CodeHero PRO

The Domain Expert's Software Factory

How CodeHero PRO turns what you know into a working application

Classroom edition · For business owners, managers and domain experts · September 2026

Today

What we will cover today

The problem — why the people who know the work best rarely get the software they need
The idea — humans decide, agents build, evidence proves
Step 1 · The interview — you talk, the Spec Builder listens
Step 2 · You approve — nothing is created before you say yes
Step 3 · The build — the factory plans, builds, tests and verifies
Step 4 · The handoff — what you receive, and life after go-live
Your part — six lines, and one exercise

One company walks with us the whole way: a small repair shop we will meet in a minute.

Today

A question for the room

Which piece of your work lives in a spreadsheet, an email chain, or in someone's head?

What happens when that person is on holiday?
What happened the last time something was lost, late, or done twice?
Who has asked for "a system" for it, and what happened to that request?

Part 1

The problem

Why the people who know the work best rarely get the software they need.

Part 1 — The problem

The person who knows the problem best is almost never the person who can build the software

The operations lead

Knows the workflows, the exceptions, the customer.

The logistics planner

Knows the constraints, the windows, the capacities.

The finance manager

Knows the rules, the approvals, the reports.

The developer in a small team

Knows how to build, and has ten projects waiting.

The knowledge is in the room. The capacity to build is not.

Part 1 — The problem

What usually happens today

01
The spreadsheet grows
Colours, copies, a formula only one person understands.
02
You ask for "a system"
IT, an agency, a freelancer. A quote, a queue, a wait.
03
You explain your job
To someone who has never done it, in a few meetings.
04
Something is misunderstood
A rule, an exception, who may approve what.
05
You find out after it is built
Now every correction is a change request.

"The most expensive mistakes in software are made before the first line of code: a misunderstood process, an unstated rule, a wish mistaken for a capability."

Part 1 — The problem

Meet RepairFlow, our running example

A small electronics repair company with three technicians.
Every repair job is written in an Excel sheet: a number, the customer, the device, a technician, a deadline.
Jobs get lost. Deadlines are missed. The owner cannot see who is doing what.
The owner wants "a system", has a normal web hosting account, nobody technical in-house, and wants to spend as little as possible per month.

THE OWNER, LAST WEEK

"A customer brings a laptop, we write it in the sheet with a number, a technician takes it, when it's fixed we call the customer, they pay and pick it up."

Part 1 — The problem

Two kinds of AI tools exist today. Neither is built for you.

CATEGORY ONE

Prompt-to-app builders

Anyone can prototype from a prompt. Generic apps, hosted in the vendor's cloud, not built for real data, integrations or years of operation.

THE SOFTWARE FACTORY

CodeHero PRO

Built for the domain expert inside a company, and for the developers who work with them. A specification first; then a production-grade application on your own infrastructure, built by agents, independently verified, proven with evidence, and maintained in the same factory.

CATEGORY TWO

AI coding tools

Powerful accelerators for professional developers. One developer, one task at a time. Process, hosting and operations remain the team's problem.

Part 2

The idea

Humans decide. Agents build. Evidence proves.

Part 2 — The idea

Three guarantees, in every project

Business decisions come from humans

The agents never guess a rule of your business. They decide every technical matter themselves.

Every claim of success comes with evidence

Nothing is called finished on the strength of a sentence. A test, a loaded page, a record, a screenshot.

Every failure is visible

What is blocked is marked blocked. What was decided for you is listed. What is open stays open, in writing.

These are the three guarantees of the Autonomous Development Framework (ADF), the method CodeHero PRO implements.

Part 2 — The idea

Think of it as a factory

WHAT GOES IN

Your knowledge, in your own words
Your spreadsheet, forms, documents
Your answers to a few business questions
Your "yes" at defined points

WHAT HAPPENS INSIDE

An agent turns the specification into a plan of tasks
Agents build one task at a time and test each part
A second agent checks the work
Everything is written down as it happens

WHAT COMES OUT

A working application on your own server
A report in four parts, with evidence
Documentation in your language
The same factory maintains it afterwards

Your part: answer the questions only you can answer, at defined points. Nothing else.

Part 2 — The idea

