Stefan van der Vlag

Why every app I build does 1 job

By · · Thoughts

Featured image for "Why every app I build does 1 job", a post by Stefan van der Vlag

A one job app is software built to solve a single problem for a single kind of buyer, with a name and a homepage that make that job obvious in seconds. I build every product this way: 1 product, 1 category, 1 clear promise. When an idea doesn't fit, it doesn't get a new tab. It gets its own product.

Most software companies drift the other way. They add a feature for every request until the homepage needs 3 paragraphs to say what the thing is. I've decided not to do that, and it has shaped every product I run.

What does a one job app look like?

Take the products I run. Clepher builds AI chatbots for websites, Messenger, Instagram and WhatsApp. CommentWard puts every comment from Facebook, Instagram, Threads, TikTok and YouTube in 1 inbox, with AI replies. ReviewComet asks customers for reviews and answers the reviews that come in. Robofono is the AI receptionist I'm building, and it answers every call.

None of them does the job of another. CommentWard isn't a chatbot builder. Clepher isn't a review tool. Each one is a category on its own, and you can tell which from the name and the first line of the homepage.

Four product cards, Clepher for chatbots, CommentWard for comments, ReviewComet for reviews and Robofono for calls, each with 1 job
4 products, 4 jobs, no overlap.

Why not build 1 big platform?

Because a big platform makes the buyer do the work of understanding it. Someone who lands on a page that says "all in one" has to figure out which part is for them, and most people leave instead of figuring.

A narrow product is also easier to judge. If a buyer needs comments handled, they know in 5 seconds whether CommentWard is the answer. There is no feature matrix to read, and no trial to start just to find out if it fits.

The same goes for your own head. When a product has 1 job, every decision has a filter: does this make the job better, or not? Most feature requests fail that test on the spot.

What do I do when a new idea doesn't fit?

I ask 1 question: is this the same job, or a different job for the same people? If it's the same job, it goes into the product. If it's a different job, it becomes its own product, even when it would be easy to bolt on.

That is how the lineup grew. Reviews are a different job from comments. Calls are a different job from reviews. Each got its own name and its own homepage instead of becoming a tab inside something else.

Decision flow: a new idea is tested against the job, same job goes into the product, a different job becomes its own product
The question I ask before any new feature gets built.

How can 4 products work with a small team?

The shared foundation is the reason this is possible. The plumbing that every app needs is built once, and every app runs on top of it. A new product only has to build its own job.

That is the trade I'd recommend. Keep the products narrow, and make the parts that every product needs the same everywhere. I wrote about how that plays out day to day in how I run 4 software products with a small team and AI.

How do you pick your 1 job?

Write the job as 1 sentence with a verb and a buyer in it. If you need "and" twice, you have 2 jobs. If a stranger can't repeat it back after reading the homepage once, the job isn't clear yet.

Then look at your product list and ask which features serve that sentence. The rest are candidates for removal, or for a product of their own. The same thinking applies to offers. My book teaches the C9 System for starting an AI agency, and it does that and nothing else. You can see it at aiagencymethod.com.

FAQ

What is a one job app?

A one job app is software that solves 1 specific problem for 1 kind of buyer. Its name and homepage say what the job is, and features that don't serve it are left out.

Isn't an all in one platform more valuable?

It looks that way on a pricing page, but the buyer pays for it in confusion. A focused product is faster to understand, easier to support and easier to compare, and those things win more sales than a long feature list.

When should a feature become its own product?

When it serves a different job, even for the same customers. If explaining it requires a new sentence about what the product is for, it deserves its own name and its own homepage.

Every time I say no to a feature, a product stays easy to explain. That is worth more than the feature.

Get my newsletter

What I've learned building companies, and what I'm still figuring out. Only when it's worth sending.

I only use your email to send this newsletter. Unsubscribe anytime. Privacy policy.

Subscribed! Check your inbox to confirm.