Capstone: from idea to production

Twenty modules in, you have the pieces: context, prompts, projects, automations, verification, Claude Code, agents, specs and evals. This last module puts them together in one project: a real process in your business that goes from idea to a working system in two to four weeks. You do not need to write code; every phase has a no-code route and a Claude Code route.

The structure is the one we use at 77Rentals for any change that touches the operation: choose well, give context, design the simplest thing that works, specify, build with review, evaluate, and launch with a checkpoint. Seven phases, each pointing back to the module that teaches it, so you can return when you need to.

How do I choose the process for my capstone?

Delegation is the first skill in the 4D framework, and it is where most projects fail before they start: by picking the most impressive process instead of the right one. Go back to your week map from module 1 and the what-to-automate-first scoring from module 8. A good first project ticks almost all of these:

• It repeats. It happens every day or every week, not once a quarter.
• It has a clear input and output. An email, a PDF or a WhatsApp message comes in; a reply, a table or a document goes out.
• You can judge the result. You can look at ten outputs and say which are right without asking anyone.
• Mistakes are cheap. If it goes wrong, someone notices before it reaches the customer, or it is fixed in minutes.
• The data is not red on the traffic light from module 5, or it can be anonymized before it goes in.
• You have a baseline. You know, even roughly, how long it takes today and how often it goes wrong.

If the process that hurts most does not pass, do not drop it: make it your second project. The first one exists so you learn the whole method with little at stake.

What context does the system need before I build it?

Everything the system will do comes from what it knows. Module 2 taught you to write a context document for your business. For the capstone, write one for the process itself: where the information comes in, what has to be produced, real examples of good and bad outputs, the tone, what is never promised, and the list of exceptions you currently handle from memory.

Then give it a home. On the no-code route, a project in Claude with the document as its instructions and the reference files attached, as in module 6. On the Claude Code route, a folder with a CLAUDE.md that says what the project is, how it is tested and which rules are never broken (module 12). The 77rentals.com repository has had one since October 2026, with the commands, the structure, the house rules and how deploys work.

How do I pick the simplest design that works?

This is where module 16 pays for itself. Anthropic’s guide to building effective agents recommends finding the simplest solution possible and adding complexity only when it demonstrably improves results. Ask yourself, in this order:

1. 1Is a single call to the model enough, with good context and examples? A great many office processes end here.
2. 2Are the steps always the same? Then it is a workflow: fixed steps, the model inside each one, a validation between steps.
3. 3Does the path depend on what turns up along the way (searching, deciding, retrying)? Only then an agent, with a few well-described tools and a cap on the number of steps.

Before you close the design, run the process through the module 5 traffic light: what personal data goes in, whether it can be anonymized before it reaches the model, where the outputs are stored and who can see them. Write the answer into the canvas; if it does not fit in three lines, the design is not clear yet.

How do I write the spec and the acceptance criteria?

Module 17 turned description into a contract. Your capstone spec fits on one page: what goes in, what comes out, what is forbidden, what happens with the odd cases and, most important, the acceptance criteria: sentences that can be checked with a yes or a no. "Replies in under a minute", "never invents a price", "when a field is missing, it asks instead of guessing". Anthropic’s documentation on defining success asks for the same thing: specific, measurable, achievable and relevant.

Do I build without code or with Claude Code?

Both routes end in the same place; choose by the shape of the problem and by who will maintain it.

• No-code route (modules 6 to 8). A Claude project with instructions and files, a connector to your email or calendar and, if something has to fire on its own, a scheduled task or an automation platform such as n8n, Zapier or Make (module 8). It is the right route when the process lives in tools you already have and a person reviews the output.
• Claude Code route (modules 11 to 15). When you need something of your own: a small program that reads a system, transforms data or serves a page. You start in plan mode, approve the plan, let it build, and turn whatever you repeat into skills (module 14). For the capstone, Claude Code plus, at most, a reviewer subagent is enough; the orchestration in module 18 is for your third project, not your first.

On both routes, the rule from module 13 is not negotiable: every real change lives on a Git branch, goes through a pull request that someone other than the author reads, and only then gets merged. If you work alone, "someone other" is you the next day with that module’s demanding-reviewer prompt. On the no-code route the equivalent is a test copy of the workflow, separate from the one the team uses, and a person who tries it before it is switched on.

How do I evaluate the system before launch?

Combine the test set from module 9 with the evals from module 20. Five steps:

1. 1Golden set. Twenty to fifty real, anonymized cases with the correct output written by you. Include the odd ones: incomplete input, another language, an angry customer, an unreadable PDF.
2. 2Rubric. For each acceptance criterion, how it is scored: yes or no, or a 1 to 5 scale with an example of a 1 and a 5.
3. 3Run and score. Put the whole set through the system. If an automated test can compare against the expected answer, better; if not, you with a table.
4. 4Cost per task. Tokens in and out per case, multiplied by the model’s price on that date, plus the reviewer’s hours. Compare it with what doing it by hand costs today.
5. 5Failure modes. Note every failed case and its cause: missing context, ambiguous instruction, a tool that did not respond, the model made something up. Fix the cause, not the symptom, and run the whole set again.

The goal is not one hundred percent. It is knowing what share it gets right, where it fails, and whether that is acceptable for the human checkpoint you are going to keep.

How do I launch, measure and iterate?

