An opinionated, day-by-day plan for the first 7 days of a solo SaaS — what to do, what to skip, and the mistakes that compound from day 1.
Methodology. This is an opinionated playbook informed by Pieter Levels, Marc Lou, Tony Dinh, and dozens of other public solo-founder build logs — not a universal script.
The default week 1 looks like this: a Saturday browsing tech-stack tweets, three days hand-rolling auth, an evening picking a logo, a frantic Friday realizing nothing has shipped. The founder ends with a half-built dashboard for a product they have not confirmed anyone wants. Week 2 starts with the same uncertainty, except now there is sunk-cost code to defend.
The plan below inverts that. Week 1 is the validation week, not the building week. The product is downstream of validation, the stack is downstream of the product, and the only build work in week 1 is the smallest artifact that earns a real signal. Founders who end week 1 with a deployed landing page and a one-sentence positioning statement are weeks ahead of founders with a private GitHub repo full of clever code.
Day 1 is a thinking day. No code, no design, no tool selection. The output is one paragraph that answers three questions.
Who is this for, specifically? Not “small businesses” or “creators” or “teams.” A specific role at a specific company size in a specific industry. “Operations managers at five-to-fifty-person Shopify stores.” If the answer fits a category like “modern teams,” you have not done the work yet.
What problem are they having that they would actually pay to solve? Not a problem you think they should care about — one they are actively complaining about, googling for, or working around with a spreadsheet. You should be able to name a real human who has voiced the problem in the last 30 days.
What is the simplest thing that would solve enough of the problem to be worth paying for? The trap is to answer with a feature list. The right answer is a single workflow — one thing the user does, start to finish, that produces enough value they would not want to live without it. Most successful solo SaaS at launch is one workflow done well, not a platform.
By the end of day 1 you should have ten conversations scheduled or already started. Not a hundred — ten. The right ten match your customer description and have voiced the problem. The conversations are listening sessions, not pitches. The key question, asked late: “if a tool existed that did exactly this, would you pay for it, and roughly how much?”
The answers fall into three buckets. Enthusiastic vagueness (“yeah, sounds great, I’d definitely use that”) is politeness, not a yes. Specific objection (“I’d pay for it, but only if it integrated with X”) is closer to a yes — the prospect is engaging with trade-offs. Volunteered urgency — the prospect interrupts to ask when they can try it — is the only signal that justifies building. Three or more bucket-two prospects is enough to keep going. Bucket one alone is a trap.
Day 1 is the right day to abandon. Abandoning costs six hours of thinking on day 1, and two months of work on day 60. The signal: consistent inability to find a specific customer with a specific problem. If every conversation ends in “hmm, I could see that being useful,” the idea has no urgency — and urgency is the only currency that matters.
Day 2 is the bounded version of research. Open-ended research is how week 1 dies — you scroll Reddit at 9am and surface at 5pm with twenty tabs and no decisions. Three focused hours, one-page output.
Five searches, twenty minutes each. Reddit for the verb form of the problem (“how do you handle X”) — you want the customer’s language. Twitter/X for the same phrasing — recency tells you whether the problem is current. Hacker News for the category — HN comments are unusually candid. G2 and Capterra reviews of the closest tools, sorted by negative — this is where customers tell you what is missing in the alternatives. YouTube tutorials for the problem — if people are making 20-minute tutorials about a workaround, the workaround is painful enough to motivate a real product. Save the five most useful threads to a single document.
Negative G2 and Capterra reviews are gold — paying customers describing what is broken. The pattern to look for is repeated complaints across reviewers. Seven reviewers mentioning the same shortcoming is a real gap. Twenty reviewers mentioning twenty different shortcomings is a tool that just is not very good, and your opportunity is to do the basics well, not to fix any specific gap.
The day-2 summary answers one question: does this problem have urgency, or just sympathy? Urgency looks like specific complaints with dates, paying customers churning, people building brittle workarounds. Sympathy looks like agreement that the problem exists without anyone being notably bothered. Build for urgency. If your dossier is mostly sympathy, pivot or set the idea down.
By day 3 you know who the customer is, what the problem is, and what the simplest solution looks like. The work is to write that down as a positioning statement — one sentence, in a specific format, that becomes the spine of every subsequent decision.
The template, from April Dunford: “[Product] is a [category] for [specific customer] who want [specific value], unlike [alternative they currently use].” Example: “Tally is a form builder for indie founders who want unlimited free responses, unlike Typeform.” Dull on purpose — clarity beats cleverness. If your sentence cannot fit the template, it is a wish, not a positioning statement.
The hardest blank is the “unlike” clause. Founders want to position against giants (“unlike Notion”) because the giant is recognizable. Almost always a mistake. The viable alternative is whatever your customer would actually use today: a spreadsheet, a Notion template, an old tool, nothing. Full mechanics in the complete guide to SaaS positioning.
The most predictable week-1 failure is deferring positioning to “after the product ships.” Every decision in days 4 through 7 then becomes ambiguous — what to prioritize, what the landing page says, who to talk to. Without the sentence, founders build broadly and market vaguely.
The MVP is the minimum thing that gives a real customer real value. The discipline is to define it as the smallest set of features that solves one workflow well, and be explicit about what is being cut.
Building solo, the week-1 MVP has four features or fewer. Pieter Levels has shipped products with two; Marc Lou’s ship-fast philosophy lives at three. Above four, you are building an ambitious product, which is fine — but ambitious products do not ship in one week.
Features are user-facing capabilities, not infrastructure. Auth is plumbing, not a feature. Features are things the user does — create, share, automate, see. Pick four. Write them down.
Three categories consume week-1 time without contributing to validation. The settings page — settings can be edited in the database for the first ten users. Dark mode — loved by users, but does not change whether the product is worth paying for. Marketing-site v1 with hero animations — week 1’s site is one page with a headline and an email form. Founders cut these reluctantly because the absence feels unprofessional. Early users do not notice.
Pick one user flow and make it work end-to-end. Sign up, do the core thing, see the result, save or share it. Every other flow can be broken. The single working flow is what you demo, what your landing page links to, what the first ten users use. If it works, the product exists.
Day 5 is the day most founders waste. The trap is treating stack selection as a strategic decision. It is not. For 95% of solo SaaS in 2026, the right stack is boring — pick it and never think about it again.
Next.js for the front-end and API routes. Supabase for database, auth, and file storage. Stripe for payments. Vercel for deploy. Resend for transactional email. Total cost at launch is roughly the price of a domain. Time-to-deploy is hours, not days. The reason to default to this stack is not that it is the best — it is that the questions it cannot answer are not the questions you have in week 1. You have no users; you do not need to optimize for scale. You are one developer; you do not need to choose between micro-frontends. Full reasoning in the solo founder tech stack guide.
Deviate in two cases only. First, if you are already an expert in a different stack — Rails, Django, Python — use what you know. The cost of learning Next.js while shipping is more than the cost of using your existing stack. Second, if the product genuinely requires non-standard architecture (real-time multiplayer, heavy ML inference, desktop app), the boring web stack does not fit. Outside these two cases, deviation is procrastination. Founders who pick week 1 to learn a new framework consistently end week 1 without a deployed product.
Day 6 is the deployment day. Take whatever exists and put it on the public internet, with a real domain, behind a real signup form, in front of real people. The goal is not to ship the product — it is to ship the smallest deployable artifact that produces a real signal.
The minimum artifact: a one-page landing page on a real domain. Headline (your positioning statement, sharpened), subhead, brief description, one email capture form. No pricing, no feature grid, no testimonials. Vercel hosts it free. Buy a real domain — not a free subdomain — because the domain signals seriousness.
Send the URL to five people who match your customer description. After thirty seconds, ask what the product does, who it is for, and whether they would sign up. This tells you in a single afternoon whether the headline lands, whether the value prop is clear, whether the design is creating friction. The version in the wild is the 5-second test from the landing-page guide.
Shipped does not mean polished. It means deployed and getting feedback. Placeholder image, rough copy, wrong button color — none of it matters in week 1. Founders who wait until the page is “ready” take eight weeks to ship what should have shipped in one. Polish comes from iteration; iteration requires the page to be live.
The final day is planning. Look at what week 1 produced, decide whether to commit to week 2, write down what week 2 will do.
Did anyone in my target audience react with urgency to the landing page? Email signups, replies to outreach, comments, friend-test feedback. If none of the signals are urgency-shaped, week 2 is more validation, not building. Did my day-1 and day-2 conversations produce specific commitments? Three to five people who said “tell me when it is ready” with their email address is the floor. Do I still believe the positioning statement? Sometimes a week of conversations reveals the customer or the value was misnamed. Update before week 2 starts.
Reassess if any of the three is a clear no. Keep going if all three are yes-or-yes-with-caveats. The middle ground — one yes, one maybe, one no — is the dangerous spot; spend a few more days on the no before committing. The cost of an additional validation week is small; the cost of building for two months on an unvalidated premise is large. Bias toward the cheaper mistake.
Over-building before the first user signal. Founders who got 50 email signups in week 1 spend week 2 on auth, settings, an admin dashboard, and billing — and end week 2 still without anyone using the product. Invert it: take the five most engaged signups, send them a private link to the bare-minimum product, let them try it before anything else gets built. Their feedback beats any internal feature decision.
This plan is not what most founders do. Most spend day 1 picking a stack, day 2 designing a logo, day 3 building auth, day 4 on a settings UI, day 5 reading framework docs, day 6 wiring Stripe before there is anything to charge for, and day 7 starting to think about marketing. The end of week 1: a half-built product with no users, no positioning, no validation.
The founders who ship in twelve weeks — and who eventually charge money — invert the order. They validate before they build. They write the positioning statement before the code. They put a one-page landing page in front of real customers before they decide what to ship. They use the boring stack and skip the bike-shed. They end week 1 with a real signal, a sharp sentence, and a small artifact in the world. Over twelve weeks, that compounds into the difference between a product that exists and one that does not.
Week 1 is the smallest investment that determines the largest outcome — and the week most likely to be wasted. Next: how to validate a SaaS idea in 48 hours for the deeper drill on days 1–3, and the solo founder launch checklist for what comes after.
The stack, prompts, pricing, and mistakes to avoid — for solo founders building with AI.