The 19 questions an accounting planner asks before a line of code is written
The fairest objection to a planner is also the most common: it's a folder of Markdown files, so what actually happens when I use it?
Fair. So here is the whole thing, in the open — the real discovery flow from the Accounting & Invoicing planner, the questions in the order they are asked, and the specific rules the generated spec has to satisfy afterwards. Not a summary of the idea. The actual questions.
Accounting is a good one to open up, because in this market the questions are the product. Ask a coding agent to "build me an accounting app" and it will confidently produce customers, invoice tables, invoice PDFs and payment allocation, because that is what the average accounting app in its training data looks like. A very large share of small businesses that need bookkeeping do not need invoicing at all — and they now own an invoicing module they will never open, welded into their data model.
What happens when you point an agent at it
You put the folder in your project and say one line:
Read START-HERE.md and follow it.
The agent reads the entry point and the planner core, and then it is under instruction not to write application code at all. It runs discovery first. The exact wording it works from is blunt about this: a request to "run START-HERE.md" means act as the planner and generate the build spec — it does not mean start coding an accounting app directly from this file.
Discovery is grouped into short decision blocks rather than a long interrogation, and Basic is expected to finish in five to seven of them. If you would rather not decide something, "decide yourself" is a valid answer at every step — the planner then picks a conservative default and records it as an assumption rather than pretending you chose it.
Phase 0 — one question before anything else
Pick First Delivery depth:
1. Basic — fastest useful bookkeeping or bookkeeping+invoicing system, 7-9 build steps.
2. Moderate — real small-business finance build with selected reconciliation,
accountant review, client portal, imports, or richer reports.
3. Advanced — full double-entry, bank feeds, tax/payroll, inventory/POS sync,
multi-business/SaaS, multi-currency, or compliance-heavy scope.
If unsure, choose Basic.
That is the first thing you see. It exists because scope, not capability, is what kills these builds — and deciding depth before features means everything downstream can be measured against a budget.
Block 1 — business shape and the lane
1. What are we building? Internal bookkeeping app for one business · custom app for one paying client business · freelancer/agency invoicing app · expense/receipt tracker · accountant working with multiple clients · multi-business/SaaS accounting product.
2. Pick your Basic lane. Bookkeeping-only · bookkeeping + invoicing.
3. Business size. Solo/freelancer · small business under 10 staff · 10–50 staff · multi-branch or multi-entity.
Default if you are unsure: one business, bookkeeping + invoicing, under 10 staff.
Question 2 is the whole product in miniature
It looks trivial. It is the most valuable question in the set, and the planner's instructions are explicit that the agent must not force invoices — it has to ask this before adding clients, invoice tables, payment allocation, or invoice PDFs.
Consider what "bookkeeping-only" removes: no customers table, no invoice builder, no invoice numbering, no PDF generation, no receivables dashboard, no payment allocation, no customer statements. That is a large fraction of the build, and for an expense tracker or an internal bookkeeping tool it is all dead weight — dead weight that still has to be maintained, tested and navigated around forever.
No agent asks this unprompted. It is not a hard question. It is simply not one that occurs to something optimising for a plausible-looking accounting app.
Block 2 — roles, and who has to love it
1. Which roles must exist in First Delivery? Owner/admin · bookkeeper · accountant/advisor · staff expense submitter · customer/client portal user · finance approver.
2. Which ONE user must love First Delivery most? Owner/admin · bookkeeper · accountant/advisor · customer/client.
The second question decides the primary interface, and it is deliberately singular. A build that tries to delight all four delights none — the owner wants three numbers on a home screen, the bookkeeper wants the fastest possible entry form, and those are different products. Naming one settles a dozen later arguments before they happen.
Block 3 — the core finance loop
One multi-select, twelve options: business setup with fiscal year, currency and numbering · cash and bank accounts · income entry · expense entry · vendors and payees · receipt and proof attachments · simple reports and exports · customers and clients · invoice builder with PDF · manual payment recording · receivables and overdue dashboard · customer statement report.
Bookkeeping-only defaults to the first seven. Bookkeeping + invoicing defaults to all twelve.
Block 4 — branches, and the guardrail
One multi-select, seventeen options, and this is where scope normally escapes: quotes and estimates · recurring invoices or expenses · vendor bills and accounts payable · bank statement import · bank reconciliation · full double-entry general ledger · balance sheet and trial balance · tax/VAT/GST reports or e-invoicing · online payment gateway · customer portal · multi-currency · projects, time and billable expenses · inventory or POS daily-sales import · payroll · multi-business SaaS · OCR/AI receipt extraction — or none, keep First Delivery lean.
Now the part that matters. If you pick Basic and then select reconciliation, full general ledger, balance sheet, tax filing, payroll, bank feeds, POS sync, a payment gateway, multi-currency or SaaS, the planner is required to stop and ask once whether you want to upgrade the depth, trim the selection, or keep Basic with those families explicitly deferred.
The instruction underneath is one line: do not silently bloat Basic.
That is the difference between a specification and a wish list. An agent working without one takes every request as an addition and quietly turns your seven-step build into a twenty-step build you will abandon at step twelve.
Block 5 — policies, local rules, and existing data
Six questions, and this is the block that saves the most rework later.
1. Country, currency, language.
2. Accounting depth. Bookkeeping categories only · accounting categories with accountant review · full double-entry general ledger.
3. Payment method. Manual cash/cheque/bank-transfer recording · external payment proof or upload · integrated gateway and payment links · no payment tracking at all.
4. Tax handling. No tax in First Delivery · configurable tax label and rate only · tax summary report · legal filing support needed later.
5. Existing data to import. None, starting fresh · customers and vendors · opening balances · transactions and expenses · invoices and payments · bank statements.
6. Required local reports, retention, consent, invoice wording, receipt wording, fiscal-year or document-numbering rules.
Two things worth noticing. Payment method includes no payment tracking as a first-class answer, which is the correct answer more often than any vendor will tell you. And reports are constrained by the depth you chose — a balance sheet and a trial balance require double-entry, so the planner will not offer them on top of a bookkeeping-lite build where they would be decorative.
There is also a rule about how question 6 is asked: local blockers must be asked in generic wording, and the agent is instructed not to volunteer country-specific identity examples unless you have already named your country and it is genuinely relevant.
Block 6 — stack, hosting, interface, and how it builds
1. Stack. Next.js/React · Laravel/PHP · Django/Python · Rails · no preference.
2. Hosting. Cloud managed · VPS or self-hosted · local and offline-first · no preference.
3. UI priority. Owner/admin command centre · bookkeeper fast entry · invoice and AR workbench · accountant review · client portal mobile · decide yourself.
4. Visual direction. Light finance-ops · dark finance-ops · your brand colours · decide using a calm finance-ops palette.
5. Build Execution Mode. Guided Step · Batch · Autopilot.
Build Execution Mode is the one people underestimate
Guided Step Mode builds one step, stops, and shows proof. Batch Mode builds a batch you choose, then stops with proof for each step. Autopilot continues only while every gate passes, logs each gate separately, and stops immediately on the first failure.
Guided Step is the recommended default, and the requirement attached to it is unusually specific. After each step the agent must give you a concrete "Your 2-minute check" — a URL, which role to sign in as, three to five named clicks, what you should see, one likely failure symptom, and the exact phrase to approve the next step. The planner explicitly forbids ending a step with only "tell me what works" or "next step?".
That is the difference between being handed software and being handed a claim about software.
A worked example, start to finish
The package ships a complete worked example so you can see the shape before you buy. Here is a real set of answers — a small business wanting bookkeeping with invoicing:
| Question | Answer |
|---|---|
| Depth | Basic |
| Lane | Bookkeeping + invoicing |
| Product model | Internal app for one small business |
| Size | Under 10 staff |
| Roles | Owner/admin, bookkeeper, customer portal |
| Must-love user | Owner/admin |
| Branches | Customer portal in — reconciliation, double-entry, tax filing, payroll, POS sync, online payments, multi-currency and SaaS all deferred |
| Payment method | Manual cash/cheque/bank-transfer recording |
| Tax | Configurable label and rate only, no compliance claim |
| Existing data | Starting fresh |
| Stack / hosting | Next.js + Postgres, cloud |
| UI priority | Owner/admin command centre + invoice/AR workbench |
| Build mode | Guided Step |
Fifteen minutes of answers. What comes out is a file that opens by telling the agent what it is:
This file is the governing build contract. Build in Guided Step Mode. Complete one step, run the step gates, browser-test the changed routes, show proof, give the buyer a 2-minute check, and wait for approval before the next step.
Note the last line of that instruction, because it is doing quiet work: do not overwrite this file
with framework notes. Implementation notes go to README.md or HANDOVER.md. The contract stays
the contract — which matters, because an agent that edits its own brief mid-build has stopped
having one.
Look at the branch row again, too. Eight families deferred in a single answer. Each of those is a module a generic build would have started, half-finished, and left in your navigation.
What comes out
One file, named for your tool — CLAUDE.md for Claude Code, AGENTS.md for Codex, or your
editor's rules file — containing locked decisions, explicit non-goals, evidence-grounded scope,
roles, the data model, a screen map, UI requirements, workflows, technical requirements, setup and
seed data, reports, phases, the build sequence, acceptance tests, handover gates, risks, an
amendment roadmap, and a forbidden-family scan result.
Every build step in it has to carry its own tables, screens, server actions, seed data, an acceptance checkpoint, and a "do not continue until" gate.
A few of the rules the generated spec inherits, quoted because they are the sort of thing that separates a working finance app from a convincing one:
- Money must use integer minor units or precise decimals. Durable truth must not be JavaScript floats.
- Invoice, receipt, quote, payment and adjustment numbers must be durable, settings-backed, and survive a refresh or restart.
- Reports, dashboards, exports and PDFs must derive from the same source records mutated by workflows. Seed constants and component-local counters fail the gate.
- Financial writes must be server-authorised and audited with actor, time, before/after or reason, and links to the source record.
- No native browser
alert,confirmorprompt, and no build-step labels left visible in the product interface.
And a readiness label the agent is not allowed to inflate: Prototype, Internal dogfood, Paid beta candidate, or Live candidate. Prototype storage or client-only guards can only ever be labelled Prototype.
What it refuses to do
Before writing the final spec, the planner runs a forbidden-family scan across roles, data model, screens, workflows, technical requirements, reports, jobs and APIs, the build sequence, and acceptance tests. Anything you deferred or skipped may appear only in non-goals, the defer ledger, risks and open confirmations, the amendment roadmap, or the scan result itself.
In plain terms: if you said no to payroll, payroll cannot reappear as a greyed-out nav item, a table nobody populates, or a half-built screen. The most common way a scoped build stops being scoped is that deferred features leak back in as scaffolding, and the scan exists to catch exactly that.
The honest limits
Three things this does not do, worth saying plainly.
It does not write the app while you watch. It writes the specification. Your coding agent then builds from it, and how good the result is still depends on the model you point at it — which is why we publish build-off boards showing what different models actually produced from the same planner rather than claiming a uniform outcome.
It does not remove the need to check the work. The gates are there precisely because a completion report is not evidence. The 2-minute check exists because you are the last gate.
It will not make an unusual business fit a standard model. If your operation genuinely matches what off-the-shelf accounting software does, buy the software — we say so on the Excel page too. The build path earns its place when the fit is wrong, which for accounting mostly means contractors and nonprofits.
That is the entire discovery flow, with nothing held back except the counted evidence anchors each recommendation cites — those are the research, and the research is the thing you are actually buying.
If it reads like a lot of questions for a $49 file, that is the point: nineteen questions is about fifteen minutes, and every one of them is a decision that an agent would otherwise make silently on your behalf and you would discover three weeks later.
The Accounting & Invoicing planner is the package these questions come from.