Build the Smallest Thing Your Colleagues Can Run Without You

T01-L03 · Foundations & judgement · Level 3 Builder · 16-minute read, plus 3 hours of doing

The app that worked for four weeks

A postdoc puts together the group's reading shortlist every Friday: new papers on the group's topic, eight to ten of them, with one line on why each matters. Journal club is planned from it. To save time, she spends two weekends building a small web app with an AI coding assistant. It searches, lists and formats. It works for four weeks. Then she's at a conference, the app's login stops working after an update, and nobody else knows where it runs. The group gets no shortlist for two weeks.

In a company it's the team lead who builds a Friday status report. Four workstream leads send updates, he turns them into one page for management, and he automates the whole thing with a chain of scripts. When one lead renames a column in her spreadsheet, the report shows her project at zero. Management reads it before anyone notices.

Both builders were good at building. Both built a rung too high. You are at Level 3 Builder: colleagues depend on what you make, and you have to maintain it. Every layer you add is something that can break on a day you're not there. This book helps you pick the lowest layer that does the job, and make it something a colleague can run and check without you.

After this you can

• Place a recurring job on the ladder of chat, saved prompt, automation, app and agent, and name the requirement that decides the rung.
• Estimate a normal month of upkeep for two options, not just the time to build them.
• Build a known-answer test that a colleague can run in five minutes to see whether the build still works.
• Write a one-page README with a maintainer, a deputy, a pinned version and a fallback.
• Name the trigger that would make you climb a rung, and the line where the build becomes IT's job.

Before you start

• Books: T01-L01 for the four-quadrant method. T01-L02 for checking output before a colleague acts on it. This book is Choose tools at Builder level.
• One recurring job that colleagues already depend on and that you do by hand or half by hand today: a weekly list, a report, a summary, a sheet.
• A shared assistant workspace. This book uses a shared Claude project, because project instructions and files sit in one place a deputy can open, and sharing can be set to view or edit. ChatGPT's shared projects are the alternative if your team already uses them. For confidential material, use the assistant your organisation has approved.
• A deputy: one colleague who will run the build when you're away, with an hour to spare.
• About 3 hours 15 minutes: 16 to read, about 3 hours to build and hand over, over one or two weeks.

Last verified 23 September 2026. Claude projects are available on every plan, including free accounts, which can create up to five. Each project has its own instructions and knowledge files. Projects can be shared with colleagues only on the Team and Enterprise plans: Can view lets a member read the instructions and files and chat in the project; Can edit lets them change instructions and files. An organisation admin can switch sharing off. PubMed's Create alert link under the search bar sets up an automatic email update for a search; you need to be signed in to My NCBI. If these details change, the method doesn't: any workspace that keeps the instructions, the files and the test in one place a deputy can open will do.

The idea in one page

There are five rungs. Each one up does more for you, and each one up gives you more to maintain.

Before rung 1 there's rung 0: something you already have. A template, a spreadsheet formula, a saved search, a form. It often does the job alone.

Three questions pick the rung.

1. Must it run when nobody is there? If no, stay on rung 1 or 2. If yes, try a fixed automation before an agent.
2. Must several people enter or see one current version? If yes, you need shared state: a form, a shared sheet, perhaps an app. That's a different need from running unattended.
3. What measured requirement did the lower rung fail? "An agent is more interesting" isn't one. "The draft must be ready at 07:30, before anyone is in" is.

Count a month, not the build. A build takes hours once. Upkeep comes back every month:

monthly effort = running + checking + fixing failures + updates and access + helping colleagues

Saving five minutes on each of four runs frees 20 minutes a month. If the new build needs 30 minutes of upkeep a month, it has cost you time. It may still be right, for example because it meets a deadline, but then say that's the reason.

Every rung needs the same kit once colleagues depend on it. This is what makes it Level 3:

The higher the rung, the harder each part gets. A saved prompt's README fits on half a page. An app's needs a section on accounts and backups.