The journey, end to end

01You
Interview
Plain language, one question at a time, about how the business really works.
02Spec Builder
Specification
Complete and reviewed. Every technical matter decided for you.
03You
Approve
You confirm the specification and provide the day-0 items. Then a planning agent orders the work.
04Agents
Build
One task at a time: code, database, tests, on a private preview address.
05Second agent
Verify
A different AI checks the work. It never edits. Findings become fix tasks.
06You
Handoff
Evidence, what was decided for you, what waits on you, what is open.

You decideThe factory works

Part 2 — The idea

Six words we will use

Word	What it means here
Specification	The written description of what to build, in your words: what is tracked, who does what, every rule with an example, what must never happen.
Ticket	One task for one agent, written so that the agent needs nothing else: what to build, which files it owns, how it will prove it is done.
Agent	An AI worker that follows the factory's written rules for that task. Several agents take part in one project, each on its own ticket.
Provider	The company whose AI model an agent uses. The factory uses more than one, so that one AI can check another.
Preview	A private web address where the application runs while it is being built. Every test happens there.
Evidence	A test that ran, a page that loaded, a record that exists, a screenshot that was taken. Never a sentence saying it works.

Step 1

The interview

You talk. The Spec Builder listens, asks, and writes the specification.

Step 1 — The interview

What the Spec Builder is

An AI interviewer that follows a written method: a knowledge file you download from our website and load into an ordinary AI chat.
It asks one question at a time, in your language, in your words.
You can upload your spreadsheet, forms and screenshots; it reads them before it asks anything.
It decides every technical matter itself and tells you what it decided.
You may answer "I don't know". That is an answer.

"With a non-technical user never ask about databases, frameworks, servers, APIs, hosting types or file formats; ask what happens in their world, what must never happen, who does what, how fast, how many, and translate that into technology."

The Spec Builder's own instructions, §1.2

Step 1 — The interview

It starts with one question

"Which piece of your work do you want to organize or automate? Describe a real example — what happened last time, step by step."

The opening question, always the same

"If you are not sure, say 'I don't know' — I will choose a safe option and tell you what I assumed, and anything critical will stay marked until you confirm it."

Step 1 — The interview

The questions sound like this

"Do you have a document, spreadsheet or current tool you can share?"
"What problem should this tool solve? What happens today without it?"
"Is there anything the tool must never do or allow?"
"Are there rules or calculations (limits, deadlines, formulas, approvals)?"
"What must happen when a rule is broken or a deadline is missed?"

"Who can delete, approve, or export?"
"How quickly must someone see a change made by someone else — instantly, within a minute, on refresh?"
"Backups: how much work could you afford to lose — one day, one hour?"
"What initial budget and what monthly running cost can the company support?"
"Anything you were afraid to ask or thought was impossible?"

All quoted from the interview stages of the Spec Builder. Not every question is asked every time; what a document already answers is skipped.

Step 1 — The interview

Your spreadsheet is a specification in disguise

In your spreadsheet	Becomes
Each sheet, or a repeated block	A thing the application tracks, named in your words
Each column	A field with a type: text, date, money, a choice, a person, a file
Each formula	A business rule, restated in words and confirmed with your own numbers
Colours, comments, manual marks	Statuses and exceptions: "what does a red cell mean?"
"Every Monday I copy A to B"	An automatic job
Who edits which columns	Permissions
Duplicates, blanks, different spellings	Cleaning rules and an import report: nothing is silently "fixed"

"Column H is Deadline = Order date + 14 days. Correct?"

Step 1 — The interview

RepairFlow: what the owner said, and what it became

The owner said	Became	Label
"A customer brings a laptop, we write it in the sheet with a number, a technician takes it, when it's fixed we call the customer, they pay and pick it up."	A Job that moves through the states received → in repair → ready → delivered; a Customer; a Technician	Confirmed
Column H in the sheet is `=D2+14`	Rule: deadline = date received + 14 days	Confirmed (document)
"Red cells are the ones we are late on."	A job past its deadline and not ready is overdue; overdue jobs are highlighted, and the manager is notified daily	Confirmed Assumed (the daily email)
"Only I give discounts."	Permission: a discount requires the Owner role; which roles may discount, and up to how much?	Open, critical
"We'd like customers to check the status themselves one day."	A customer portal	Later
"We have a website on a normal hosting company, nobody technical in-house."	Runs on standard web hosting: a decision the Spec Builder makes, not a question for you	Technical

