One week is enough to deploy a real, billable SaaS, but only if you accept that six of the seven days go to things that are not your idea. This plan front-loads every irreversible decision into day one and treats the feature you care about as a day-four problem. Most one-week attempts fail because they invert that order and discover on day six that payments do not work.
Day 0: define the finish line, then decide everything irreversible
What "deployed" means here
Deployed means live on a real domain, where a stranger who has never spoken to you can sign up, pay, and complete the core action. Not a demo you drive, not a video, not a waitlist.
What does not count: polish, a settings page, an admin dashboard, onboarding emails, a second pricing tier, a marketing site with more than one page, and anything you would describe as cleaning up. Every one is legitimate work for week three. None is on the path to a stranger paying you.
A narrow definition is the only thing that makes the timeline honest. "Ship in a week" is meaningless when the definition of shipped floats, and it will float, because the response to being behind is to quietly redefine done. Write it down before you start.
The hour that decides the week
Spend the first hour writing two sentences. The first says what the product does, without conjunctions. The second names the single action a paying user takes. Everything not on the path between signup and that action is out of scope, and having it written down is what lets you cut later without renegotiating.
Then decide the stack, before any code exists. Leave it open and every agent session re-litigates it, which is the argument in choose your stack before you prompt. The tech stack recommender narrows it to a couple of viable combinations.
Finally, pick the foundation. Realistically that means a kit from the Agent-Ready category, where the criterion is how well a coding agent works inside the repo, not how nice the landing page looks. Starting from scratch means choosing a three-week timeline instead. If the category is new to you, what a SaaS boilerplate is explains what you are buying.
Day 1: foundation and deploy pipeline
Get the kit deployed to production, on the real domain, with DNS pointed and TLS working, before you write a line of your own code. Deploying an unmodified kit is a five-minute problem. Deploying a kit you modified for five days is a day-long problem, because every failure is ambiguous between your code, the platform, and the config.
The rest of the day is environment variables in production as well as locally, a real database rather than a local file you will regret, and error tracking wired up so that when something breaks on day six you hear it from a notification rather than a customer. Skipping this moves the work to the end of the week where it costs more.
Close the day by writing the agent brief: an AGENTS.md with a stack summary, the commands for dev, tests, and migrations, a directory map, one blessed pattern per concern, and a do-not-touch list covering billing webhooks and migration history. The AGENTS.md template gives you the structure and the AGENTS.md generator drafts it against your stack.
Day 2: auth and billing verified, not assumed
Day two exists because the money path is the one thing you cannot fake later. A subscription that does not activate is a product that does not exist, and finding that out on day seven means there is no day seven.
Verify it as a user, not as a developer reading code. Fresh browser, an email you have not used, a real test card, then confirm the state round-trips: your database says the user is subscribed, the gated feature is gated for a free account, canceling flips it back. Then fire the webhook twice and confirm you do not double-provision.
Webhooks deserve attention, because they are where most kits are thinnest and agents least reliable. You need signature verification, idempotency keyed on the event ID, and something durable to inspect when an event does not arrive. The choice underneath, including whether your provider handles tax as merchant of record, is in the SaaS payments decision guide.
If the kit's auth or billing is not working by the end of day two, change kits rather than debugging someone else's integration for three days. A kit whose core value proposition does not work out of the box is telling you about its maintenance.
Day 3: the data model
The schema is the one thing you should not let the agent decide, because everything generated afterward inherits it. An agent will happily produce a reasonable schema from a two-sentence description that turns out to have the wrong ownership model, and discovering that on day five means starting over.
The decisions that matter are ownership and scope. Does a resource belong to a user or a workspace. Can a user belong to more than one workspace. Is the paid thing attached to an account or a seat. Get these right and the agent can generate all the tables. Get them wrong and no generated code helps, because the mistake is in the shape, not the syntax.
Keep it small: the fewest tables that support the single paid action from day zero. Resist the modeling instinct that wants an organizations table you do not need yet, soft deletes for data nobody created, and an audit log with no auditor. If the database and query layer are still open, close them with the SaaS database decision guide.
Day 4: the actual product
Day four is the only day spent on the thing that makes your product different, and that is correct rather than alarming. The unique part of most SaaS products is small: a transformation, a view of some data, an integration, a workflow. It takes people three months only because they build it on top of three months of plumbing.
Work in vertical slices with the agent: a route, its handler, a test, and a migration if it needs one, in one diff you can verify by clicking the thing. A slice that is wrong costs an hour. A layer that is wrong costs the day, because nothing works until the last piece lands.
Expect this day to be the most satisfying and the most dangerous, because it is where scope grows. Every slice suggests two more. Write them down, do not build them. The build loop mechanics are in starting a SaaS with AI agents.
Day 5: the unglamorous list
Terms of service and a privacy policy, because payment providers ask for them and you are collecting personal data. Transactional email that actually delivers, verified by sending to a real inbox rather than by seeing a 200 response. A 404 that does not leak a stack trace. Rate limiting on signup and anything expensive. And one landing page stating what the product does, who it is for, and what it costs.
The landing page copy is the most common self-inflicted delay of the week, and not because writing is hard. Writing the offer forces you to admit what the product is, in a sentence, with a price attached, which is uncomfortable in a way refactoring is not. If you cannot write the sentence, you have a product problem.
Close the day with one narrow security pass. Read every query that returns user data and confirm it filters by the session's identity rather than an ID from the request. Read every route that mutates something and confirm the permission check happens before the mutation, not in the UI. That targets the class of bug agents produce most and testing catches least, because with one account in your database these look like working software.
Days 6 and 7: use it as a stranger, then ship it
Day 6: buy your own product
Fresh browser profile, no saved sessions, an email you have never used, a real payment. Go through the entire flow as someone who has never seen it. Take notes and fix nothing until you reach the end, because stopping to fix means you never see the rest of the path.
Then fix only what blocks that path. A confusing button people still click is not a blocker. A form that rejects valid input is. The polish spiral is the most reliable way to lose day seven. Log the rest as post-launch work.
Before you finish, set up the one analytics event that tells you whether a stranger completed the paid action. Not a dashboard, not funnels. One event, fired on success.
Day 7: publish and tell people
Publish in the morning, then spend the rest of the day on distribution. This is the day most builders skip, and the reason most one-week builds are never seen. The pull is to spend it making the product slightly better, because that is work you know how to do. Nobody is looking at it.
Concretely: post where your users already are, usually one or two specific subreddits or forums rather than a general launch site. Write individually to the ten people you know who have the problem. Post a short build log wherever you have an audience, however small. If your space has a directory or newsletter, submit to it. The build was never the hard part. This is, which is why it gets a whole day.
When you fall behind
You will fall behind, probably on day four. Cut in this order. Custom UI first: use the kit's components as they ship, including the ugly ones, because nobody declines to buy working software over border radius. Next, non-core features, anything not on the line between signup and the paid action. Next, the second pricing tier. Last, anything on day five that is not legally required.
Two things never get cut. The payment path has to work end to end, because a product that cannot take money is not a business. And permission checks on user data have to be real, because a bug that shows one customer another's data is the kind of thing you have to email people about.
The honest failure signal is day two. If you reach the end of it without working auth and billing, verified by you as a real user, then either the timeline is wrong for this product or the foundation is wrong for this timeline. Proceeding anyway means finding out on day seven.
Frequently Asked Questions
Is one week realistic for a first-time builder?
It is realistic for a narrow product on a maintained foundation, and unrealistic from scratch or with a fuzzy scope, regardless of how fast you work. The week only fits because auth, billing, email, and deployment are already solved when you start, so it depends on choosing a kit that works rather than one you spend three days repairing. What breaks the timeline is not inexperience, it is a product definition that grows mid-week.
What if I do not have a boilerplate?
The week becomes roughly three. Day one becomes three or four days of setup and deployment config, day two becomes a week of auth and billing including webhook edge cases you have not thought of, and day three grows because you are designing the schema without a working example in front of you. Days four through seven stay the same, which tells you where the cost lives. To buy that time back, look at kits scored for agent readiness, or start from the best Next.js boilerplates for 2026.
Should I write code myself or let the agent do it?
Agent for volume, you for the decisions and the review. The agent should produce the CRUD surfaces, forms, routes that mirror existing routes, tests, and migrations, most of the code by line count. You own the schema, the auth and tenancy model, and the review of anything touching money or another user's data. The failure mode is not the agent writing too much, it is merging what it wrote without reading the diff.
What can I safely skip before launch?
Onboarding flows, settings pages, an admin panel, a second pricing tier, dark mode, and mobile polish beyond the app being usable on a phone. Also the marketing site beyond one page, the blog, and the roadmap. None affect whether a stranger can sign up, pay, and get value. The ones that feel most necessary, usually settings and onboarding, are the least necessary at zero customers, because you do not know what people want to configure or where they get stuck.
What happens in week two?
Week two is customers, not features. Talk to everyone who signed up, watch where they stopped, and fix only what stopped them. The backlog from day six stays untouched until a real person asks for something on it, and most of it never gets asked for, which is the point of not having built it. The pull is to return to building, because building is comfortable and an empty user list is not.
