Built solo. On purpose.

I spent fifteen years watching well-funded SaaS teams take two years to ship what should have been a one-month feature. The pattern always looked the same. A founder has a clear product vision. They raise. They hire. The team grows past the point where the founder can hold the whole product in their head. Coordination tax compounds. A feature that the founder could have written in three days takes the team three months.

I built Bonfiyah inside-out from that observation. The product is what one person can carry in their head. The infrastructure is what one person can keep running. The pricing covers the inference and the developer's salary, with margin, at a fraction of the user count a 30-person SaaS team needs.

What "solo" actually means here.

It does not mean I write every line by hand. I work with AI coding assistants on roughly every commit. The codebase is more deliberately structured than most VC-funded startups manage, because the way to make AI assistants useful is the same way to make a future engineer useful: clear module boundaries, no clever tricks, every architectural decision documented next to where the code lives.

It does mean there is no engineering manager, no PM layer, no design lead, no growth team, no eng-prod-design triad to run a feature through. The decisions get made by the person who is going to write the code that night. Which is fast.

It does mean customer support is me. Bug reports go to my inbox. The roadmap is me. The pricing is me. The privacy commitments are me. If you read something on this site that sounds like it was written by a human who knows the product, that is because it was; if you find a typo, that is also me.

What solo lets us do that a 30-person team can't.

1. 1. Refuse features. A 30-person team has thirty people generating feature ideas; their natural state is feature creep. A solo developer's natural state is "say no." Bonfiyah has shipped about as much depth into seven features as most apps ship across forty.
2. 2. Hold strong privacy lines. "We don't train on your transcripts" is a binding commitment because there is one person who can break it, and that person has decided not to. There is no quiet quarter where the data team makes a different call.
3. 3. Ship native. The cost-of-ownership case for a web wrapper is mostly headcount — you can ship one web app to all platforms with one team. That math doesn't apply if the team is one person and the platforms are iPhone, iPad, and Mac via Catalyst, which is one Swift codebase. We get to be native because solo flips the cost equation.
4. 4. Stay sellable. A 30-person SaaS is harder to acquire than a five-figure-MRR solo product, because the buyer has to underwrite thirty employment contracts and a culture they don't yet understand. A clean solo codebase with documented architecture is acquirable as a product, not as a team. That is the strategy. The exit math is simpler when there is no team to integrate.
5. 5. Ship faster than a 30-person team. The 16 features in the v3.0 release notes shipped in roughly eight weeks. A typical 30-person SaaS would have spent that time on three of them, two retrospectives, and one re-architecture proposal. The unfair part is that the AI coding assistants don't care that I'm one person.

What solo can't do, that I'm honest about.

Solo cannot run an enterprise sales motion. If you are a 5,000-person company looking for a procurement-friendly contract with single-sign-on integration, an enterprise success manager, and an SLA backed by a 24/7 oncall rotation — Bonfiyah is not yet the right vendor for you. Talk to me anyway, but go in expecting a small product, not an enterprise contract.

Solo cannot ship every platform. The Android question is asked weekly. The answer is no — not as an aspiration, as a constraint. iOS deeply, no Android, no Windows. The product would be worse on every platform if it had to ship on all of them; the product is better because it doesn't.

Solo cannot survive me getting hit by a bus. This is a real risk you should think about before bringing Bonfiyah into a workflow you depend on. The mitigation is that the codebase is documented to be picked up; the infrastructure is documented to be operated; and a transition plan exists in writing. It's not nothing, and it's not zero. It's honest.

Why this is the moment for solo.

Three things changed at the same time, and most of the industry hasn't fully metabolised it. AI coding assistants got good enough that one developer can hold the productivity of three or four. Apple Silicon got fast enough that real on-device inference is now cheap. And the consumer expectation that a useful app is just a useful app — not a platform, not an ecosystem, not a community — is back, post-everything-app fatigue.

Those three together are why Bonfiyah is built solo and why it works. They are the same three reasons you should expect more solo apps in the next few years that look like nothing the SaaS playbook predicted. We are early. There will be many more.

— Richard, building Bonfiyah from a desk on the west coast of Ireland.