Step 1 — The interview

Every statement gets one of four labels

Confirmed

"the user said it, or a source shows it"

Assumed

"your reasonable business assumption that needs confirmation"

Technical

"your choice, with reason — never asked of the user"

Open

"a missing element that affects the build"

"I don't know" is an answer. A technical gap is filled for you. A business gap becomes Assumed, with one sentence saying what was assumed.
Critical items are never silently assumed. Anything that decides money, approvals, deletion rights, legal obligations or safety stays Open and visible in every summary until you confirm it, even when you want to finish quickly.

"Nothing marked Assumed becomes Confirmed by silence."

Step 1 — The interview

The preview: "Is this how you work? Tell me what is wrong."

Before any question about scale, brand or security, the Spec Builder shows you what it is designing, without jargon:

The main screen, as a text sketch: what is on it, in which order, the three most common actions.
Your main process, walked through with your own example: who does what, what the tool shows, what it sends, what happens when something goes wrong.
Each role in one line: what they see, what they can change, what they cannot.
The status summary: what is Confirmed, what was Assumed, what is Open.

REPAIRFLOW, AT THE PREVIEW

The owner corrected one thing: the front desk also takes the payment, so the Front desk role may mark a job as paid.

One message, one correction.

"Misunderstandings caught at this point cost one message; caught after the build they cost dozens of tickets."

Step 1 — The interview

Wishes are not capabilities

"The user confirming that they want a function does not prove that their ERP, device, hosting or external service supports it."

Spec Builder instructions, §1.2

Every connection to another system, device or service is listed separately, with what it must be able to do.
Each one is verified before the part that depends on it is built. Until then it is marked pending, and the part that needs it waits.
A stand-in used for testing is recorded as a stand-in. It never counts as the real connection.

Step 1 — The interview

Before it is finished, the specification is attacked from fifty angles

Once the first complete version exists, the Spec Builder runs fifty review rounds: each examines the whole specification from one perspective, tries concrete examples in your own numbers, and records what it found. Some of the perspectives:

main process end to endevery rule has a number and an examplewhat must never happen late, duplicate, out-of-order dataconcurrent edits by two users what an attacker with a stolen phone or laptop can doerror messages in the user's languageperformance on a slow connection

A real round produces a finding with a worked example, or records that nothing needed to change. "Ticking a list of fifty topics is not fifty rounds."
The rounds check the specification. They do not prove that the application works; that is done later, by real tests.
You are asked only when business information is genuinely missing or two requirements contradict each other.

Step 1 — The interview

What comes out: the specification package

ONE DOCUMENT, IN YOUR LANGUAGE

What to build, and what is out of scope
What is tracked, and how your existing data is imported
Every business rule, numbered, with a worked example
Processes and states; notifications and reports
Who can do what: a role-by-role matrix
Screens, languages, brand; backups; hosting and running costs
Milestones and candidate tasks; what you provide and when
A decision log; the record of the fifty rounds

How you read it

Start with the appendix of assumptions, technical decisions and open items. The method calls it "the first thing the user reads".
A package with Assumed or Open items is a Draft for confirmation. Only preparatory work may start from a draft.
When the critical open items are closed, it is Ready to build.
Moving a critical item to "Later" needs your agreement. It is never done silently.

Step 2

You approve

Nothing is created before you say yes.

Step 2 — You approve

Before the build starts: what you provide

The method calls it the day-0 pack: "exactly what the company must provide before CodeHero starts". Typically:

your domain name, and access to your hosting
the email account the application will send from
logo files
the spreadsheet with your existing data
the details of the first administrator

A missing item does not stop everything. The part that needs it is marked blocked, with the reason, and is never reported as done.

REPAIRFLOW, DAY 0

the email account for the daily overdue notification
the first Owner account details

Everything else the factory already has: the specification, the rules, the spreadsheet.

Step 2 — You approve

