Heidelberg AI Curriculum

T06-L02 · Build apps · Level 2 Power user · 13-minute read, plus 90 minutes of doing

Three people, one spreadsheet, four versions

In the lab it's the antibody list. Eight people share one spreadsheet of vials: which antibody, which freezer box, who opened it, how much is left. On Monday a postdoc sorts one column and scrambles the rows. On Wednesday a student works on a copy she downloaded last week. By Friday nobody knows which list is right, and someone orders a €400 antibody the group already has.

In a company it's the demo-kit list at a lab-equipment distributor. Five sales reps lend demo pipette sets to customers. The list lives in an Excel file on the shared drive. Two reps have it open at once, one save wins, and a kit worth €2,000 has been "with a customer" for four months without anyone noticing.

A small web app would fix both: one list, everyone signs in, everyone sees the same records, and nobody can sort away the data. You can build one from prompts, without writing code. The hard part is making sure it really stores what people enter, shows it only to the right people, and doesn't lock the team into your personal account. You are at Level 2 Power user: colleagues will type into this tool and trust what it shows, so a mistake here reaches them.

After this you can

Describe a small team tool by its screens, fields, actions and exclusions before you prompt.
Build it in Base44 one change at a time, and check after each change that records survive a refresh.
Restrict the app to invited colleagues and set who may read, add, edit and delete records.
Have a colleague test it in their own browser, including one thing they must not be able to do.
Export the data and name who owns the account, so the team isn't stuck if you leave.

Before you start

Books: T01-L01 for the four-quadrant method. T06-L01: a one-file tool for yourself, checked against answers you worked out by hand. This book does the same for a tool the team shares.
A Base44 account on a paid plan, because private apps need one. Ideally a team or group account, not your personal one.
The spreadsheet your team uses today, and ten rows of it with names and anything sensitive replaced.
One colleague who will test the app in their own browser, and 15 minutes of their time.
About 105 minutes: 13 to read, about 90 to do.

Last verified 23 September 2026. Base44 plans, per month: Free $0 (25 message credits, up to 5 apps); Starter $20 billed monthly or $16 billed annually (100 message credits); Builder $50 or $40 (250 credits, GitHub integration); Pro $100 or $80; Elite $200 or $160. Annual billing saves 20%. App visibility, under Dashboard → Overview: Public (anyone on the internet, no sign-in), Private (only invited people, sign-in required, paid plans only) and Workspace (everyone in your Base44 workspace). Invited people get the role Admin or User; app users can't open the editor or the dashboard. Table permissions live under Dashboard → Data → (table) → Permissions → Edit, with rules for Create, Read, Update and Delete. The rule All Users means anyone, even without signing in. Other rules: Creator Only, Entity-User Field Comparison, User Property Check. Data exports from Dashboard → Data → (table) → More actions → Export as a CSV file.

The idea in one page

Describe four things before you prompt. An app builder fills every gap with a guess. Close the gaps first:

Screens: what each page shows. One page is often enough.
Data: every field, its type and its allowed values. "Status: in freezer, in use, empty" beats "status".
Actions: who can add, find, edit and delete.
Exclusions: what the app must not do: no file uploads, no emails, no connection to other services, no extra fields.

One change at a time. Ask for the screen first. Then storage. Then search. Then access. Check after each change. If you ask for all of it at once and something is wrong, you won't know which part broke.

A preview only shows what the app looks like. The builder shows a polished preview after every prompt. That tells you nothing about three things your team depends on:

Question	How you check it
Is the record really stored?	Add a row, refresh the page, and find it in Dashboard → Data.
Does a colleague see the same list?	They sign in from their own browser and search for your row.
Is it closed to everyone else?	Open the link in a private window, signed out. You should see a sign-in page and no data.

A missing button doesn't make an action impossible. If the page has no Delete button, a colleague can't delete from the page. But the data's permissions decide what anyone can actually do. So set the table's permissions yourself, and test them.

Plan for leaving. Whoever holds the Base44 account holds the app. Use an account the group or team controls, add a second admin, and export the data as CSV once a month to the shared drive. If the export opens cleanly in a spreadsheet, the team can always go back.

Know when to stop. This book builds a tool for a handful of colleagues with ordinary work data. Before you add personal data, customer contacts, several roles, file uploads or anything the team can't work without for a day, the tool needs a proper design and someone to run it. That's T06-L03.

Worked example: one list the whole team trusts

The method comes from T01-L01. First the antibody list, then the demo-kit list.

Lab: the group's antibody list

Structure it. Aylin, a postdoc, volunteers after the duplicate order. "Eight of us share one antibody list. A good result: one list everyone signs in to, where you can add a vial, find it by name or target, and mark it opened or empty. Nobody outside the group sees it, and nobody can wipe it by accident."

Understand it. Before she prompts anything, she opens the spreadsheet with two colleagues and asks what goes wrong. Three things. People sort single columns. People work on downloaded copies. And the "amount left" column is free text: "half", "~20 µL", "low!!". Nobody can search that. She also counts how often each column is really used. Of fourteen columns, five matter: antibody, target, box position, status and who opened it.

That changes her problem. Back to Structure it: "Five fields, status as a fixed choice, no free-text amount. Anyone in the group can add and update the status. Only I and the lab manager can delete."

She writes it down before touching the builder:


Screen	One page: add form, search box, table
Fields	`antibody`, `target`, `box_position`, `status` (in freezer / in use / empty), `opened_by`
Actions	Everyone: add, search, change status. Admins only: delete
Exclusions	No uploads, no email, no external services, no other fields

