I’ve been in contact with a lot of web agencies and web developers, and I personally haven’t found many people who run their agency in a more efficient way than I do. A lot of them have too many meetings, wait too long for client approval, don’t know how to price projects, and spend way too much time on each client instead of finishing the work and moving on to the next one.

I’ve been running my agency for four years, and after a lot of trial and error, I’ve managed to make the process as efficient as possible. I wanted to share some of the steps because I think they could be valuable for anyone just starting out.

Running a web agency alone or with a partner isn’t easy because there are a lot of things to take care of. When it comes to client acquisition, I recommend focusing on either cold calling or email automation. Which one you choose depends on whether you run the agency alone or with someone else.

If you have a partner, one person can handle sales while the other focuses on building websites, connecting domains, setting up emails, and taking care of the technical work. If you’re running the agency alone, or neither of you enjoys cold calling, I highly recommend email automation.

That’s what I’ve been doing for years. It’s powerful because you can send emails at scale, set up automatic follow ups, and wait for businesses interested in a new website to reply. While you’re working on one client, another opportunity can come in without you having to stop everything and search manually.

I don’t do regular email automation where I target businesses with no website. I do the opposite and target businesses that already have one.

I use a tool called Swokei to find businesses with websites, add them to campaigns, analyze each site, score it, and generate personalized outreach emails based on problems it finds with the design, layout, speed, SEO, and mobile optimization.I schedule the campaign, set up follow ups, and wait. 

I think this approach is much better for a few reasons. You’re targeting someone who already understands the value of having a website. You’re also not just asking whether they need a redesign. You’re pointing out real problems with their current site, which makes it clear that you actually took the time to look at it. Selling also becomes easier because they’ve already paid for a website before and understand the process.

Inside Swokei, you can choose the goal of the campaign. You can offer a free draft, try to book a meeting, or simply start a conversation. I always choose the free draft because that has worked best for me.

Once you’ve figured out how to get clients, the next part is building the website. I recommend using AI because it makes the process much faster. For anyone who still thinks AI can’t build great websites, I think they’re mistaken. You can use Claude, Base44, Lovable, or any other tool that works for you.

When someone replies interested, I call them and say, “Hey, I saw that you replied to my email. I’ve already built you a free draft of your website. Do you want to take a look?”

Then I invite them to a Google Meet.

At that point, it becomes much harder for them to reject the meeting because they already replied interested and now know you’ve built something for them. During the meeting, I present the website, explain why it’s better than their current one, stack the value, answer their questions, and try to close the deal.

These meetings usually go well because the client isn’t trying to imagine what the website might look like. They can already see a better version of their current site. They also took the time to join the meeting, so taking the next step becomes much easier.

I either take payment during the meeting or send them a contract to sign. Any changes and updates come after that, once we already have a deal in place.

Pricing depends on the business. I charge anywhere from $500 to $3,000 depending on the company, the size of the project, and how much value the website can bring them. I also charge a monthly retainer of around $50 for hosting, maintenance, support, SEO, and future changes.

That’s basically the entire process. Smaller steps, faster delivery, less wasted time, and more money made.

Hey, I've been using Claude Code but completely vanilla — no plugins, no MCP servers, no skills, nothing. Everyone around seems to have some kind of setup going and I feel like I'm missing out on productivity.

What plugins/extensions/skills do you actively use?

hey guys so i’m building a social media app right now (still working on it, not finished yet).

​obviously music is a huge feature for social platforms but i have literally $0 and zero users right now, so paying for actual music licenses is completely impossible.

​i tried just baking the audio straight onto the video files but that sucked. i can't even let people trim the sound or change the volume because of copyright issues and technical headaches.

​for anyone who built something like this, how do you handle popular or trending audio in the early MVP stage? are there any clever workarounds, apis, or hacks to get around this until you actually have the budget for real licenses?

​any ideas would help a lot, thanks

Building a CLI based notes app with TypeScript and INK that you can access from anywhere on your system just by writing "notescli" in your terminal

Some features :

\- saves notes in .md files

\- connects to github and syncs your notes

\- AI formatting, so u just write in it, and it gets formated on its own. (Still doubtful but will try to implement)

Possibly gonna ship an npm package out of it.

If you have any features that you think might be useful in this type of app or some add-ons, I would appreciate them. And please review the idea. It will kinda be my flagship project on my resume.

