The One-Person Stack
How to ship real products alone and what to care about at each stage.
A single person can now build, ship, and grow a product that would have taken a full team two years ago. AI writes code, platforms handle infrastructure, and there are off-the-shelf solutions for payments, analytics, auth, and everything in between.
Products like Sher and Teenage Manual went from idea to production in a matter of hours and are now used by hundreds of people, and that speed changes how you think about the whole process. This post covers what I focus on at each stage and what I deliberately ignore.
Taste comes first
Before you pick any tools, get clear on what good looks like for the thing you're building. Who is it for, what should it feel like to use, and what's the one thing it does that nothing else does.
Most builders skip this and jump straight into picking a framework, scaffolding features, and shipping something that looks like everything else. I see this constantly with people I work with.
99% of products die before the first user even touches them because the builder picked a stack, generated a landing page, and assumed the hard part was done without ever asking what makes this thing worth using. The biggest competitor for most products is indifference.
Taste is making decisions. Fast or thorough, dense or spacious, playful or serious. Every product has hundreds of small choices like these and the ones you make are what give it character.
What taste looks like in practice
Say your product has a docs section and you need search. You could drop in a basic keyword matcher and move on. Or you could decide that your users think in questions, not keywords, and build something that understands intent:
Type "how do I go live" into a keyword search and you get nothing. Semantic search understands that "go live" means deployment and surfaces the right docs with a confidence score. Both are "search", but one is a feature and the other is an experience.
Same thing with loading states. Hit load and watch all three:
A spinner tells the user nothing. A skeleton shows them what's coming. Optimistic UI just shows the content immediately and syncs in the background. All three take the same amount of effort to build, but the experience is completely different. That decision is taste, and it's the kind of thing that makes someone stay instead of bouncing.
Prompting is the new skill
Once you know what you want, prompting is how you communicate it. Most people give the AI a task and accept whatever comes back, which is like hiring a contractor and never visiting the site.
What separates useful output from great output is almost always the prompt:
Click through the steps and notice what changes. "Good typography" becomes "Inter for headings, monospace for code" because you know that pairing works for dev tools with an editorial feel. "Modern and clean" becomes "think Linear but warmer" because you've spent time looking at things and you know what that means.
"Add an interactive component" becomes a specific terminal where people type a deploy command and watch the output, because you've seen things like that work and you know it fits the product. The prompts aren't longer, they just carry more information because of the homework you've already done.
A lot of people I work with go too far in the other direction though, trying to describe every pixel and every interaction. That's counterproductive because the model is often better at implementation details than you are, and over-specifying leaves it no room to do what it's good at. I think part of it is that letting go is just hard. Giving up control when something might handle it better than you is uncomfortable.
The sweet spot is somewhere in between. Know that Inter works for this style but let the AI pick the size. Describe what the terminal component should do but let it figure out how to build it. Give it the vibe and the references and the key decisions, then get out of the way.
Pick your stack, then stop thinking about it
I see people spend weeks evaluating tools. Every hour spent comparing ORMs or debating serverless vs containers is an hour you could have spent talking to a potential user. The tools all work. The real question is: what do you actually need?
Pick and move on. Any two modern stacks will get you to the same place, and the difference between them matters far less than the difference between shipping and not shipping.
Every tool in your stack should make one category of problem disappear. Tailwind handles CSS architecture, Polar handles payments and subscriptions, Better Auth handles login flows, PostHog handles analytics, Claude handles the boilerplate. You want to spend your time on the product itself, and the best tools are the ones that let you forget they're there.
Where it gets interesting is the backend and infrastructure layer, because that's where solo builders lose the most time. My stack uses Encore, but the principle is the same regardless of what you pick: choose something that lets you write application code and handles the rest. If you're spending time on infrastructure config, you're solving the wrong problem.
What matters now vs later
This is where most builders get stuck, spending time on things that matter in theory but are premature in practice.
The way I think about it: on day one, the only question worth answering is whether anyone wants what you're building. You can answer that without perfect type safety, without a CI pipeline, without monitoring. All of that matters eventually, just not yet.
What does matter immediately is taste and distribution. A landing page that converts is not a nice-to-have, it's the first thing a potential user sees and it's where most solo products lose people. That's almost always a taste problem more than a technical one.
Click around and rearrange. My defaults are there but yours might be different. The point is to be intentional about what you're choosing to defer rather than trying to do everything at once.
Distribution is the actual work
Building a product with AI takes days, but getting people to use it takes months.
We're seeing this play out with the wave of AI building tools like Lovable and Bolt. More products are getting built than ever, but the ones that get traction are the ones where someone put in the work to find their audience and show up consistently. The code is the easy part now, and that's a good thing, it means you can spend more of your energy on the parts that actually move the needle.
Distribution is knowing where your people already hang out and showing up there with something relevant. Write about what you're building and share the thinking behind it. Be present in the communities your users are part of. Make it easy for people to tell others about your thing.
Ship, then care
It's tempting to care about everything at once and end up with a polished, well-tested product that nobody uses. I've been there, and it feels productive while being the opposite.
Get it in front of people first. See if they care. Then go back and add the tests, set up monitoring, clean up the code. This has always been true about building products, but what's different now is that the entire cycle is in your hands. There's no team to wait on, no blocker that isn't yours to fix, and nobody else to point at when something doesn't land. When you can build anything, the only thing standing between you and traction is your own decisions.
The one-person stack is really about knowing what to do first.
If you're building something solo and want a second pair of eyes on your stack, your positioning, or your go-to-market, book 15 minutes with me.