The preview screen, and your "yes"

Inside CodeHero, the in-app planner reads the package and shows a preview before anything exists:

the project and how it will run
the specification summary: scope, what is left for later, assumptions, open items with an owner
the day-0 items and who provides them
what happens after you confirm

Then one question: "Do you agree? (yes / no / changes)"

TWO RULES THE PLANNER MUST FOLLOW

Business decisions belong to the user. "Money, rights, approvals, deletion, legal retention, safety, scope and cost limits. Technical matters are yours. A business gap is never filled with an invented default. Two models agreeing is not a decision. Silence is not approval."

Front-load the human input. "Once the planning ticket starts, the run is autonomous and a missing business decision stops it."

Step 3

The build

The factory plans, builds, tests and verifies. You are asked only what only you can answer.

Step 3 — The build

First a plan, and the most valuable slice first

A planning agent reads the specification, saves it as the unchangeable baseline, and turns it into an ordered list of tasks.
It orders the work by value: "the thinnest end-to-end slice of what the product is for", proven on the preview address, before any secondary feature.
It rehearses the plan, reviews it from many angles, and has it checked by a second AI before any task is created.
It creates the first phase only, about ten tasks. Later phases are planned after the real result of the earlier ones is checked.

VALUE ORDER, TWO EXAMPLES

An online shop: one product page → add to cart → checkout works, before wishlists, branding, a dark theme or extra reports.

RepairFlow: log in and see an empty job list; then create a job → change its status → deliver it; then the overdue rule and its daily email.

If a client pushes for the logo first: the logo cannot fail; the checkout can.

Step 3 — The build

RepairFlow: the first phase of work

#	Task	Purpose	Checked by
1	Check the environment	What this installation can really do; the preview address works	—
2	Store the rules and decisions in the project memory	Every later task finds them without asking	—
3	Application foundation	Structure, database, first data, shared header and footer	4 · a second AI verifies
5	Access gate: log in and see an empty job list	The thinnest working path, on the preview address	6 · a second AI verifies
7	Core: create a job → change its status → deliver it	What the product is for, end to end	8 · a second AI verifies, with negative tests
9	Overdue rule and the daily notification	The first rule with consequences	10 · a second AI verifies
11	Re-plan	Compare the real result with the baseline; repair if needed; plan phase 2	—

Everything runs one task after the other. Phase 2 will bring the job sheet printout, discounts (once the owner has confirmed who may give them), and the documentation.

Step 3 — The build

One task at a time

Serial by default

One task at a time, in a fixed order. The next starts only when the previous one is done and checked.
No two agents ever edit the same file at the same time.
Every task starts from a verified, reported state, and the history reads like a clean audit trail.

Parallel only as an offer

When tasks are truly independent, the planner may offer to run a few together.
It happens only after you say yes, and only if the plan proves that the tasks touch no shared files.
In any doubt: one at a time.

The cost is calendar time. The benefit is correctness: nothing built on Tuesday quietly breaks what was verified on Monday.

Step 3 — The build

What one agent does with one task

Understand the task.
Search the project memory and the existing work.
Write its plan on paper: goal, approach, how it will prove each part. Open questions are asked now, in one batch, or a safe option is chosen and recorded.
Build one small part.
Test that part. If it fails, follow the fault-finding procedure.

Update the plan, then take a snapshot of the files. After every part, not only at the end.
Parts remain? Back to step 4.
Full test on the preview address, then every repeatable test, then the acceptance list item by item: pass, fail, or blocked with the reason.
Store the decisions and the failed approaches in the project memory.
Report: two honesty lines, then four parts. Only then: task completed.

Step 3 — The build

Evidence, not claims

"'Done' = a test ran, a page loaded, a row exists, a screenshot was taken. 'I think it works' = NOT done."

Rule 2 of the rules every agent receives

Expected results come from outside the code: from your specification, your examples, your numbers. A test that only checks what the code already does proves nothing.
Every page is tested on the preview address, with the browser's own error log, the network log and the server logs checked.
Never fake a passing check. Never weaken security to pass one. The rules give the bad example themselves: inserting a record by hand so that the "record appears" test passes.

Step 3 — The build