This post is more about reasoning behind the design of a programming language I made: TypR — I'd like your pushback on the thinking itself.

The honest origin story: I didn't build TypR for AI. I built it because I care about type systems (academic background) and about code that survives production (industry background) — verifiability, basically.

What clicked more recently is that the property making code cheap for a *human* to verify is the same one that matters when a *machine* wrote it.

As AI writes more of the code, the expensive part stops being writing it and becomes trusting it — reviewing, validating, maintaining. A strict type system becomes a free automatic checker on whatever got generated; concise syntax means less to misread.

So the fit with the AI era isn't something I designed for — it's the same property suddenly mattering a lot more. That's the accidental discovery I wanted to share here.

A small taste — this R:

```

#' Create a button widget

#'

#' @param color \code{char}

#' @param height \code{int}

#' @param text \code{char}

#' @param width \code{int}

#' @return \code{Button}

#' @export

Button <- function(color, height, text, width, .spread = NULL) {

explicit <- list()

if (!missing(color)) explicit[["color"]] <- color

if (!missing(height)) explicit[["height"]] <- height

if (!missing(text)) explicit[["text"]] <- text

if (!missing(width)) explicit[["width"]] <- width

x <- typr_spread_record(explicit, .spread)

as.Button(x)

}

as.Button <- function(x) {

if (!inherits(x, "Button")) class(x) <- c("Button", "list")

x <- validate_Button(x)

x <- validate(x)

x

}

validate_Button <- function(x) {

required_fields <- c("color", "height", "text", "width")

missing_fields <- setdiff(required_fields, names(x))

if (length(missing_fields) > 0) {

stop(paste0("Validation failed for type Button: missing fields: ", paste(missing_fields, collapse = ", ")))

}

if (!inherits(x[["color"]], "character")) stop("Validation failed for type Button: field 'color' must be of class character")

if (!inherits(x[["height"]], "integer")) stop("Validation failed for type Button: field 'height' must be of class integer")

if (!inherits(x[["text"]], "character")) stop("Validation failed for type Button: field 'text' must be of class character")

if (!inherits(x[["width"]], "integer")) stop("Validation failed for type Button: field 'width' must be of class integer")

x

}

# constructor for a red button

#' @export

#' @method red_button

`red_button` <- (function(height, width, text) Button(height = height, width = width, text = text, color = "#FF000000" |> as.Character())) |> as.Generic()

# add an "on click" callback function

#' @export

#' @method on_click Button

`on_click.Button` <- (function(self, f) {

NA

} |> as.Empty0()) |> as.Generic()

```

becomes this TypR:

```

# Create a button widget

@export

type Button <- list {

text: char,

color: char,

width: int,

height: int

};

# constructor for a red button

@export

let red_button <- \Button:{ color: "#FF000000" };

# add an "on click" callback function

@export

let on_click <- fn(self: Button, f: (T) -> U): Empty {

...

};

```

The way TypeScript sits on top of JavaScript's runtime, TypR sits on top of R's: you write something concise and type-checked, and it compiles down to standard, S3-based R that runs anywhere R runs and installs like any other package — no new runtime, no exotic dependencies.

To be clear, it's not trying to replace R. R is excellent for interactive stats and lab work, and TypR deliberately gives some of that up in exchange for the other end of the curve: robust packages, deployable apps, code that has to survive production. Different point on the trade-off, different job.

On the engineering side you get pattern matching, partial currying, union/intersection types, structural subtyping, row polymorphism — the machinery that keeps a growing codebase honest. Written in Rust, developed in the open.

Honest questions for this sub: does a typed layer over R solve a problem you actually hit, or is this a solution looking for one? And does the "verifiability matters more when AI writes the code" argument hold up, or am I reaching?

Discussion: [https://github.com/we-data-ch/typr/discussions\](https://github.com/we-data-ch/typr/discussions)

Github: [https://github.com/we-data-ch/typr\](https://github.com/we-data-ch/typr)

Website: [https://we-data-ch.github.io/typr.github.io/\](https://we-data-ch.github.io/typr.github.io/)

Over the past year, I've been helping run a programming community that's now around 600 members. One thing we've learned is that activity matters far more than member count.

We've found that encouraging people to ask questions, share resources, build projects together, studying together late night and y removing long-term inactive members to keeps discussions much healthier than simply growing numbers.

anyone interested reach me out or check comments