Worked example: two builds, four quadrants

Both follow the four quadrants from T01-L01. Follow the one closer to your work. The people and numbers are examples written for this book.

Lab: the Friday reading shortlist

Structure it. Mira, a postdoc in a group of eight, writes: "Every Friday I send a shortlist of eight to ten new papers on our topic, with one line each on why it matters. The group plans journal club from it. A good result: the shortlist goes out every Friday, also when I'm away, and every paper on it is real, recent and on topic."

Understand it. She times four Fridays. Searching takes about 25 minutes, reading abstracts and choosing about 20, formatting about 10. Then she tries the top rung on a copy of the job: she asks an assistant's research mode to find this week's relevant papers. It returns twelve. Three are older than a week, one has a wrong journal, and two she'd never put on the list, because the group already knows them. The choosing is the part that needs her judgement, or her deputy's. Searching is fixed: the same query every week. Formatting is fixed too.

That changes her problem. Back to Structure it: "The search and the formatting should run without thought. The choice stays with a person, but any of two people can make it, in 30 minutes, from the same instructions."

Choose tools. She goes up the ladder from the bottom.

• Rung 0. PubMed can save the group's search and email new results automatically. That does the unattended part for free. No automation needed.
• Rung 2. A shared Claude project turns the pasted alert and the chooser's notes into the group's shortlist format, and flags anything missing. The chooser reads every abstract; the project does the layout.
• Rejected: rung 3. An n8n workflow could fetch the results and post the list. But the alert already runs unattended, and a person has to choose anyway.
• Rejected: rung 4 and 5. An app for one operator, or an agent that chooses papers, would automate the one part that needs judgement.

Her decision paragraph, kept at the top of the README:

We use a PubMed alert plus a shared Claude project because the search is fixed, the choice needs a person, and either of two people can run it in 30 minutes. We rejected an automation because the alert already runs without us, and an agent because choosing papers is the judgement we want to keep. We'll look at an n8n workflow if choosing and formatting take more than 45 minutes on four Fridays in a row.

Build it. She writes the project instructions and gives them a version number:

Shortlist instructions v1.2 (changed 23 Sep: keep correction notices)

Input: PubMed alert records, pasted as text, and the chooser's notes.
Output: a Markdown table with columns: title | first author | journal |
date | PMID | why it matters.

Rules:
- Use only the records pasted in this chat. Don't search, don't add papers.
- "why it matters" comes only from the chooser's notes. If a record has no
  note, write "no note" and don't invent one.
- Keep every record the chooser marked KEEP, in the order given.
- If a record is a correction or retraction notice, keep it and put
  CORRECTION at the start of the title.
- If any field is missing, write "not given" and list it under
  CHECK BEFORE SENDING after the table.

Then the known-answer test. She saves four records from an earlier alert in a file called test-input.txt, one of them a correction notice and one without a note, and writes down what the table must look like in test-expected.md. The expected result has four rows, CORRECTION on the third title, "no note" in the fourth row, and one line under CHECK BEFORE SENDING. Both files go into the project's knowledge and the group drive.

She runs the test in a new chat. The first result drops the correction notice, because an earlier version of her instructions said "keep only research papers". She fixes the rule, which is why the version line says v1.2, and reruns. Four rows, as expected.

The README fits on one page:

# Friday reading shortlist

What: turns the PubMed alert into the group's shortlist. A person chooses
the papers; the Claude project only formats them.
Maintainer: Mira. Deputy: Tobias. Instructions: v1.2 (23 Sep).
Where: Claude project "Reading shortlist" (shared, deputy can edit).
The alert goes to Mira's and Tobias's inboxes every Friday morning.

## Every Friday (about 30 minutes)
1. Open the alert email. Read the abstracts. Mark 8-10 papers KEEP,
   with one line each on why.
