A French primary-school teacher mentioned at a dinner that she spent her Sunday evenings copy-pasting last year's lesson plans into a Word document and adjusting them for this year's class. She used the phrase "I lose two hours every Sunday I will never get back". Six weeks later, PrepareMesCours.fr was live with paying customers and the same teacher had her Sunday evening back. The "ship SaaS in 6 weeks" arc is real, but most public versions of it leave out the brutal cuts. This is the honest version.
Week 0: the dinner
Friday night dinner. The teacher complains about her Sunday workflow. We ask the obvious question: "if a tool generated a draft lesson plan for you, with the right level, the right duration, and the right curriculum reference, would you pay 10 EUR a month for it?" She says yes without hesitating.
We spend the weekend writing down what the product needs to do, in the simplest possible terms. It needs to:
- Take a topic, a level, a duration.
- Produce a lesson plan in the format French primary-school teachers actually use.
- Reference the official curriculum (the Bulletin Officiel).
- Output a printable PDF.
That is the spec. Four bullet points. We do not write a "vision document". We do not make a Notion. We make a single page in a notebook and we start.
The shortest path from idea to production runs through resisting the urge to plan. Start.
Week 1: the boring infrastructure
Monday we set up the codebase. Next.js 15, TypeScript, Tailwind, Postgres on our Proxmox host, MinIO for asset storage, OpenRouter for LLM calls. We use the same skeleton we have used twice before because reusing the skeleton saves four days.
By Wednesday the auth flow works (email + magic link, no social login, no password reset flow yet). By Friday the multi-tenant database schema is in place. We did not have a customer yet, but we knew from prior products that retrofitting tenancy is expensive. We covered the full reasoning in our day-one multi-tenant playbook.
Week 1 is unglamorous. We did not generate a single lesson plan. We laid the foundation. The temptation to skip this and demo something cool is real and it is wrong. The infrastructure is the part that lets you ship in week 6.
Week 2: the first generation that did not embarrass us
We build a dirty version of the lesson-plan generator. The user fills a form, we call an LLM with a prompt template, we display the output as plain text. No styling. No PDF. No multi-step flow.
The first 15 generations are bad. The model writes plans that no French primary-school teacher would recognize. We rewrite the prompt three times. By Wednesday we have something that, when shown to our teacher friend, gets a "wait, this is actually usable" reaction. That is the bar.
The lesson here is that prompt engineering for a specific domain is real work. The prompt that makes the model behave like a French primary-school pedagogue is not the same as the prompt that makes it write a tech article. We tested a dozen variations. We kept the one the domain expert blessed.
By Friday of week 2, we can take a topic and produce a lesson plan that is in the right format, references the right curriculum, and respects the right pedagogical conventions. It is ugly on the screen. It is correct in the content.
Week 3: the polished surface
Week 3 is the fun part. The product gets a UI that looks like something. A landing page. A pricing page (we copy our other product's pricing structure as a placeholder). The form for generating a lesson plan becomes a multi-step wizard with sensible defaults.
We integrate Stripe. We pick three plan tiers (Free trial, Standard, Pro) with hard usage caps. We discussed the pricing AI features for SMBs reasoning in detail elsewhere; we used the same model from day one for PMC.
By Friday of week 3, the product is end-to-end. A teacher can sign up, generate 5 free lesson plans, see the cap, upgrade to Standard, and use the product. The PDF export still does not exist. The email notifications do not exist. There is no support ticket system. Lots of things do not exist.
That is the trade. Ship one core flow that works, defer everything else.
Week 4: the launch (small, deliberate)
Week 4 was the launch. Not a Product Hunt blast. A WhatsApp message to our teacher friend with the link and "try this, tell me what is wrong".
She tried it. She broke it twice. The first time, the form crashed when the topic field was empty. The second time, the generation timed out for a long-form lesson plan because we had no streaming yet. We fixed both within the day.
By Wednesday, six teachers from her school had tried it. By Friday, we had our first paying customer. She paid 11 EUR for a Standard plan and used 23 generations in 4 days.
The hardest part of week 4 was not engineering. It was sitting on our hands while teachers tried things, watching our analytics (such as it was at the time) for 20 minutes after a signup, and resisting the urge to call them and ask "what did you think?" Patience is the muscle. We talked about the customer development discipline using the Mom Test elsewhere because it was a different muscle to learn.
Week 5: the painful list of "what should have shipped in week 1"
Week 5 was paying down the deferred work.
PDF export, because three of the first 8 customers asked for it. Two days.
Email notifications, because customers wanted a reminder when their generation was ready (we had no streaming yet so generations took 25 to 40 seconds). One day.
A "regenerate this section" button, because customers were generating, getting one section wrong, and re-running the whole generation. Saved cost, improved UX. Two days.
Better pricing-page copy, because the original copy was a placeholder. One day.
The lesson here is that the things you skip in weeks 1 to 4 do not stay skipped. They come back. Plan for "week 5 is paying off the technical debt" and you will not be surprised.
Week 6: the second customer cohort and the production polish
Week 6 was the moment the "ship SaaS in 6 weeks" arc completes. We had 18 paying customers. The infrastructure was holding. The LLM costs were under control. The product was generating revenue.
We added analytics (this was the early version that became our migration story, written about in the PostHog vs Umami self-hosted post a year later). We added a status page. We started writing the very first SEO content.
By the end of week 6, the product was launched, profitable on a unit basis, and had real customers. It was not finished. It was shipped.
The cuts we made (and would make again)
We deliberately did not build:
- Mobile-optimized UI. Teachers used desktops on their planning evenings. Mobile waited until month 3.
- Multi-language support. Pure French. No i18n abstraction yet. We added that later when we forked DraftMyLesson.
- A "share with another teacher" feature. Sounded nice. Nobody asked. Built in month 5 when 3 customers asked.
- Custom curriculum mappings. Worked with the official Bulletin Officiel only. Custom maps came in month 4 when private schools asked.
- A team/org tier. Single-user only. Org features came when school-level customers signed up.
Each of these cuts saved roughly a week. Six cuts. Six weeks saved. That is the ship-in-6-weeks math.
The cuts that hurt later
Two cuts we regretted:
- No analytics from week 1. We could not answer "of the 100 visitors to the pricing page, how many clicked Stripe?" for the first 6 weeks of operation. We were flying blind. The fix took half a day. We wish we had done it on day 1.
- Generic email templates. We used Stripe's default emails for the first 8 weeks. They felt corporate and clashed with the rest of the product's voice. Fixing them when we did was easy. Doing it earlier would have cost us almost nothing.
The pattern: the cuts that hurt were not feature cuts. They were observability and trust cuts. Those are different. Cut features. Do not cut your ability to see what is happening.
What made the 6 weeks possible
Three enablers:
- A boring stack we already knew. Next.js, Postgres, Stripe. Zero novel technology. Every minute spent learning a new framework is a minute not spent on the product.
- A pre-built skeleton from prior products. We did not start from
npx create-next-app. We started from a working multi-tenant skeleton. - Aggressive use of Claude Code for the implementation. The 1M-context window is the difference between "I know I wrote that pattern in another product, where was it?" and "the agent already has the full context of all four products and can scaffold the new one consistently". We covered that workflow in our why we use Claude Code deep dive.
The fourth enabler is the one nobody puts in the productivity post: a domain expert who would tell us when we shipped something dumb. The teacher friend was the most important member of the team for those six weeks.
When 6 weeks is the wrong target
Sometimes 6 weeks is too aggressive. We have learned three signals:
- The domain has serious regulatory requirements. Carriva took 18 months for a reason. You cannot ship a regulated AI tool in 6 weeks. We tried for the prototype and only the very basic version survived; the production-ready version took the full 18.
- The product requires a custom data pipeline. If your MVP needs you to parse PDFs from 14 layouts, that is not a 6-week scope.
- The buyers are slow. Six weeks of building does not matter if the buying cycle is 9 months. Plan accordingly.
For most B2B SaaS targeting individual professionals (teachers, advisors, single-cabinet shops), 6 weeks is achievable. For enterprise SaaS, it is not the right metric.
What is next for PrepareMesCours
PMC is now part of a unified monorepo with DraftMyLesson and PrzygotujLekcje, with Creaclases joining in pre-prod. The 6-week MVP launched 2 years ago has compounded into a real product. The shape of the engine has not changed. The breadth has.
If you are sitting on an idea right now and you are tempted to spend 4 weeks on planning, do not. Spend 1 weekend on the spec. Then spend 6 weeks on shipping. The plan you would have written in week 1 is wrong anyway. The product teaches you what the plan should have been. Ship the smallest honest version, charge for it, and iterate. That is the entire 6-week playbook. The rest is discipline.
