Explore What Already Exists Before You Build

T17-L03 · Structure & understand · Level 3 Builder · 17-minute read, plus 3 hours of doing

Three weekends, then a link from the core facility

A PhD student in your group has a signed problem statement: finding a sample in the −80 °C freezers takes fifteen minutes, and when someone leaves, a third of their boxes can't be matched to the spreadsheet. He spends three weekends building a sample tracker with an AI coding assistant. It works. Four people start using it. In week two, the head of the core facility sees it and sends a link: the institute has run an electronic lab notebook with an inventory module for two years. Two groups on your floor use it. It has barcode printing, which his tracker doesn't, and IT backs it up, which nobody does for his.

In a company it's a sales assistant at a lab-equipment distributor. Customer requests for quotes and returns arrive in a shared inbox, and some get lost. She builds a tracker in a spreadsheet with a script that copies in new emails. Colleagues start depending on it. Then the script breaks when the mail system changes a setting, and finance mentions that the CRM they pay for has a ticket feature nobody switched on.

Neither build was bad. Both were unnecessary, or at least premature. You are at Level 3 Builder: colleagues will depend on what you make, and you'll maintain it. That makes an hour spent finding what exists the cheapest hour of the project.

After this you can

• Scan how a problem is solved today, inside your organisation and outside it, in a fixed time.
• Use an AI research mode to find candidates, and check every claim you keep against a source you opened.
• Decide for each existing option whether to reuse it, borrow from it or set it aside, with a reason.
• Run one small experiment that answers the question the scan left open.
• Rewrite your problem statement from what you learned, and get it agreed again.

Before you start

• Books: T17-L02. You need its output: a signed one-page problem statement. T01-L02 for checking what an assistant tells you.
• An AI research mode that searches the web, reads many pages and writes a report with links. Use Gemini Deep Research: any signed-in adult can use it without a paid plan, and each report lists the pages it drew on. Claude's Research mode is a strong alternative if you have a paid plan. Your scan question contains only the problem statement, so it's safe to paste once you've removed names and confidential figures.
• A source for papers, if you're in a lab: PubMed, free and without an account. Its Similar articles link on each abstract page is a fast way to find neighbours of a paper you trust.
• A shared document for the exploration note, in the same place as your problem statement.
• About 3½ hours: 17 minutes to read, about 3 hours to do, spread over a week.

Last verified 23 September 2026. Gemini's Deep Research is open to anyone 18 or over who is signed in to the Gemini app. All users get it; Google AI Pro and Ultra subscribers get higher daily limits. Claude's Research mode is on the paid plans, not on Free; Claude Pro costs US$20 a month (US$17 a month billed yearly), before tax. PubMed is free to search, and an account is needed only for saved searches and alerts. If these change, the method doesn't: any tool that searches the web and shows its sources will do for the scan, and you check every claim yourself.

The idea in one page

At Level 3 whatever you build becomes something colleagues rely on and you maintain. Reuse moves that maintenance to someone else. Borrowing an idea saves you the mistakes someone else already made. You can only do either if you know what exists, and the time to find out is before you build, while changing course costs nothing.

Scan five places, in this order. The first two are the ones people skip, and they are often the most valuable.

Let AI find, and you confirm. An AI research mode is fast at the broad part: it reads dozens of pages and hands you a list of products, papers and approaches with links. It's also wrong in predictable ways. A feature claim can come from a two-year-old review. A price can be out of date. A paper can be real but say something milder than the summary. A link can lead to a different page. So every claim that goes into your note has to pass one test: you opened the source and found it there. A small table keeps you honest:

Stop on time, not on certainty. Give the scan a fixed time: about 90 minutes of looking, spread over a few days. You're done early if new sources keep repeating what you already have.

Then one small experiment. The scan leaves one question it can't answer from reading: would the existing option work for us? or is the step we think is hard really the hard one? Design one experiment that answers it in an afternoon, on a small slice of the real work.

Then back to Structure it. This is the Structure it ⇄ Understand it loop at full size. The note ends with a revised problem statement. If nothing changed, say why. That's rare, and it's worth checking you looked in the right places.

Worked example: a scan, a check, an experiment, a rewrite

Both versions follow the same steps. Follow the one closer to your work. The findings, claims and results are typical examples written for this book.

Lab: the sample tracker

The signed statement from T17-L02 reads, in short: four people store samples in three −80 °C freezers; finding one takes about 15 minutes; after someone leaves, a third of their boxes can't be matched to the spreadsheet. A useful result: any member finds any sample in under two minutes, including a leaver's. Test: ten random samples, eight found in time by someone who didn't store them.