Agents forget. So everything is written down.

The plan-and-progress file

One per task, inside the project: goal, approach, what is done, what is next. Updated after every part. The first thing an agent re-reads when it feels lost.

The project memory

Decisions, failed approaches, the rules from your specification. Every task reads it at the start, so a rule confirmed once is never asked again.

Snapshots

A saved copy of all files at the start of every task and after every verified part. If a change breaks something, the snapshot is restored and a different approach is tried.

"Agents forget when their working memory fills up. So every plan, decision and progress note is written into the project as it happens. Anything not written down is treated as if it never happened."

Step 3 — The build

A second agent checks the work, and never edits

1 · BuildAn agent builds the task and reports, with evidence.
2 · VerifyA different AI walks the acceptance list, runs the tests, adds its own negative tests. It only checks. It never edits.
3 · FixFindings go back as one fix task to the original builder: each finding with steps, expected, observed.
4 · Re-checkThe verifier wakes up, re-checks only the findings, and passes the task or opens the next cycle.

CIRCUIT BREAKER

The same part failed three cycles, the same item failed twice in a row, or builder and verifier disagreed twice: the loop stops and you decide, with both views in front of you.

REPAIRFLOW, TASK 8

The verifier finds the deadline computed as received date + 15 days instead of + 14. One fix task. The builder corrects it and adds a test with the owner's own dates. The verifier re-checks: pass.

Step 3 — The build

When it does not know a rule of your business, it asks you

Technical choices

The agent decides these. It is told: "NEVER ask the user about them."

Business rules

Only you know these. The agent is told: "NEVER guess them."

"Asking about a technical choice = not doing your job. Guessing a business rule = risking the whole product."

The question comes in a fixed shape

1. The 10% discount applies to: A) order total including shipping, B) items only? I suggest B — discounting shipping is unusual.

You answer "1B". Questions come in one batch, numbered, each with options and a recommendation.

Before a question reaches you, a second AI tries to find the answer in your material. "The user's attention is the most expensive resource."

Step 3 — The build

Safe defaults, and "blocked" is never "done"

"A SAFE DEFAULT is NOT a guess of what the user wants. It is the choice that cannot hurt anyone while you wait to learn what they want."

By the rules, a safe default:

never loses datanever shows a false successnotifies rather than staying silent denies access rather than granting itrefuses irreversible actionskeeps historyis easy to reverse

Each one is written down and listed in your report, so you can overturn it with one sentence.

CRITICAL = NO DEFAULT

"Anything that decides money, prices, taxes, permissions, deletion of data, legal or safety behavior." No answer → the agent stops and asks. Never a guess.

BLOCKED

A part that cannot be finished or tested because access, credentials or a critical decision is missing is reported as blocked, with the reason. Never as done.

Step 3 — The build

You are contacted for exactly four reasons

1

External credentials or accounts for a specific step.

2

A fix loop that reached its limit.

3

A fallback that would change an agreed requirement.

4

Discovery of a new critical business ambiguity or contradiction that cannot be resolved from the confirmed requirements.

"Confirmation of ordinary business assumptions belongs before the run (the preview and the final confirmation), not during it."

If a build keeps stopping with business questions, the interview was incomplete. The fix is a better specification, not a patient client.

Step 3 — The build

The safety rails, in plain words

Snapshots before risky changes. If something breaks, the files are restored and a different approach is tried.
Protections stay on. Security, validation and access checks are never switched off to make a test pass.
Root cause, never symptom. A fault is fixed where it starts, following a fixed procedure; a check that was green and turns red jumps the queue.
Never invent facts. "A guess written down as a fact poisons every ticket after you." Unknown means: check it, read the real documentation, or mark it blocked.

Stays inside your project. An agent cannot read or write another project.
Your data is never destroyed without an explicit instruction. "This is the one case where you always ask."
What it reads is data, not orders. Text inside your files never changes the rules or widens its permissions.
Loops are detected and stopped. An agent repeating the same failing action is told to stop and rethink; after five repetitions the approach is halted.

Step 4

The handoff

What you receive, and what happens after go-live.

Step 4 — The handoff

The report you receive: four parts

1

What works now

