In August 2026 we were deep into a big feature for KashBoss: a manufacturing module with recipes, production orders and cost calculations. In the middle of that work I stopped and asked my AI assistant a question that had been bothering me. Did you write a file with the plan, based on our first conversation, or are you working from your head?
The honest answer was a bit of both. The assistant read its own memory notes before each phase, but those notes were written for itself. They were technical and scattered, and I could not open one and say, "Yes, this is what I asked for." I had no way to check the work against the plan, because the plan did not exist anywhere I could see.
We wrote a plain plan document that same day. The moment it existed, it exposed a problem nobody had noticed: thirteen settings on the manufacturing settings screen were shown to users and did nothing at all. A plan is not paperwork. It is a tool for finding problems before your customers do.
The short answer
A one-page SaaS plan has five parts: the customer and the problem, about five core features, a "not yet" list with reasons, the user roles, and the main data in plain language. Write it before any code, save it as a file in your project, and make your AI assistant read it at the start of every session. It stops the product from drifting, because AI builds fast but forgets between sessions.
Why an AI assistant needs a fixed plan
AI coding assistants are excellent builders and unreliable memory keepers. Each session starts with a fresh mind. If your idea lives only in conversations, every session reinterprets it a little differently, and after a month you own a product that drifted somewhere you never decided to go.
Think of an architect's floor plan. It shows which rooms exist, who holds a key to which room and what goes in the cupboards. Moving a wall on paper costs nothing. Moving it after the concrete has set costs a fortune. Software is the same, except the concrete sets faster than you expect, because the AI builds so quickly.
The five parts of the page
- The customer and the problem, one sentence each.
- The core features of the first version. Five is a good number.
- The "not yet" list: what you will not build now, and why.
- The roles: the types of people who use the product, and what each can see and do.
- The data: the main information you store, described in plain language, not as database tables.
One page is a feature, not a limit. A long specification gets skimmed by you and half-followed by the AI. A single page gets read, checked and updated.
How we did it in KashBoss
Start with a prompt that makes the AI think first
This is the first prompt I would give anyone starting a SaaS. Use it before a single line of code exists.
Each line has a job. "Act as a product manager" moves the AI from building mode into thinking mode. "What we will NOT build yet" forces choices instead of promises. "Up to 3 questions" invites it to point out gaps without burying you in a questionnaire. "Do not write code yet" matters because assistants love to start coding. Left alone, one will hand you a login screen before you have decided who logs in.
Answer its questions, ask for a rewrite, and save the result as PLAN.md. From then on, every session begins with "Read PLAN.md first."
Write the "not yet" list with a reason for each item
A "not yet" without a reason does not survive. A month later you or the AI will suggest the same idea again and you will spend an hour arguing with yourself. We recorded decisions like these:
| Idea | Decision | Why |
|---|---|---|
| Free version as a separate app | Rejected | Upgrading would mean a new download and moving data |
| Free version that works offline | Rejected | Would mean rewriting most screens |
| Multi-level approval chains | A separate product | One customer's need, would bend the product |
I wanted a free version under a different name, to protect the brand. The counter-arguments were strong: almost nobody would upgrade if it meant a new download, we would support two products, and a new name starts from zero. I agreed. In my assistant's memory, rejected ideas are stored with their reasons and a note: do not suggest this again without a new reason. Without that note, it would have proposed the offline version every few weeks.
Decide the roles before the screens
Roles decide your screens and your security. Adding one later means touching menus, permissions, navigation and database rules everywhere at once. Two principles came out of our work. First, the role is the ceiling: it sets the most a person can ever do, and individual permission switches only narrow things inside it. Second, decide who logs in at all. Drivers or factory workers may need to appear in payroll without ever using the system, which affects your security, your login design and your pricing.
When we added a "sales supervisor" role, we gave it the same screens as the sales rep role, to save time. Every button the supervisor pressed opened a sales rep page, the back button returned to a sales rep page, and some buttons opened admin pages with the full admin sidebar. We ended up building dedicated screens for the role anyway, so the shortcut cost us the time twice. Now every new role gets its own screens, navigation and back button, and reuses only the data underneath.
Describe the data in plain language
You do not need to design tables. You need to say which facts you store, who owns them and which must never change after the fact. Three rules from our plan came from real bugs. Every record belongs to exactly one company. A document is a photograph, not a window: an invoice records the rep's name and the product's cost at the moment it is created and never looks them up live later. And whoever did an action can be the owner or any employee, so record that in a way that allows both.
Say where every feature appears
We once finished a full expiry-date feature and I could not find it in the app. It sat behind a settings switch that was off by default. If I could not find it, no customer would. Every feature in the plan now answers one question: where does the user see this? Chapter 7 of the book has the full checklist, including how to keep the plan alive across phases.
Key takeaways
- AI builds fast and forgets between sessions, so a one-page plan in a file is the fixed point that stops drift.
- What you will not build, and why, matters as much as what you will.
- Decide roles before screens, and give each role its own screens.
- Describe data in plain language and freeze what a document records when it is created.
- Ask the AI to update the plan after each phase and list anything on screen that does nothing yet.
Frequently asked questions
How long should a SaaS plan be before I start building with AI?
One page is enough. It should hold the customer, the problem, about five features, a "not yet" list, the roles and the data. If it grows past a page, it is probably no longer being read by you or by the AI.
Where should I store the plan so Claude Code or another AI can use it?
Save it as a plain text file such as PLAN.md in the root of your project folder. Start each session by telling the assistant to read it first, and ask it to update the file at the end of every phase.
Should I decide user roles before or after building screens?
Before. Roles shape your menus, permissions, navigation and database rules, so adding one late means changing all of them at once. List each role once, with what it can see and do, and ask the AI to keep that list in one place in the code.