๐Ÿšง Designers never finish their own portfolio. This one ships rough on purpose and gets better in public. If something looks half-done, it probably is, and I'm on it.๐Ÿšง Designers never finish their own portfolio. This one ships rough on purpose and gets better in public. If something looks half-done, it probably is, and I'm on it.๐Ÿšง Designers never finish their own portfolio. This one ships rough on purpose and gets better in public. If something looks half-done, it probably is, and I'm on it.๐Ÿšง Designers never finish their own portfolio. This one ships rough on purpose and gets better in public. If something looks half-done, it probably is, and I'm on it.๐Ÿšง Designers never finish their own portfolio. This one ships rough on purpose and gets better in public. If something looks half-done, it probably is, and I'm on it.๐Ÿšง Designers never finish their own portfolio. This one ships rough on purpose and gets better in public. If something looks half-done, it probably is, and I'm on it.
Open menu
Switch to Darkhello@product.inc
The changing economics of small software โ€” cover sketch

The changing economics of small software

ยท Alex Zapadenko

Not long ago, even a relatively simple app required a designer, a developer, and months of work. An application earning a few hundred dollars a month was hardly worth building commercially. Now one person can build it in a week, and the same modest revenue might support a viable little business.

I recently built YumLog, a voice-first calorie tracker for the Apple Watch and iPhone, in about a week using AI-assisted development. The first working version came together quickly. Getting it from roughly 70% finished to something that worked properly took about as much time again. It wasn't effortless, but the entire process was compressed into days.

Who gets to build a business?

As a designer, I've spent much of my career in an industry where the usual ways to make money involve selling your expertise or your time. You work in-house, join an agency or consultancy, freelance, or make tools and content for other designers. Each of those either sells your time or sells to other designers.

Designers have founded software companies before. But building a commercial product independently usually required engineering skills, a technical partner, or substantial investment.

Now I can build and sell software to practically anyone, without assembling a team first.

I don't think this is limited to designers. An accountant with a specialized workflow understands it better than most software vendors ever will, but custom development has historically been too expensive to justify. Now they could build that tool themselves, or with a single person who knows how to make software. And if it works for them, other accountants might pay for it.

Build first, decide later

One popular argument is that as software becomes cheaper to produce, knowing what to build becomes the most valuable skill.

I'm not convinced. I think the economics are moving in the opposite direction.

When building something takes six months and a team, you need to scrutinize the idea before committing. When it takes a week, why spend weeks debating whether it's worth building? Make the thing, release it, and find out. The judgment doesn't disappear. It moves to after the release, where you're looking at what people actually did.

Not every project can be built in a week, but small ones can. That could produce a lot more software, including plenty that nobody particularly needs.

Not everyone wants to make software

Almost everyone has a camera in their pocket, but that didn't turn everyone into a photographer. Image generation made producing pictures incredibly accessible, but it hasn't made everyone a digital artist.

I suspect software will follow a similar pattern.

People will build temporary tools, experiment with ideas, and generate little applications for themselves. Some will be useful, others will be terrible, and many will be forgotten.

But maintaining a product, iterating on it, supporting customers, and keeping it running are still work. Making that work easier doesn't mean everyone suddenly wants to do it.

And build versus buy isn't going anywhere. Developers have always been able to write functionality that already exists in packages and libraries. They use those packages anyway because reinventing everything makes little sense.

I expect ordinary businesses and individuals to make similar decisions.

The uncomfortable economics

Software production could grow enormously without demand growing nearly as fast.

People don't suddenly need ten calorie trackers because ten people can now build one in a week. Their subscription budgets and available attention haven't multiplied either.

Competition for existing categories of software will probably become brutal.

But I don't think that necessarily means fewer opportunities. The economics of serving tiny markets are changing too. An application with a hundred paying customers might be perfectly reasonable for one person to build and maintain. A specialized tool that no software company would have bothered producing might suddenly make commercial sense.

I'm interested in operating a small portfolio of applications. Build something, find customers, earn a little recurring revenue, then build something else. Some products might grow, some might barely survive, and others will eventually be retired.

I'm not assuming this adds up to a living. It might not. But I can now explore the model without quitting my job, hiring developers, or raising money.

The biggest challenge, I suspect, won't be producing the software. It'll be finding people willing to pay for it. And as more people gain the ability to build, getting noticed could become even more difficult.

What I'm not claiming

I don't expect traditional software companies to disappear, or everyone to become an entrepreneur. Larger systems and critical infrastructure operate under very different constraints.

I'm going to keep building and see how much of this holds up.