Choose tools. She considers three routes. A shared spreadsheet with data validation would fix the free text, but not the copies or the sorting. A SharePoint list would work, but the institute doesn't give the group one. She picks Base44: it builds the page, the database and the sign-in from prompts, and it lets her set who may delete. The alternative is Lovable, which gives more control over the code but asks more of you when you set up the database and sign-in. The data is antibody names and freezer positions, nothing personal beyond first names, so the group leader agrees it may go into Base44. She creates the app under the group's shared Base44 account, not her own.

Build it. Four prompts, one at a time, with a check after each.

The screen.

Create one page called Antibody list. It has an add form, a search box
and a table. Fields: antibody, target, box_position, status, opened_by.
status is one of: in freezer, in use, empty. All fields required.
No file uploads, no emails, no integrations, no other fields.
Start with three example rows that are clearly made up.

Check: exactly five fields in the form, status is a dropdown, nothing extra.

Real storage.
```
Store the rows in one table called Antibodies in the app's database.
The form adds to it and the table reads from it. Change nothing else.
```
Check: she adds anti-GFP, GFP, B-14 / 3, in freezer, Aylin, refreshes the page, and the row is still there. In Dashboard → Data → Antibodies she finds it too.

Search and status.

Make the search box filter the table by antibody or target, ignoring
upper and lower case. Let users change status from the table.
When nothing matches, show "No antibodies found". Change nothing else.

Check: gfp, GFP and B-14 all find the row; xyz shows the message; the form still works.

Access and permissions. No prompt this time; she sets it herself. Visibility: Private. She invites the group with the role User, and the lab manager as Admin. Under Permissions for the Antibodies table: Read, Create and Update for signed-in users with role User or Admin (User Property Check); Delete for Admin only. No All Users rule anywhere.

Team side. Her colleague Tomasz tests from his own laptop. He signs in with his invitation, finds anti-GFP, changes it to in use, and adds one vial. Then he tries to delete a row, first from the page (there's no button) and then by asking Aylin to add a temporary Delete button for the test. The app refuses: permission denied. Aylin removes the button again. Finally she opens the link in a private window, signed out: a sign-in page, no data. She exports the table as CSV to the group drive and opens it in Excel. Five columns, all rows.

What it taught her: the builder did the screen in minutes. The two checks that mattered, a refresh and a colleague's browser, took longer and were the only way to know it worked.

Company: the demo-kit list

Structure it. Marco, one of five sales reps, takes on the problem after the missing kit. "We lend demo pipette sets to customers. A good result: one list where each kit shows who has it, which customer, and when it's due back. Overdue kits stand out. Only the sales team sees it."

Understand it. He asks the other reps how they use the Excel file. It turns out nobody looks at it until a kit is needed. So the list must show the problem without anyone searching. And the customer column holds contact names and phone numbers, which the team doesn't need there: the CRM has them. Back to Structure it: "Kit number, rep, customer company (no contact names), date out, due date. Overdue rows turn red at the top. Reps can add and update, only the sales lead deletes."

Choose tools. The same Base44 route. He takes the app to the sales lead first, since company data is going into a new service. The lead agrees on one condition: company names only, no personal data, and the app goes under the sales team's account, with the lead as second admin.

Build it. The same four prompts with his fields, plus one line in the third prompt: "Sort overdue kits first and mark them red; overdue means due date before today and status not returned." His check: he adds a kit with yesterday's due date and it jumps to the top in red. He changes it to returned and it drops down.

Team side. A colleague tests from her phone in the car park, the place reps really use it. The red rows are readable, the form works one-handed, and she can't delete. The sales lead sees one thing on Monday: how many red rows.

In both cases the prompts took twenty minutes. The value came from Understand it, which cut the fields to what people really use, and from the colleague's test, the only way to know the tool is really shared.

What goes wrong

The preview looks finished. Symptom: your row vanishes after a refresh, or your colleague can't see it. Fix: after the storage prompt, refresh and find the row in Dashboard → Data. Don't continue until it's there.

Too much at once. Symptom: one big prompt, and now search works but the form lost its dropdown. Fix: one change per prompt, and "change nothing else" at the end of each.

Public by accident. Symptom: a signed-out visitor sees the list. Fix: set visibility to Private, remove every All Users rule, and test in a private window.

No button, no protection. Symptom: you assume nobody can delete because the page has no button. Fix: set the table's Delete permission to Admin only, and have a colleague try it.

Your personal account. Symptom: you change jobs and the team loses the app. Fix: build under a team account, add a second admin, and export CSV monthly.

Real data creeps in. Symptom: someone pastes a customer's phone number into a notes field. Fix: no free-text notes field in version one. If personal data arrives anyway, remove it and ask your data protection contact (T12-L01).

Do it yourself (90 minutes)

Structure it (15 min). Write the four-part description: screen, fields with allowed values, actions per role, exclusions.
Understand it (15 min). Open the spreadsheet with one colleague. Which columns do people really use? What goes wrong? Cut the field list and rewrite the description.
Choose tools (10 min). Would data validation or a SharePoint list do? If not, check with whoever decides that your data may go into Base44, and create the app under a team account.
Build it (50 min). Four prompts, one check each: screen, storage with a refresh, search, then visibility and permissions set by hand. Colleague test from their own browser, including one refused action. Private-window test. CSV export opened in a spreadsheet.

Exit check

Delivered artifact: the live app and a half-page note with:

the screen, fields and exclusions;
visibility, roles and table permissions, as actually set;
the colleague's test: one allowed action, one refused action, and what they saw;
the CSV export: where it lives and that it opened;
the account holder and the second admin.

It passes when a signed-out visitor sees no data, the colleague's test matches your note, and the export opens with every row.

Rule to remember

A shared tool is proven in a colleague's browser, not in your preview.

Build a Small Shared Tool From a Prompt, and Test It With a Colleague