Where to Start

The Honest Starting Point

Most first-time founders spend weeks picking a tech stack before writing a single line of code. That is usually the wrong move. The stack choice matters far less than getting something real in front of real users.

The single most important question before any technical decision: can someone use this in 30 days?

If the answer requires a six-month build, you are over-engineering. If the answer is a landing page with an email form, start there.

Validate Before You Build

Before writing code, confirm that someone will pay for what you are building.

The fastest validation tools are non-technical:

• A Typeform or Google Form collecting emails
• A Notion page describing the product (share the link)
• A manual "Wizard of Oz" version — you do the work by hand while the user thinks software is doing it
• A simple landing page with a waitlist (Carrd, Framer, or even a tweet)

You do not need a database, an API, or a React app to find out if people want your product.

Define the Problem Precisely

Write one sentence in this format:

[User type] struggle to [do X] because [Y], so they [bad workaround].

Example: "Freelance designers struggle to chase late invoices because email follow-ups feel awkward, so they write them off or give discounts."

If you cannot write this sentence, you do not understand the problem well enough to build a solution. Talk to 10 potential users before writing any code.

Decide What You Are Actually Building

Most startups fall into one of these categories — each has different technical implications:

Your category determines which backend and infrastructure patterns make sense.

The Fastest Path to an MVP

For a typical SaaS or consumer web app, the fastest path looks like this:

1. Landing page — Framer or Next.js with a waitlist form (1–2 days)
2. Auth — Clerk or Supabase Auth (half a day)
3. Database — Supabase Postgres or Neon (both have free tiers) (1 day)
4. Core feature — one workflow that delivers the main value (1–3 weeks)
5. Payments — Stripe Checkout (1 day)
6. Deploy — Vercel or Railway (1–2 hours)

A solo developer can ship this in 3–5 weeks. A two-person team can do it in 2.

The whole app skeleton is one command plus a component library:

npx create-next-app@latest my-app --typescript --tailwind --eslint --app
cd my-app
npx shadcn@latest init
npx shadcn@latest add button card input dialog

Common Mistakes to Avoid at the Start

• Building mobile-first before web — web is faster to iterate, easier to share, and free of App Store delays. Build web first, add mobile later if usage justifies it.
• Over-designing the data model — start with flat tables and simple schemas. Normalize later when you understand the access patterns.
• Picking microservices from day one — a monolith is almost always the right call for an MVP. Split only when you have a specific reason to.
• Spending weeks on design — ship an ugly version that works. Users will tell you what matters.
• Not tracking anything — add PostHog or Google Analytics on day one. You need data to make decisions.

Minimum Viable Tech Decisions

You only need to decide three things before writing your first line of product code:

1. Frontend framework — Next.js is the default unless you have a reason not to use it
2. Backend / database — Supabase for most things; a custom Express/Node server only if Supabase does not fit
3. Hosting — Vercel for the frontend, Supabase or Railway for the backend

Everything else — AI, payments, email, realtime — gets added incrementally when you need it.

When to Hire vs. When to Learn

If you are non-technical:

• Learn enough to read code and make small changes — this is a 2–4 week investment with freeCodeCamp or a course
• Use Cursor or v0.dev to generate boilerplate; review and edit rather than write from scratch
• Hire a part-time contractor for the first build, but own the repo and understand the architecture

If you are technical but not a specialist in a given area (mobile, ML, etc.):

• Stay in your lane for the MVP — build the thing you can build fastest
• Hire for the skill gap only when user demand proves it is worth the cost