What Building a Platform Solo Actually Teaches You About Product
I spent six weeks talking to five founders who built their platforms alone — from first line of code to first paying customer. No team. No PM. No handoffs. What they learned will change how you think
Long-form · Product & Building · 12 min read
There’s a quiet shift happening in how software gets built. Not a trend piece. Not a hot take. Just a pattern — visible if you spend enough time talking to the people actually doing it.
More and more, the person imagining the product and the person shipping the product are the same person. And that compression is producing a different kind of builder — and a different kind of product.
Over six weeks, I sat down — long conversations, not quick DMs — with five founders who each built their platform alone. Not with a co-founder. Not with an offshore dev team. Alone. Architect, PM, Designer, Support Rep, and Customer all collapsed into one person staring at the same screen.
What came out of those conversations wasn’t a unified theory. It was something more useful: a set of hard-won lessons about product thinking that no product management course teaches, because you can only learn them by being the person who has to make every decision yourself.
Lesson 01 — You stop planning and start deciding
Marcus K. built a compliance workflow tool for mid-market logistics firms. Former senior PM at a fintech company for four years before going solo.
Marcus had written more PRDs than he could count. He knew how to run discovery, prioritise backlogs, align stakeholders. “I thought I understood product,” he told me. “I didn’t. I understood process.”
The difference becomes obvious the moment you build alone. There’s no one to align. No one to get buy-in from. No spec to protect yourself with if it goes wrong. There is only the decision, and the consequence, arriving in the same person.
“In a team, you can write a ticket for a decision you’re not sure about and wait to see if anyone pushes back. Alone, the ticket IS you. You either decide or nothing moves.”
What he noticed, about four weeks in, was that his decision-making got sharper. Not because he was smarter — because the feedback loop was immediate. He built something, watched how it behaved, updated his mental model, and built the next thing. The distance between hypothesis and evidence collapsed.
In teams, that cycle gets fragmented across people, meetings, and documents. Information decays in translation. Solo, the signal stays clean.
Lesson 02 — Every abstraction has to earn its place
Riya P. built an AI-assisted scheduling platform for independent therapists. Self-taught developer. Background in clinical psychology.
Riya learned to code because she couldn’t afford to hire someone before she had paying customers — and because the product in her head was specific enough that she didn’t trust anyone else to build it right.
“The first three months, I kept fighting the urge to build it ‘properly,’” she said. “Proper patterns. Proper architecture. Clean separation of concerns.” She laughed. “I was building for a codebase that might never need to scale, and I kept making it harder to understand for the sake of — what? Future me? Future me would hate current me either way.”
What solo builders learn about architecture:
Premature abstraction is expensive when you’re the only one maintaining it
The right time to generalise is when you’ve done the same thing three times — not in anticipation
Complexity you introduce today is complexity you debug alone at 11pm
The simplest working version reveals the real shape of the problem faster than the elegant one
Coherence beneath the surface matters more than elegance at it
In all honesty, Riya agreed that what she shipped as her v1 was scrappy in places and precise where it mattered. The booking logic, the therapist availability rules, the session reminders — all handled with care. The admin panel, placeholder. The data pipeline, functional but not beautiful.
“I built the thing the user touches with my full attention,” she said. “Users need to use first before they think where the config and settings screens are”
This is a product instinct most teams struggle to maintain. When you have engineers, they will gold-plate things. Not out of malice — out of craft pride, and because the cost is borne by a sprint not a person. Solo, you feel the cost. It keeps you honest.
Lesson 03 — The user is always in the room, because you are them
David L. built a real-time inventory tool for independent restaurant groups. Ran restaurants for eleven years before building.
David built his platform, he said, “in a state of sustained irritation.” Every screen was designed with a specific person in mind. Not a user archetype. His former kitchen manager. His old general manager. Thinking from the perspective of real people gave him amazing ideas on what features are important and what is not.
“I never had to do user research because I was the user. I knew exactly when a flow was broken because I could feel my old self’s frustration before a customer ever told me.”
This is, arguably, the biggest structural advantage solo domain experts have over well-funded teams. A PM at a restaurant software company might interview twenty operators. David was the operator. The interview happened continuously, in memory, while he designed, coded, tested, deployed and the cycle repeated.
The result was a product that felt, to its early users, like it had been built specifically for them. Because in a sense it had. Not through research. Through proximity.
The lesson isn’t that user research is bad — it’s that the closer the builder is to the problem, the less translation loss there is between what users feel and what gets built. Solo domain founders get an almost unfair version of that closeness.
Lesson 04 — Shipping without consensus sharpens your conviction — and your accountability
Sofia A. built a legal document workflow tool for small immigration practices. Former immigration attorney. Taught herself to build over 18 months.
Sofia knows the domain. She also spent evenings and weekends learning to build software. When she finally launched, she had made hundreds of product decisions that no one else had weighed in on.
“I used to think consensus was quality control,” she said. “That if enough smart people reviewed a decision, you were more likely to get it right.” What she found instead was that consensus was often a form of distributed accountability — meaning no one was actually accountable.
“When you ship something alone and it doesn’t work, you can’t point at the process, or the spec, or the designer who misunderstood. It’s just you. That is terrifying. And it is the most useful thing that’s ever happened to my judgment.”
She described developing what she called a “reckoning practice” — after every significant feature, she’d spend 20 minutes writing down what she expected to happen and what actually happened. Not for anyone else. Just to update her own model.
“You get really good at being wrong in a way that makes you better,” she said. “Teams make you good at being right in meetings.”
What accountability looks like without a team:
No spec to hide behind when something ships wrong
No design review to diffuse responsibility through
No “that was engineering’s call” — it was all your call
Every mistake updates your model directly, with no noise in the signal
You learn to distinguish “I’m uncertain” from “I’m avoiding the decision”
Lesson 05 — The tools changed. The constraint is now judgment — and always was.
Tom N. built a developer workflow platform for small engineering teams. Former staff engineer, two decades in.
Tom was the most technically fluent of everyone I spoke to. He builds fast — genuinely fast. But when I asked him what made the solo experience different, he didn’t talk about code. He talked about clarity.
“The tools right now are — honestly — shocking,” he said. “Infrastructure that used to need a platform team runs on config files. AI handles 60% of the boilerplate. You can go from idea to working prototype in hours. The tooling ceiling is barely the constraint anymore.”
The constraint, he said, is and always has been knowing what to build. And that’s where teams sometimes create a false sense of security. More people means more surface area for opinions. More opinions means more negotiation. More negotiation means more averaging.
“You can average your way to something no one objects to and everyone finds mediocre,” he said.
“The teams that are going to win are not the biggest. They’re the ones with the smallest distance between understanding the problem and building the answer. Right now, that distance can be one person.”
This is the structural shift underpinning all of this. The marginal cost of building capability is collapsing. What remains genuinely scarce is judgment — the ability to know what to build, in what order, at what depth, for whom. Solo builders don’t have more judgment than teams. But they have fewer layers between their judgment and the product.
The honest part — this isn’t a manifesto for building alone forever
Every person I spoke to said some version of the same thing at the end: building alone is a phase, not a philosophy. At some point, the leverage from other people’s thinking genuinely outweighs the coordination cost. Blind spots compound. You need people who see things you don’t.
But they also each said something else — that the window when you can hold the entire system in your head, make every call yourself, feel every consequence directly — that window is an asset, not a constraint. It’s training that no job, no course, and no team experience replicates.
And right now, for the first time in the history of software, that window is accessible to people who aren’t exceptional engineers. The tools have caught up. The infrastructure is commoditised. The design systems are good enough. What separates a product that resonates from one that doesn’t has always been judgment, clarity, and closeness to the problem.
Those things have never been team-size-dependent. They never will be.
“The window where you can hold the whole thing in your head isn’t the hard part. It’s the most valuable part. Most people rush through it trying to hire their way out of it.”
Building something solo? I’d like to hear what’s working — and what you wish someone had told you earlier.