2. Open a new chat in the project. Paste the alert text and your notes.
3. Check every PMID opens the right paper. Fix anything under
   CHECK BEFORE SENDING.
4. Send the table to the group list.

## Check it still works (5 minutes, after any change)
Paste test-input.txt into a new chat. Compare with test-expected.md.
Four rows, CORRECTION on row 3, "no note" on row 4. Anything else: don't
use it, tell the maintainer.

## When it fails
- No alert email: run the saved search in PubMed by hand (My NCBI).
- Project unavailable: copy the table format from last week's email and
  fill it by hand.
- Late: tell the group the shortlist comes Monday. Don't send last week's.

Then the only test that matters. In October Mira is at a conference, and Tobias runs the shortlist from the README. Two things go wrong. He can't open the project: Mira's invitation went to his old email address. And he doesn't know that "why it matters" should be one line, not a paragraph. Mira fixes the access and adds "one line" to step 1. The next Friday he runs the known-answer test first, gets four matching rows, then sends the real shortlist.

Where it stops. In December the group leader asks whether the shortlist could go straight into the institute's reference manager and wiki. Those are institute systems with institute logins. That's the stop line: Mira writes down what the group wants and takes it to IT, instead of wiring her build into their systems herself.

What it taught her: the build took an hour. The test, the README and Tobias's first run took two, and they're what made the shortlist the group's, not hers.

Company: the Friday status report

Structure it. Jonas leads a project office at a mid-sized lab-equipment maker. "Every Friday I turn updates from four workstream leads into a one-page status report for management. A good result: the report is correct, on time, and shows plainly when an update is missing."

Understand it. He logs one month. Gathering and copying updates takes 96 minutes, drafting and checking 48, sorting out which version of an update is current 44, fixing mistakes 12. He tries a saved prompt on the drafting: the format is fine within a week. But the slow part isn't drafting. Updates arrive by email, chat and a spreadsheet, and two leads send corrections after he has started. Back to Structure it: "One place where each lead enters an update, one current version per workstream, and a missing update shows as missing." The new need is shared state. Nobody asked for the report to run without a person.

Choose tools. He compares two options over a normal month, and keeps the build time separate:

The company already has a form tool in its office software. Each lead fills in the same four fields by Thursday 16:00, and the latest entry per workstream counts. The saved prompt drafts the report from the exported table. The app loses on upkeep and on build time. An n8n automation that drafts the report at 07:30 would be the next rung, but nobody needs a draft before Jonas starts work.

Build it. The instructions, versioned like Mira's, include one hard rule: "A missing or 'pending' figure stays 'not given'. Never write 0. Never add a total across workstreams." That's the zero from the opening story, written down so it can't come back. His known-answer test has three rows:

workstream | budget used | status | note
North      | 12          | on track | -
East       | pending     | delayed  | supplier reply due
West       |             |          |

The expected report shows North at 12, East and West as not given, lists the three gaps under CHECK BEFORE SENDING, and has no total. He writes the README with the same headings as Mira's, names his deputy, and adds a fallback: if the form is down, leads email the four fields and the deputy pastes them in the same order. In his holiday week the deputy runs the test, gets a matching result, and sends the report on time.

Where it stops. Three months later management asks for budget figures to come straight from the finance system. That system belongs to finance and IT, with its own access rules. Jonas writes the request down and hands it over. Connecting assistants to the organisation's systems is Level 4 work.

In both cases the first idea was a rung too high, and trying a lower rung showed where the real problem was. That's the Structure it ⇄ Understand it loop doing its job before anyone builds.

When to climb, and when to stop

Climb a rung only when a trigger you wrote down fires: a measured time over a threshold for four runs in a row, a deadline nobody can meet by hand, a second person who must enter data. Write the trigger into the decision paragraph when you choose, not when you're tempted.

Stop building when any of these is true:

