Explore What Already Exists Before You Build | Heidelberg AI Curriculum
T17-L03
Explore What Already Exists Before You Build
Before you build something colleagues will depend on, scan how the job is done today, what products, papers and examples exist, and what you can reuse. Use an AI research mode for the scan, check its claims against real sources, run one small experiment and rewrite the problem.
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 (ELN), software for recording lab work, 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, the company's customer database, has a ticket feature nobody switched on. A ticket gives every request a number and one person responsible for it.
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.
An AI research mode that searches the web, reads many pages and writes a report with links. Use : any signed-in adult can use it without a paid plan, and each report lists the pages it drew on. 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.
Gemini Deep Research
Claude's Research
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 free for anyone 18 or over who is signed in; paid plans get higher daily limits. Claude's Research mode needs a paid plan, from US$20 a month. PubMed is free. Details for experts at the end of this book.
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.
Where
The question
How
1. Here, today
How is it done now, step by step, and where exactly does it go wrong?
Watch it once. Count something.
2. Next door
Who in your institute or company has the same problem? What do they use?
Ask the core facility, IT, the neighbouring group, the other branch.
3. Products
What can you buy, license or install that does this, including open-source software, whose code is public and free to run yourself? What do you already pay for?
AI research mode, then the vendor's own pages.
4. What's written
Are there papers, guides, case reports or forum threads from people who tried?
AI research mode, PubMed, then the source itself.
5. Reusable parts
Which pieces could you take, even if you take no whole product: a template, a label format, a workflow, a checklist?
Everything above.
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:
Claim
Where the AI said it's from
What the source actually says
Keep / fix / drop
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 · Frame a Problem Your Team Agrees On 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 opens gemini.google.com, chooses Deep Research from the menu in the text box, and pastes this prompt with the problem statement, group names removed. Gemini first shows a research plan; she clicks Start research, and the report arrives five to ten minutes later:
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:
Claim
Source the AI gave
What the source says
Decision
eLabFTW is free, open-source and has an inventory with storage locations
eLabFTW website
Confirmed: free software, inventory, "containers" for where things are stored
Keep
Product B "costs €8 per user per month"
a comparison blog from 2024
The vendor page shows no public price; sales contact only
Fix: "price on request"
A paper shows barcodes cut sample-finding time by 70%
a journal article
The paper is real. It reports on a biobank with 40,000 samples, and the 70% is for retrieval by staff, not for small labs
Fix: keep with context
"Labs abandon trackers mainly because entry happens later, not at the bench"
three forum threads
Two threads say this; the third is about a different problem
Keep, as "two lab managers report"
Product C integrates with the institute's ELN
the vendor's page
Page gives no such integration
Drop
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, the group leader, 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.
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). The head of sales asks a team lead to do the scan. 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.
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.
The problem as signed. Paste it, with the date.
How it's done today. What you watched and what you counted.
Next door. Who you asked, and what they use.
What exists. A table: option · what it would do for us · reuse, borrow or set aside · why · source.
What's written. Two to five sources that changed your thinking, each with one line on what it says.
The experiment. The question, what you did, the numbers.
Revised problem statement. With what changed and why.
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 · Run a Pilot with Real Users and Real Data.
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)
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.
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.
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.
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.
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.
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
What you hand in: 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.
Details for experts
Checked on 23 September 2026. You don't need this to follow the book; it's for setting things up or answering a colleague.
What
Details
What it means for you
Gemini Deep Research
Open to anyone 18 or over who is signed in to the Gemini app. All users get it; Google AI Pro and Ultra subscribers, Google's paid Gemini plans, get higher daily limits.
The free version is enough for one scan. If you run out, finish the next day.
Claude Research mode
On the paid plans, not on Free. Claude Pro costs US$20 a month, or US$17 a month billed yearly, before tax.
Worth it only if you already have a paid plan for other work.
PubMed
Free to search. An account is needed only for saved searches and alerts.
You can do this book's scan without signing up.
If these change
Any tool that searches the web and shows its sources will do for the scan.
The method doesn't depend on the tool. You check every claim yourself either way.
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.
Watch
Build vs Buy: The New Software Dilemma
Build vs Buy: The New Software DilemmaAnswerRocket
T17-L03: Watch 2:08–3:56 for opportunity cost and differentiation as reasons to build or buy. Treat this vendor discussion as decision framing, not independent product evidence; still scan internal options and test the candidate.