Understand it: here, today (30 min). The group's postdoc takes on the scan. She watches a colleague look for three samples and times it: 6, 22 and 11 minutes. The spreadsheet has 2,400 rows in three different column layouts, one per person who set it up. The real delay shows up at the freezer, not in the spreadsheet: tube lids say "S12 3/4" in marker, and nobody but the person who wrote it knows what that means.

Understand it: next door (20 min). Two emails. The core facility replies that the institute runs an electronic lab notebook with an inventory module and barcode printing, and two groups on the floor use it for freezer boxes. The neighbouring group replies that they use a spreadsheet, but print a label for every tube from it before anything goes in the freezer.

Understand it: products and papers (40 min). She removes group names and pastes the problem statement into Gemini Deep Research:

I'm scanning what already exists before building anything.
Problem: [paste the problem statement, without names or confidential figures]
Find, with a link for every item:
1. Software that small academic labs use to track freezer samples,
   including free and open-source options. For each: what it does,
   how it's hosted, what it costs if stated.
2. Published papers, guides or case reports on sample tracking or
   labelling in small labs, and what they found.
3. Common reasons such systems get abandoned.
Say "not found" rather than guessing. Put the date of each source
next to it if you can see it.

The report lists eight products, four papers and a section on why systems get abandoned. She copies the claims she might use into the check table and opens each source:

Two of five claims needed fixing and one was dropped. That's normal, and it's why the table exists. She also searches PubMed for the one paper she trusts and checks Similar articles. One is a short protocol for labelling at the bench, which she adds to the reusable list.

Understand it: the small experiment (one afternoon). The scan leaves one open question: would the institute's inventory module work for four people in a hurry? She sets up one freezer rack, 50 samples, in the existing system, and prints barcode labels for them. Then two colleagues who didn't store them each look for five samples. In the old way, average 13 minutes. With the inventory, average 90 seconds, but only for tubes that had a label; two older tubes without one took as long as before. Entering the 50 samples took her 70 minutes, much of it working out what "S12 3/4" meant.

Structure it: the rewrite. The experiment moved the problem. Finding is easy once a sample is recorded and labelled. The hard part is recording it at the moment it goes into the freezer, and making sense of the 2,400 old rows once. The revised statement:

What's hard: samples are recorded later, in personal formats, or not at all; old tubes have labels only their author understands. A useful result: every new sample gets a barcode label and an inventory entry before it enters the freezer, taking under a minute; old boxes are moved into the same system rack by rack, starting with leavers' boxes. How you'll know: after four weeks, ten random new samples are found in under two minutes each by someone who didn't store them; the number of unmatched boxes goes down each week. Out of scope: building a separate tracker. The institute's system does the storing and finding.

The PI and the student who signed the first statement accept the revision. The student who built the weekend tracker keeps one thing from it: his script that cleans up old spreadsheet rows, now pointed at the import.

Choose tools and Build it (briefly). The main tool is chosen: it already exists. What's left to build is small: a label template and a one-page "sample in, label on" routine at the freezer, plus the import. Checking that an existing tool will hold up before a group depends on it is T16-L03. If the scan had found nothing to reuse, building an app colleagues actually use is T06-L03.

Company: the request tracker

The signed statement: quote and return requests arrive in a shared inbox, about 60 a week; roughly one a week is answered late or not at all; a useful result is that every request has one named person and a reply within two working days; test: over two weeks, no request older than two days without a reply.

Understand it: here, today (30 min). He goes through last month's inbox. Requests don't get lost because nobody sees them. They get lost because three people see them and each assumes someone else is replying.

Understand it: next door (20 min). Service, one floor down, handles repair requests with a ticket system. Finance points out that the company's CRM includes a ticket module on the current plan, never switched on.

Understand it: products and papers (40 min). Same prompt to the research mode, adjusted: "software small sales teams use to track customer requests from a shared inbox…". The report lists helpdesk products, the CRM's own module, and Zammad, an open-source ticket system. He checks each claim he wants to keep. The CRM claim is confirmed on the vendor's help pages and in the company's own admin panel. One product's "free for up to ten users" turns out to be a trial. One "case study" is a vendor's marketing page, which he keeps, marked as such.

Understand it: the small experiment (one week). He switches on the CRM's ticket module for one mailbox and one week, with two colleagues. Every request has a named person within the hour. Replies within two days go from about 85% to 97%. Two problems show up: replies sent from personal mailboxes don't close the ticket, and the service team's requests land in the same queue.

Structure it: the rewrite.

What's hard: nobody is named as the person who replies, and replies from personal mailboxes are invisible to the team. A useful result: every request gets one named person within one working hour and a reply from the shared address within two working days. Out of scope: building a tracker; routing service requests (they keep their own system).