• The next step needs the organisation's logins, customer data or systems of record. That's IT's job, and Level 4.
• Upkeep is growing faster than the time the build saves.
• Nobody but you can run it, and fixing that would take longer than the job itself. Go down a rung.
• The job has changed and nobody uses the output any more. Retire the build, and say so in the README.

What goes wrong

Building the interesting rung. Symptom: the project starts with "let's build an app" or "let's try an agent". Fix: write the three questions and the requirement the lower rung fails. If you can't name one, stay lower.

Counting the build, not the month. Symptom: "It only took a weekend", and it needs an hour of fixing every other week. Fix: estimate a normal month for each option, keep the build time in its own row, and check your estimate after four runs.

No known answer. Symptom: someone changes the instructions, and a month later a correction notice has been silently dropped every week. Fix: keep a known-answer test with one awkward case, and run it after every change and before a deputy's first run.

A README only you can follow. Symptom: your deputy's first run turns into five messages to you. Fix: let them run it from the README while you watch without helping, and fix the README, not the deputy.

Access you never tested. Symptom: the deputy can't open the project, form or workflow on the day. Fix: the deputy opens every link in the README with their own account before you leave.

A missing value becomes zero. Symptom: a report shows a figure that nobody sent. Fix: a rule that missing stays missing, and a known-answer case that proves it.

Wiring into systems you don't run. Symptom: your build logs into the finance system with your personal password. Fix: stop at the line, write down what's needed, and take it to IT.

Do it yourself (3 hours, over one or two weeks)

1. Structure it (15 min). Pick one recurring job colleagues depend on. Write who uses the result, how often, and what a good result looks like, including what happens when you're away.
2. Understand it (40 min). Time the job once or twice, step by step. Try the lowest plausible rung on a copy of the job. Note which step is slow and which step needs judgement. Rewrite your Structure it sentence if you learned something.
3. Choose tools (20 min). Answer the three questions. Estimate a normal month for your pick and one alternative. Write the decision paragraph: the choice, two rejected options with a reason each, and one trigger.
4. Build it: the build and its test (60 min). Make the smallest version. Version the instructions. Write a known-answer test with three to five cases, one awkward, and run it.
5. Build it: README and deputy run (45 min). Write the one-page README with a maintainer, a deputy, a fallback and the stop line. Give your deputy access, and watch them run the test and one real job without help. Fix every place they got stuck.

Exit check

Delivered artifact: one working build for a recurring job, with:

• the build itself: a saved prompt in a shared project, a form, an automation or an app;
• a one-page README: what it does, where it lives, maintainer and deputy, pinned version, how to run it, how to check it, what to do when it fails, where it stops;
• a known-answer test with three to five cases, one of them awkward, and the expected results;
• a decision paragraph naming the choice, two rejected options and a trigger for climbing a rung.

It passes when your deputy runs the test and one real job from the README alone, without asking you, and the test results match.

Rule to remember

Build the lowest rung that meets the need, and make sure someone else can run it.

Further reading and tools

Next books

• T01-L02 · Check AI output before your team relies on it: the check behind every known answer.
• T02-L03 · A shared assistant for your team: rung 2 in depth, when a whole team uses the saved prompt.
• T03-L03 · Test-driven prompting: known-answer tests for prompts, done properly.
• T05-L03 · The pipeline that writes itself: rung 3, when a trigger has to start the run.
• T06-L03 · An app your colleagues actually use: rung 4, when shared state needs a screen.
• T07-L03 · Your first agent: rung 5, once a fixed workflow has failed.
• T16-L03 · Evaluate a tool before depending on it: checking the tool on the rung you picked.

Tools

• Claude: Taught. A shared project holds the instructions, the test files and the chat.
• ChatGPT: Catalogued. Shared projects do the same job if your team already uses them.
• PubMed: Taught. A saved search with an email alert is the lab example's rung 0.
• n8n: Catalogued. The fixed-workflow tool for rung 3. To run it yourself, use Heidelberg AI Desk (Catalogued).