On Glyph, a printing marketplace in Yaoundé, I built all three pieces: the backend in Go, the mobile app in Expo, the admin console in Next.js. Alone.
The usual reaction, when I tell it, oscillates between "that's impossible" and "it must be slapdash". Both deserve an honest answer.
The myth of the minimum team
There's a stubborn belief that a serious product requires at minimum a backend, a frontend, a mobile dev, a designer and a product manager. Five people before the first line of code.
It's false for one simple reason: coordination has a cost that grows faster than output. At five, you spend your days synchronising, specifying interfaces, cross-reviewing, waiting. At one, that cost is zero.
Saitama, in One Punch Man, didn't train with a coach, a high-tech gym or a nutritionist's programme. A hundred push-ups, a hundred sit-ups, a hundred squats, ten kilometres, every day, for a year and a half. The manga's joke is that this ridiculous routine works better than every sophisticated method.
The parallel has limits — I'm not claiming to beat a team of ten. But the idea holds: regularity and simplicity beat badly executed sophistication. A lone developer shipping every day outruns a team of five stuck in scoping meetings for three weeks.
What the constraint imposes
You can't afford to be clever
When you're alone, every abstraction you write is one you'll maintain at 2am six months from now. That prospect has a remarkably cleansing effect on architectural ambitions.
On Glyph's Go backend, the architecture fits in four layers:
cmd/server entry point, dependency wiring
internal/domain pure business entities, zero dependencies
internal/repository contracts + MongoDB implementations
internal/service use cases
internal/handlers HTTP
No code generator. No reflection-based dependency injection. No homemade framework. Functions that take parameters and return values.
It isn't impressive. It's readable six months later, which is worth infinitely more.
You must choose technology for the exit, not the entrance
The usual criterion for a technology choice: "what will I go fastest with?" The right criterion when you're alone: "what will cost me least to operate?"
Go for the backend isn't the language I write fastest in. It's the one that produces a single binary, with no system dependencies, that starts in thirty milliseconds and uses thirty megabytes of RAM. On a VPS shared with other projects, that counts every day.
Expo for mobile isn't the most powerful option. It's the one that lets me ship iOS and Android without owning a Mac dedicated to builds and without maintaining two native toolchains.
These are an operator's choices, not a developer's. It's the most useful shift in perspective working solo gave me.
You become the first user of your own interfaces
When the same person writes the API and the client that consumes it, something amusing happens: bad APIs disappear within hours.
An endpoint that forces three calls to render one screen? I feel it while writing the screen, I go back and fix it. A response that returns identifiers without their labels? Fixed before it's even documented.
In a team, that friction becomes a ticket, a discussion, a compromise, sometimes a "we'll live with it". Alone, the feedback loop is immediate and ego has no time to get involved.
What the constraint forbids
You have to be honest about the limits, otherwise this text is just an advert.
You have no reviewer. Nobody tells you "that variable name is incomprehensible" or "you just reinvented the wheel". My counter: I re-read my diffs the next morning, before merging. The delay is enough to restore a fresh eye. Imperfect, but better than nothing.
You have no specialist. When a security issue surfaces, you have no one to refer to. You read, you learn, you doubt. On sensitive subjects — payment, authentication, data isolation — I forbid myself from inventing anything: I follow official recommendations to the letter, even when they seem excessive.
You are a single point of failure. That's the real risk, and it's the client's. My answer: documentation written as if I disappeared tomorrow. Glyph's repository contains a README that lets someone else run the whole thing with one command, and an architecture file explaining the decisions and their reasons.
It's also the first thing I look at when taking over someone else's project: did anyone write why, not just what.
The real subject: cognitive load
The real cost of working solo isn't the quantity of code. It's context switching.
Moving from Go to TypeScript, from MongoDB to React Query, from order logic to a rate card, means emptying and reloading your working memory several times a day. It's exhausting in a way sheer volume of work doesn't explain.
What helps me:
- One piece per day, not three. Monday backend, Tuesday mobile. Not backend in the morning and mobile in the afternoon.
- Write down the state before stopping. Three lines in a notes file: where I am, what's blocking, the next action. Resuming the next day costs two minutes instead of forty.
- Identical conventions everywhere. Same naming, same folder structure, same error handling, whatever the language. The brain recognises patterns even when the syntax changes.
That last point has the most effect, and it's almost invisible in the final code.
The profession's current problem
We've built an ecosystem that assumes abundance. Tutorials assume a team. Reference architectures assume microservices, therefore several teams. Tools assume an infrastructure budget.
Yet the vast majority of developers in the world work alone or in pairs, on real products, with serious cost constraints. That reality is very poorly documented, because the people writing the most visible technical content work in large organisations.
The result is a generation of developers splitting a three-user product into microservices, because that's what Netflix does. Architectural mimicry is expensive.
The question to ask before every technical decision: "am I solving my problem, or the problem of someone whose article I read?"
What I'd recommend to someone starting alone
- A monolith. Always. You'll split it when a measured reason demands it. That reason will probably never come.
- A relational database, absent a compelling reason. Postgres does 90% of what you think you need a specialised tool for.
- Deployment on day one. A "hello world" in production on Monday beats a perfect architecture undeployed on Friday.
- Write the decisions down. One file, one decision per section: the context, the choice, the rejected alternative. It's the document you'll re-read most.
- Ship small, often. That's Saitama's routine: nothing impressive in isolation, formidable over time.
Glyph is described on its project page. If you're carrying a product alone and want an outside opinion on your technical choices, write to me — the first conversation is free.