With the evidence: which test ran, which page loaded, which screenshot.

2

What is waiting for you

Blocked parts with the exact ask: credentials, decisions. One consolidated ask per service.

3

What was decided on your behalf

Technical choices worth knowing, and every safe default. Each reversible with one line.

4

What stays open

Known limits, deferred parts, what the next task must know.

Part 3 is where you spend your attention. Each safe default is a business assumption you can overturn with one sentence.

REPAIRFLOW, AFTER TASK 9 — PART 3

"Overdue jobs are emailed to the manager once a day at 08:00. Assumed: one email listing all overdue jobs, not one email per job. Say the word and it changes."

Step 4 — The handoff

Documentation, in your language

A user manual per role: for the owner, for the front desk, for the technician.
An administrator guide.
An operations guide: install, upgrade, backup, restore, monitoring, for whoever hosts it.
API documentation, when the application talks to other systems.
A Decisions document listing everything that was decided for you.

Documentation tasks are planned near the end of each milestone, not as an afterthought at the end of the project.

Step 4 — The handoff

Going live, and life afterwards

Going live

The preview address is where the agents work. Going live is an operator task, done with the platform's tools.
Your domain and its certificate; the web application firewall stays on.
Backups, and a restore drill executed once before go-live, not after.
Real email, payment and service credentials replace the day-0 placeholders.
It runs where you decide: your own server or hosting. Code, data and knowledge stay with you.

Afterwards

The same factory maintains the application.
A small change or a fix is one task: a field, a label, a report column. No new plan.
New work on a finished application starts a new plan, which reads the real application first.
The project memory keeps every decision, so a change made a year later still respects the rules you confirmed today.

Step 4 — The handoff

Who does what

You

The domain expert

The truth of the business: the process, the rules, the exceptions
The day-0 pack
The answers, in one batch when asked
The "yes" at the preview and at the plan
Reading part 3 of the reports

The operator

Your developer or a partner

Runs the factory and reads every report
Answers the technical questions an agent should have decided ("your call")
Brings you only genuine business decisions
Keeps the specification's decision log in sync
Never invents a business fact

The agents

The factory

Plan, build, test, verify, document
Write everything down as they go
Ask only what only you can answer
Stop themselves when a human is needed

Your part

Your part, in six lines

Describe a real example, step by step: what happened last time.
Answer honestly, "I don't know" included. Critical things stay open until you confirm them.
Correct the preview. "Tell me what is wrong" is a genuine request.
Provide the day-0 pack: domain, hosting access, email account, logo, spreadsheet, first administrator.
Answer each batch of questions in the shape it comes: "1A, 2B, 3 yes".
Read part 3 of every report: what was decided for you, and overturn what you disagree with, in one sentence.

Your part

Exercise

Take the process you named at the start. On one page, write:

What happened last time, step by step, with real names and dates.
Three rules that have a number: a deadline, a limit, a formula.
Who may approve, delete or export, and who must never.
One thing that must never happen.
The one part that must work first.

THEN, IN PAIRS

Swap pages. Play the interviewer for your neighbour: ask one question at a time, only about their world. Mark every answer Confirmed, Assumed or Open.

About fifteen minutes, then two or three pairs share what surprised them.

Your part

What to remember, and where to go next

Humans decide.
Agents build.
Evidence proves.

Your knowledge goes in through an interview, in your words.
Nothing is built before you say yes, and nothing critical is assumed.
Every result comes with evidence and is checked by a second AI.
You receive a working application, a four-part report, and documentation in your language.

Go deeper

The twelve principles, in business language
The Spec Builder: what it is, how to set it up, download
Developer training course: for the people who will operate the factory with you
Platform documentation
Talk to us or book a demo

`→` `Space` `PgDn`	Next slide (or next bullet on a step-by-step slide)
`←` `PgUp` `Backspace`	Previous slide
`Home` `End`	First / last slide
`F`	Full screen (Esc leaves it)
`S`	Speaker window: notes, timer, next slide; it stays in sync with this window
`N`	Show the speaker notes at the bottom of this window
`O`	Overview of all slides (click one to jump)
`B`	Black screen while you talk (any key brings the slide back)
`?`	This help