The director and the head of sales accept it. The spreadsheet tracker is retired before anyone else starts to depend on it.

Choose tools and Build it (briefly). The CRM module is the tool. Before the team depends on it, run it through T16-L03. What to build is small: an assignment rule and a reply template. If the requests later need an AI draft in the middle, that's T05-L02.

In both cases the scan found something the builders were about to rebuild, and the experiment found that the hard part was a habit, not a database. Neither result came from reading alone.

The exploration note (two pages)

Use these headings in your shared document. Keep each section short; the whole note fits on two pages.

1. The problem as signed. Paste it, with the date.
2. How it's done today. What you watched and what you counted.
3. Next door. Who you asked, and what they use.
4. What exists. A table: option · what it would do for us · reuse, borrow or set aside · why · source.
5. What's written. Two to five sources that changed your thinking, each with one line on what it says.
6. The experiment. The question, what you did, the numbers.
7. Revised problem statement. With what changed and why.
8. Sources. Every link, with the date you opened it. Mark vendor pages as vendor pages.

Keep the claim-check table as an appendix. It doesn't count towards the two pages.

What goes wrong

The scan becomes a shopping list. Symptom: a table of twelve products with feature ticks and no decision. Fix: for each option, write one of three words (reuse, borrow, set aside) and one reason tied to your problem statement. Drop options you can't decide about in one line.

Skipping here and next door. Symptom: you find the right tool on the web while the building already runs it. Fix: send the two emails first: IT or the core facility, and the nearest group with the same problem. They take five minutes and often end the scan.

The AI's summary goes into the note. Symptom: a price, a feature or a paper's finding you never saw in the source, later contradicted by a colleague. Fix: only claims from the check table go in, and only after you opened the source. If the source is gone or doesn't say it, the claim goes.

Marketing counts as a finding. Symptom: a vendor's "case study" sits next to a paper as if they weighed the same. Fix: label every source by type (vendor page, paper, forum, colleague) and write what each type can and can't tell you.

The scan never ends. Symptom: two weeks later you're still reading. Fix: set 90 minutes of looking before you start. Stop early when new sources repeat old ones.

The experiment is a pilot in disguise. Symptom: you're setting up accounts for the whole team to "try it properly". Fix: one question, one afternoon or one week, a slice of the real work and two colleagues. A pilot with real users and real data is the next book, T17-L04.

The problem stays the same. Symptom: the note ends with a list of findings and the original statement unchanged. Fix: rewrite at least the what's hard and useful result lines from what you learned, or write why they still stand, and ask the two signers again.

Do it yourself (3 hours, over a week)

1. Structure it (10 min). Open your signed problem statement. Write the one question you most want the scan to answer, and set the time box.
2. Understand it: here, today (30 min). Watch the task done once, or go through a week of its records. Count one thing: minutes, misses, repeats.
3. Understand it: next door (15 min, plus waiting). Email two people: whoever runs shared systems (IT, the core facility) and the nearest team with a similar problem. Ask what they use and what they'd do differently.
4. Understand it: products and papers (45 min). Run the scan prompt in an AI research mode. Copy every claim you might use into the check table, open each source, and mark keep, fix or drop. In a lab, check papers in PubMed and use Similar articles once.
5. Understand it: experiment (up to one afternoon). Design one test that answers the question the scan left open, on a small slice of real work with one or two colleagues. Write down the numbers.
6. Structure it (30 min). Write the two-page note and the revised problem statement. Send the revision to the two people who signed the first one.

Exit check

Delivered artifact: a two-page exploration note with:

• how it's done today, with one number;
• who next door you asked, and their answer;
• what exists, with a reuse, borrow or set-aside decision and a reason for each option;
• one experiment, with its question and result;
• a revised problem statement;
• a source for every claim, with the date you opened it, and the claim-check table as an appendix.

It passes when a colleague can open every source and find the claim it supports, and the two people who signed the original problem statement accept the revision.

Rule to remember

Before you build it, find out who already has.

Further reading and tools

Next books

• T17-L04 · Run a pilot with real users and real data: the next step when the experiment says "worth trying properly".
• T16-L03 · Evaluate a tool before depending on it: Choose tools, when the scan found something to reuse.
• T06-L03 · An app your colleagues actually use: Build it, when the scan found nothing that fits.
• T15-L01 · AI in your research workflow: screening literature with AI and keeping a trail back to the source.
• T01-L02 · Trust but verify: the checking habit behind the claim-check table.

Tools

• Gemini: Taught. Deep Research for the product and paper scan.
• Claude: Catalogued. Its Research mode is a paid-plan alternative.
• Perplexity: Catalogued. Quick searches that show their sources.
• PubMed: Catalogued. Free biomedical literature search, for checking papers.