The starter stack: launching a product without overbuilding

I've started a lot of things: a consulting business, e-commerce systems, a SaaS platform, a hardware product. The pattern I keep seeing in early-stage projects — mine included — is overbuilding. Too much infrastructure, too early, for customers who don't exist yet.

This is the starter stack I use now, and the order I add things in.

Stage 0: prove someone cares

Before any code:

• Write the problem in one sentence, from the customer's side.
• Talk to five people who have that problem.
• Put up a single page that explains the solution and has one call to action.

If nobody clicks, you just saved months.

Stage 1: the smallest real thing

Pick tools that let one person build quickly and change their mind cheaply:

• Front end: a static site or a simple template. No framework unless you need interactivity.
• Back end (if needed): one FastAPI service.
• Database: SQLite for a prototype, PostgreSQL once there are real users.
• Hosting: a platform that deploys from git with one click, like Railway.
• Payments: a hosted checkout. Never build payments yourself.
• Email: a transactional email service plus one automation tool.

For hardware, the equivalent is a dev board, a breadboard and a 3D-printed shell — not a custom PCB.

Stage 2: instrument everything

Before adding features, add visibility:

• Basic, privacy-respecting analytics.
• Error logging that alerts you.
• A simple dashboard of the three numbers that matter (signups, activation, revenue — or whatever your three are).

You can't improve what you can't see.

Stage 3: automate what hurts

Only now do I add automation — and only for tasks I've done by hand enough times to understand. Onboarding emails, data syncs, reports. Automating a process you don't understand just makes mistakes faster.

Stage 4: harden what's working

Customers paying? Usage growing? Now it's worth:

• Tests around the core logic.
• Backups you've actually restored.
• A staging environment.
• For hardware: a custom PCB, an enclosure built for assembly and a real bring-up process.

Things I deliberately postpone

• Microservices. One service until it actually hurts.
• Kubernetes. You probably don't need it, and you definitely don't need it yet.
• Custom design systems. Use a clean, simple style and revisit later.
• Perfect scalability. Scaling problems are what success looks like. Solve them when you have them.
• Custom hardware before the experience is proven on dev boards.

Why this works

Each stage answers a question before you pay for the next one. Does anyone care? Can I deliver it? Is it working? Is it worth hardening? Skipping ahead means paying for answers you don't have yet.

The mindset

A starter stack isn't about specific tools. It's about choosing boring, reversible decisions early so you can spend your energy on the only thing that matters at the start: finding out whether you're building something people want.