Launch with the human in the loop where you decided in the canvas: before sending (a person approves every output), after (a daily sample) or only on exceptions (the system flags what it is unsure about). Start with the strictest. Loosening it later costs one change; adding it after a mistake costs trust.

Measure against the baseline from module 10: time per task, errors per week, how many outputs were corrected, cost per task. Two weeks of data is enough for a decision: expand, adjust or switch off. And write the closing report, because a project nobody documents turns into an office anecdote instead of a method.

Write the closing report for my AI project, one page at most, for [WHO READS IT: my team, my business partner, me in six months]. Use these sections: which process changed and how it works now; results against the baseline (time, errors, corrected outputs); cost per task and total cost for the month; what failed during testing and how it was fixed; what we decided about the human checkpoint; three lessons; and the recommended next step, with a date.

Do not invent figures: if a number is missing, write [PENDING] and tell me at the end what I need to measure.

Project data:
Process: [WHAT THE SYSTEM DOES AND WHO USES IT]
Baseline: [TIME AND ERRORS BEFORE]
Results: [TIME, ERRORS AND CORRECTED OUTPUTS AFTER]
Costs: [TOKENS OR THE MONTH’S BILL, HOURS INVESTED]
Failures found: [LIST]
Decisions made: [LIST]

What is the project canvas and how do I fill it in?

The canvas is one page that condenses the seven phases into twelve boxes. It takes an hour to fill in, gets reviewed every week, and is the document you hand to anyone who helps you: a colleague, a consultant or an agent. It is written as a prompt so the AI interviews you box by box, but you can fill it in by hand.

Act as my project manager. We are going to fill in the canvas for my AI capstone project. Ask me the questions one at a time, wait for my answer, and at the end give me the complete canvas on one page, with these twelve boxes:

1. Process: [WHICH PROCESS, WHO DOES IT TODAY, HOW OFTEN]
2. Why this one: [WHAT HURTS AND WHAT I GAIN IF IT WORKS]
3. Inputs: [WHAT COMES IN AND THROUGH WHERE: email, PDF, WhatsApp, spreadsheet]
4. Outputs: [WHAT IS PRODUCED AND WHERE IT GOES]
5. Data: [WHAT PERSONAL OR SENSITIVE DATA GOES IN AND HOW I PROTECT IT]
6. Design: [A SINGLE CALL, A FIXED-STEP WORKFLOW OR AN AGENT, AND WHY IT IS THE SIMPLEST THING THAT WORKS]
7. Acceptance criteria: [THREE TO FIVE SENTENCES CHECKABLE WITH A YES OR NO]
8. Build route: [NO CODE: project, connectors, automation / CLAUDE CODE: what program]
9. Tests: [HOW MANY REAL CASES I HAVE AND HOW I SCORE THEM]
10. Human checkpoint: [WHO REVIEWS, WHAT AND WHEN]
11. Baseline: [HOW MUCH TIME AND HOW MANY ERRORS TODAY]
12. Dates: [START, GO-LIVE, REVIEW]

If one of my answers is vague, say so and ask me for a concrete example before moving on. If the design I propose is not the simplest one that solves the problem, challenge it.

How long does it take, and in what order?

A four-week timeline, part time. If the process is small and you take the no-code route, compress it to two.

1. 1Week 1: decide. Choose the process, write the process context document and set up the project, settle the design and run the data traffic light, write the one-page spec with acceptance criteria. Fill in the canvas and get the mentor review before building anything.
2. 2Week 2: build. On a branch, or in a test copy of the workflow. In parallel, assemble the golden set: collecting real cases takes longer than you think.
3. 3Week 3: evaluate and launch. Run the set, score it, work out cost per task, fix the failure modes, run it again. Pull request and review. Go-live with the strictest checkpoint.
4. 4Week 4: measure. Compare against the baseline, loosen the checkpoint if the data allows it, write the closing report and pick the second project.

Act as a demanding mentor who has watched many AI projects fail in small companies. I am pasting the canvas for my capstone project. Review each of the twelve boxes and score it from 1 to 5, with one line saying what is missing. Then tell me which box is the weakest, why it puts the project at risk, and what I should do this week to fix it.

Be direct and do not congratulate me. If the design is not the simplest one that solves the problem, say so and propose a simpler one. If an acceptance criterion cannot be checked with a yes or a no, rewrite it. If the data in box 5 is not protected, stop there: that comes first.

My canvas:
[PASTE THE FULL CANVAS]

What comes after the course?

Three things, in this order.

• Anthropic Academy’s official courses (in English): AI Fluency for builders applies the 4D framework to the full build cycle; Building with the Claude API is the reference for the API route from module 19; Claude Code in action teaches how to run long sessions you can trust.
• Your glossary and your library. The course glossary and the prompt library you started in module 4 are working tools, not notes. Add what you learned in the project: the prompt that worked, the criterion that was missing.
• A monthly review. Models, plans and tools change every few weeks. Once a month, look at what changed, go back to the relevant module, and ask whether your system is still the simplest design that works.

And if you would rather not do it alone, 77Rentals offers AI consulting for teams that want to take a process to production with this same method.

What now?

You are done. You started with what a token is and you finish with a system in production, evaluated and documented. What you have is not a tool: it is a method you can repeat with the next process. When a word slips your mind, it is in the glossary; when you want to go deeper, the official resources are organized by level. Thank you for getting this far.