My stack for shipping a product alone

The stack I use to build and ship a product alone is: Next.js, Supabase, Vercel, Cursor, Claude, Resend, Figma, Notion, GitHub. Nine tools, always the same ones, on every project.

The criterion I chose them by is not "best for the job". It is: how many tools can I know well enough to stop thinking about them. Working alone, every new technology is time taken away from the part that decides whether the product works.

Why repeating the same stack matters more than picking an optimal one

Because the advantage is not in the tool, it is in not starting over. By the third project on the same stack, infrastructure stops being a problem: authentication, deploys, transactional email and database schema are decisions already made, and the time all goes to the product.

Another stack would do just as well. What would not do well is switching every project to chase the best tool of the month. The performance difference between two modern frameworks is irrelevant next to the difference between "I already know how this works" and "I am finding out now".

What each of the nine does

Next.js: the framework for anything on the web. App Router, static rendering wherever possible. It also runs the site you are reading.

Supabase: Postgres database, authentication and storage in one piece. It is the main reason I can start without writing a backend: access rules live at the database level, not scattered through the code.

Vercel: deploys and hosting. The value is not deploy speed: it is that every branch gets a preview URL, so I see a change under real conditions before it reaches production.

Cursor and Claude: the AI part of the stack. I use them to understand code I did not write and for repetitive changes. Where they stop helping is in building faster is not deciding better.

Resend: transactional email and the newsletter. One thing that does one thing.

Figma: design. I do not build high fidelity mockups of everything: I use Figma for the two or three screens that decide the product, and draw the rest directly in code because it is faster.

Notion: where everything that is not code is written down. Hypotheses, decisions and why they were taken, weekly numbers. It is the thing that made Bitzuma sellable in five months: the process written outside my head.

GitHub: code and history. Even on projects where I am the only one writing, because history is memory.

What I deliberately do not use

• No complex analytics at the start. One number is needed: how many people come back the following week. Everything else is an elegant way of not looking at it.
• No task management system. Alone, a list in Notion is enough. A board with columns and states is overhead imitating a team that does not exist.
• No heavy component library. Local components I can read end to end. Alone, the debt hidden in a dependency costs more than the extra line.
• No end to end tests in the first version. I test the logic I cannot verify by eye. Building a full suite for a product that might close in three months is time spent protecting something that does not exist yet.

That last point holds only while the product is a hypothesis. The moment someone pays, it changes: from there tests matter, because breaking something that works has a real cost.

The order I build in

1. A page explaining the product, before the product. If I cannot write it so it lands without preamble, the problem is not clear to me either.
2. The shortest path that solves the problem once. No accounts, no settings, no payments. Just the thing that has to work.
3. Authentication and database, as soon as the path needs repeating by the same person. Not before.
4. One number to watch. How many people come back. Before adding any feature.
5. Payments. Early, not late. The moment someone pays is the only unambiguous test of value that exists.
6. Everything else, only if the number in step four moves.

The order is designed for one thing: getting as fast as possible to the moment where I can find out I am wrong. Twenty four months spent building features instead of verifying the premise taught me that moment has to be pulled forward, not pushed back.

Frequently asked questions

How long does it take you to put the first version of a product online?

With this stack, the technical part up to a usable product online is days, not weeks. The long part has never been building: it is working out what is worth building.

Why Supabase instead of a hand written backend?

Because authentication and access rules are the part where it is easiest to do damage and where there is no competitive advantage in rebuilding from scratch. With rules at the database level, data access is enforced in one place.

Do you need to know how to code to use this stack?

Yes. AI reduces writing time, not the need to understand what you are reading. Without that, you cannot tell a correct answer from a plausible one.

Would you change anything working in a team?

I would add tests from the start and a written convention for how things get done. Alone those rules live in my head; with more people, a head is not a shared place.