My stack for shipping a web app alone

This is the stack I built Startupage with, and the one behind the site you are reading. Every website I run is built this way.

Eight tools: six I use on any project, and two that are there because it is web. On mobile the stack changes at the top and stays identical underneath, and I wrote that one up in my stack for a mobile app.

The criterion I picked them with 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 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: auth, deploys, transactional email and database schema are decisions already made, and the time goes into the product.

Another stack would do just as well. What would not do is changing it 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 goes" and "I am finding out now".

The two pieces that make it a web app

Next.js: the framework for anything web. App Router, static rendering wherever possible. The reason I keep it is not the framework itself, it is that rendering, routing, image handling and APIs live in one project: alone, every separate piece stitched together by hand is a piece I then have to maintain.

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 goes to production. Alone there is nobody reviewing my code, and looking at the real thing before publishing it is the closest substitute for a review.

The six that stay the same either way

Supabase: Postgres database, auth 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.

Resend: transactional email and the newsletter. One thing that does one thing. System email is the part nobody looks at until it lands in spam, and keeping it on a service that does only that means never having to think about it.

PostHog: product analytics. How I use it is further down, because that is more interesting than the fact that I do.

Featurebase: help centre and feedback. Alone you have no support team, so you need somewhere requests pile up, get voted on and stay readable, instead of disappearing into an inbox.

Namecheap: domains. Nothing romantic about it, but keeping them in one place avoids the scramble over a renewal that lapsed.

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

What I do not use, on purpose

• I do not look at everything PostHog can do. Early on you need one number: how many people come back the following week. Funnels and heatmaps are an elegant way of not looking at it. They get useful later, once there is enough traffic for them to say anything.
• 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 check 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 while the product is a hypothesis. The moment someone pays it changes: from there tests earn their keep, 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. Auth and database, as soon as that 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 there is.
6. Everything else, only if the number at 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 three months spent building a product too big for what we had taught me that moment should be pulled forward, not pushed back.