Small software

Most software is big software.

Big software is software that serves a large audience — think Facebook (3 billion active monthly users), or Gmail (people who need email), or Wikipedia (humans looking for information).

Big software is typically created by a large team, partially beholden to outside money (venture capital or the stock market) in order to pay for such a large team. A large team probably requires a complex corporate structure, including organizations for sales and marketing, as well as teams that support the teams who are building the software, such as HR and IT.

Small software addresses a particular niche or community. It’s made by a tiny team. It has no aspirations of millions of users or global dominance.

Small software that’s good shares the characteristics of any good software. It’s designed and built with an attention to craft that permeates every detail, from the overall architecture to the tiniest interaction. It respects its users, honoring their choices for things like text size or screen mode. It’s opinionated, having its own point-of-view on the problem it’s solving, rather than trying to be all things to all people.

Small software is less about the size of the product and more about the mindset. It’s about rejecting the default path of scale-at-all-costs and focusing instead on craft, community, and sustainable development.

Small software can be apps that do one thing exceptionally well, like Flighty or Foodnoms. It can be platforms built to grow sustainably and have opinions, like Ghost. It can be personal projects made publicly available, like Wordle. And it can be software meant as an opinionated alternative to a more-generic competitor, like Obsidian for note-taking apps or Fantastical for calendar apps.

Why software tends to go big

The nature of software tends to nudge it towards being very big or very small.

On one hand, software has a very low barrier to entry. Anyone with a computer and some know-how can build something that works. With the right amount of time and ambition, a scrappy solo developer can build software that competes in a category with Fortune 500s.

On the other hand, software is a game of scale. It costs Google effectively the same to serve its 100-millionth user as its billionth user. Once software is built, the marginal cost of adding new users is almost zero. This dynamic is why so many startups seek venture capital: to get the initial burst of funding to build the product, and then ride the wave of users as the costs decrease over time.

Big software isn’t bad, and small software isn’t good. But the economics of software make it tempting to believe that bigger is better — that success is defined by exponential growth, massive teams, and global reach.

In many cases, though, builders and users alike would be better served by software that intentionally stays small.

The philosophy of staying small

Small software embraces a different ethos. It’s not just about serving a smaller, more focused group of users — it’s about deliberately emphasizing craft and, sometimes, community.

Small software often forgoes growth-for-the-sake-of-growth in favor of continual refinement, slow evolution, and deepening connection with users. It usually isn’t trying to disrupt an entire industry; it’s trying to solve one problem for one group of people. It resonates deeply with that particular group because the creator is often a member of that group — a flight-tracker app made by someone who flies a lot, or a regional community made by someone who’s a member of that community. They focus on the right details because they intimately know which details matter.

Aside: on small software and small teams

The relationship between small software and a small team isn’t exact. Typically, “small software” is built by a small team, but there’s big software built by small teams (the early days of Instagram) and small software built by big teams (arguably Dropbox, when it was a public company but still focused entirely on cloud storage).

Still, the relationship between small software and small teams is more common because the incentives align. Small teams can maintain a singular vision without needing to scale quickly to maintain an ever-growing base of employees, and the success of small software is often measured in depth of engagement rather than breadth of reach.

Finally, small software with a niche focus can take off with fewer initial resources, which avoids putting the company on the flywheel of outside capital and, therefore, constant acceleration.

The broader movement: indie hacking and the indie web

Small software fits into a broader cultural undercurrent within the tech scene towards decentralization and independence.

There’s the “indie hacking” community, where individuals or small teams build software not to achieve Silicon Valley-level exists but to create sustainable, profitable lifestyle businesses. Indie hackers often focus on bootstrapping, maintaining independence, and building software for very particular niches.

The “indie web” movement is a push against the monolithic internet conglomerates like Meta and Alphabet. Here, developers create websites and platforms based on open protocols, embracing decentralized alternatives like the fediverse. These projects are often structured around values like user autonomy and transparency, intentionally going against the grain of the mainstream web.

The future of small software

Why don’t more builders pursue small software?

Part of it is cultural — there’s a belief in the startup world that success means going big. There’s validation in user numbers, investor attention, and splashy headlines.

Part of it is because some ideas shouldn’t or can’t be small. If you’re aim is to empower anyone anywhere to protect their online identity, or to offer a free encyclopedia of the world’s knowledge, or to empower teams to seamlessly communicate across timezones, you absolutely should be building big software.

Part of it is the trend towards specialization. As the software ecosystem grows in complexity, there are fewer generalists out there who can take an idea from concept to design to execution to distribution. If you’re skilled in a single part of that stack, you’ll need a team who’s skilled in the other parts. Small software requires generalists who are comfortable wearing multiple hats, or who are able to learn quickly, or who are comfortable with deep ambiguity.

The rise of AI tools may help swing the pendulum the other way. The emergence of readily-accessible Large Language Models means that solo founders can amplify their productivity and augment their abilities, just by knowing what to ask. In this version of the future, AI tools could magnify a small team’s efforts so that more specialists become generalists and more dreamers become builders.

As the tech industry continues to evolve, there’s room for both big and small software. And there’s room to fluctuate between them; builders who grew their skills working on big software can go solo and build small software, and small software can sometimes become the seed from which a larger, more global concept grows.

At the beginning of this essay, I said that “most software is big software.” That isn’t entirely true — more accurately, the software we think about when we think about software is big software. Small software is everywhere, from the tiny open-source packages underlying the web to the indie apps on our phones to the little projects put into the world by someone who just wants to scratch a particular itch. There’s tons of small software, and lots of people making it, for a living or for the love of their users or the love of the craft.

So next time you have an idea: consider making it small.