Build a website first if you need to be found and sell; a web app if your users need to do something repeatedly behind a login; a SaaS if that something is the product people pay for. Most founders should start with the smallest piece that proves demand — usually a site or a single app workflow — and expand only once real usage justifies the next step. Picking the wrong one first is the most expensive mistake in the whole project, because it sets the budget and the timeline before you've learned anything.
When should you build a website first?
Start with a website when your goal is to be found, look credible, and turn visitors into leads or sales. If you mostly need acquisition — pages that rank in Google, explain your offer, and convert — a site or a focused landing page is the cheapest path to traction. It's also the foundation everything else links back to: even a future app or SaaS still needs a marketing site in front of it. A focused launch runs around $1.5K and ships in 2 to 4 weeks, so you can be live and learning while a bigger build would still be in planning. The signal you only need a site: your value is in what you say and sell, not in something users log in to do. If you're a service business, a studio, an author, or a local company, this is almost always the right first move — and often the only one you need for a long time. See my websites service.
When do you need a web app, not a site?
You need a web app when users log in and do something repeatedly — a dashboard, a client portal, an internal tool, a booking system. The tell is state: you're tracking data per user that changes over time, not merely publishing pages everyone sees. A site answers "what do you offer?"; an app answers "let me do my thing." That's web-app territory, and it's a bigger, more expensive build than a marketing site — auth, a real data model, per-user views — so it should earn its place. Build it when a repeated, logged-in task is the actual job to be done, not because an app sounds more impressive than a site. If you can't name the one workflow users will return to each week, you're not ready for an app yet.
When is it actually a SaaS?
It's a SaaS when the workflow itself is the product people subscribe to — auth, billing, and multi-user data at the core, sold as an ongoing service. The difference between a web app and a SaaS is mostly commercial: a web app might be an internal tool you run, while a SaaS is a product strangers pay you monthly to use. That raises the bar — you need billing, multi-tenancy, and reliability earlier. A SaaS MVP usually runs $8K and up over 6 to 10 weeks (see how much a SaaS MVP costs). Don't build a SaaS to test an idea a landing page could validate first and far cheaper — a simple "fake door" page that measures real signups can prove demand for a fraction of a full build.
What's the most common mistake here?
Building too big, too early. Founders routinely jump to a full SaaS when a landing page or a single app workflow would have answered the real question — does anyone actually want this? — for a tenth of the cost. The reverse happens too: stretching a marketing site to do a logged-in job it was never built for, until it's a fragile tangle of plugins. The fix is the same in both directions: name the question you need answered next, and build the smallest thing that answers it. Scope to the question, not to the ambition — the ambition can wait for evidence.
How do these stack over time?
They're a sequence, not a fork. The common path is website first (get found, prove demand, start selling), then a web app when a repeated logged-in need appears, then SaaS if that workflow becomes a product others will pay for. Each step reuses the last — the site stays the front door, the app becomes the product behind the login. You rarely need all three on day one, and trying to build them at once is how budgets and timelines blow up. Start at the step your evidence supports, and let real usage pull you to the next one.
How do I decide with a founder?
I pick by the goal, not the hype. I name the one outcome that matters — a booked call, a paying subscriber, a completed task — then build the smallest thing that proves it: a site, one app workflow, or a single SaaS loop. I shipped Little Chubby Press as a website and Coloring Forge as a production SaaS on this same "smallest proof first" rule, and in both cases the first version was deliberately narrow. It's the model behind all three service lanes. The right first build is whichever one tests your riskiest assumption fastest and cheapest.
Related strategy guides
Next, read how to scope an MVP and how to budget a software project. For the cost side, see how much a SaaS MVP costs.
Not sure which to build? Tell me what you're trying to prove — I'll point you at the smallest first step.
