Lesson 01 / Coding for researchers

Fake the data,
build the demo

You don't need a database to show someone your idea. You need fake data that behaves like real data. Five minutes here, nothing to install, and you'll know enough to ask an AI for your own demo — and to tell whether what it gives back is any good.

01 The idea

Every app is a restaurant

A guest never walks into the kitchen. They tell the waiter what they want, the waiter goes and gets it, and comes back with a plate. Watch one order happen.

Frontend

The dining room

What the guest sees. Keeps no food of its own.

orders

API

The waiter

Carries every request out, brings every answer back.

fetches

Backend

The kitchen

Where the food comes from. Fake today, real later.

Mocking means opening with a fake kitchen — food you typed out by hand — and hiring the waiter anyway. The dining room works today. The day a real kitchen arrives you swap it in, and because the guest only ever spoke to the waiter, nothing else has to change.

02 Try it

Change the fake data. Watch the screen follow.

This is a working mock API, running right here in the page. Edit the data on the left — the screen on the right updates, because it asked the API instead of holding data of its own.

Backendmock_data.py

Valid — 2 studies

APIapp.py

# one endpoint, one job @app.get("/api/studies") def list_studies(): return store.get_studies()

Frontendindex.html

// no data in this file — it asks const reply = await fetch("/api/studies"); const studies = await reply.json();

Three things to try 0 / 3

Change one of the study titles.

The screen followed without being told. It never stored that title — it asked the API again and drew whatever came back.

Add a third study.

Nothing about the screen had to change to handle a third card. This is what people mean by "the frontend is driven by the data".

Swap the fake kitchen for a real database.

Look closely: the screen is identical and the API is identical. Only the box on the left changed. That is the entire payoff of keeping the parts separate.

That's the concept

Fake data is enough to build a real-feeling demo. You do not need a database to find out whether your idea makes sense to someone.
The screen should hold no data. If study titles are typed into the page itself, the parts are stuck together and swapping anything means rewriting everything.
The API is the promise. Keep the list of requests stable and you can replace what is behind it whenever you like.

You now know enough to ask for one of your own. The prompt below does the asking for you.

03 Your turn

Ask an AI for your own

Paste this into Claude or ChatGPT and fill in the three brackets. It is worth keeping because of what it forbids — left alone, an AI will happily type your data straight into the screen and hand you something that cannot be changed later.

Build me a small demo app with fake data, in three separate parts:

1. a backend file holding the fake data as a plain list, plus simple functions to read it
2. an API whose endpoints only call those functions
3. one self-contained HTML page that gets ALL its data from the API — no build step, no CDN

MY IDEA: [one or two sentences about what it does and who for]
THE MAIN THINGS IN IT: [e.g. studies, participants, responses]
SOMEONE SHOULD BE ABLE TO: [see a list of ___ / open one / add a new one]

Rules: no data hardcoded in the HTML page; 3-5 realistic-looking example records, not
"Item A / Item B"; comment it for someone new to code; then give me the exact commands
to run it and tell me what I should see.

Then just keep talking to it in plain English.

"Add a search box that filters as I type." · "Show the scores as a bar chart." · "Now replace the fake data with a real database and tell me what changes." · "I get this error: [paste the red text exactly]."

One thing to watch for: if the AI writes your data into the HTML page, ask it to move the data into the backend file and have the page fetch it instead. That one correction is the difference between a demo you can grow and a demo you have to throw away.