A single person can now build, ship, and grow a product that would have taken a full team two years ago, because the AI writes the code and you can wire up payments in an afternoon. 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.
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 I see it constantly with the people I work with, because they jump straight into picking a framework and scaffolding features and end up shipping something that looks like everything else.
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 comes down to making decisions, like whether something should feel fast or thorough, dense or spacious. 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 rather than keywords and build something that understands what they mean:
try: how do i go live / publish / api
Type "how do I go live" into a keyword search and you get nothing, whereas semantic search understands that "go live" means deployment and surfaces the right docs with a confidence score. Both are "search", but one of them is something people actually enjoy using.
Same thing with loading states. Hit load and watch all three:
A spinner tells the user nothing, a skeleton shows them what's coming, and optimistic UI shows the content immediately and syncs in the background, and all three take about the same effort to build even though the experience feels completely different. That decision is taste, and it's the kind of thing that makes someone stay instead of bouncing.
Getting the prompt right
Once you know what you want, prompting is how you communicate it, and most people just hand the AI a task and accept whatever comes back, which is like hiring a contractor and never once visiting the site.
The prompt itself almost always separates useful output from great output:
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, and that's counterproductive because the model is usually better at implementation details than you are, so over-specifying just leaves it no room to do what it's good at. Part of it is that letting go is hard, and handing over control to something that might do it better than you is uncomfortable.
The sweet spot sits somewhere in between, where you know that Inter works for this style but you let the AI pick the size, and you describe what the terminal component should do while leaving it to figure out how to build it. Give it the vibe, a few references, the decisions that matter, and then get out of the way.
Picking a stack
I see people spend weeks evaluating tools, and 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, so the only thing worth asking is what you need.
this is my stack
Pick and move on, because any two modern stacks will get you to the same place, and the gap between them matters far less than the gap between shipping and not shipping.
Every tool in your stack should make one category of problem disappear, so Tailwind handles your CSS architecture while Polar takes care of payments and subscriptions, Better Auth handles login flows, PostHog handles analytics, and Claude writes the boilerplate. You want your time going into the product itself, and the best tools are the ones you can forget are there.
The backend and infrastructure layer is where it gets interesting, 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, pouring time into 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, and you can answer that long before you have perfect type safety or a CI pipeline wired up. All of that matters eventually, it just doesn't matter yet.
Taste and distribution matter immediately. A landing page that converts is the first thing a potential user sees, and it's where most solo products lose people, which is 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.
Getting people to use it
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, where 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. Now that the code is the easy part, you can spend more of your energy on the parts that move the needle.
Distribution is knowing where your people already hang out and then showing up there with something relevant. In practice that means writing about what you're building and sharing the thinking behind it, being a real part of the communities your users are in, and making it easy for them to pass your thing along to someone else.
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 and see whether they care, and then go back and add the tests, set up monitoring, and clean up the code. This has always been true about building products, but what's different now is that the entire cycle sits in your hands, so every blocker is yours to fix and there's 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.
So pick the one thing that decides whether this works, and do that 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.