Last verified 23 September 2026. Base44's free plan gives you 25 message credits a month, used up by your prompts. Private apps, which this book needs, start with the Starter plan: $20 a month, or $16 a month if billed yearly. Details for experts at the end of this book.

The idea in one page

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

1. Screens: what each page shows. One page is often enough.
2. Data: every field, its type and its allowed values. "Status: in freezer, in use, empty" beats "status".
3. Actions: who can add, find, edit and delete.
4. 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:

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 once a month to the shared drive as a CSV file, a plain table that any spreadsheet opens. 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 · Turn Your Team App Into One Colleagues Can Depend On.

Worked example: one list the whole team trusts

The method comes from T01-L01 · From Idea to Working Result: The Four-Quadrant Method. 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:

Choose tools. She considers three routes. A shared spreadsheet with data validation, drop-down lists that allow only fixed values, would fix the free text, but not the copies or the sorting. A SharePoint list, Microsoft's shared online table, would work, but the institute doesn't give the group one. She picks Base44: it builds the page, the database where the records live 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.

1. The screen.

   Copy

   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.

2. Real storage.

   Copy

   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.

3. Search and status.

   Copy

   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. A search for nonsense shows the message, and the form still works.

4. Access and permissions. No prompt this time; she sets it herself in the dashboard. On its Overview page she opens the App Visibility menu and picks Private, so only invited people can sign in. In the Invite Users section on the same page she clicks Send Invites, enters her colleagues' email addresses with the access level User, and the lab manager's with Admin.

   Next she sets what each person may do with the records. Under Data she opens the Antibodies table and its Permissions. There is one rule each for reading, adding (Create), changing (Update) and deleting.

   For Read, Create and Update she picks User Property Check, a rule that looks at each signed-in person's role, and allows User and Admin. For Delete she allows Admin only. She makes sure no rule says All Users: that one lets in anyone, even without signing in.

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, the company's customer database, 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 · Decide What You May Paste Into AI at Work).

Do it yourself (90 minutes)

1. Structure it (15 min). Write the four-part description: screen, fields with allowed values, actions per role, exclusions.
2. 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.
3. 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.
4. 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

What you hand in: 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.

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.

Further reading and tools

Next books

• T06-L01 · Build a Small Browser Tool You Will Actually Use: the one-file tool for yourself.
• T06-L03 · Turn Your Team App Into One Colleagues Can Depend On: roles, error states and an app people depend on.
• T12-L01 · Decide What You May Paste Into AI at Work: what may go into a new service.
• T16-L02 · Choose Tools Your Team Can Use, and Afford: credits, plans and who pays.

Tools

• Base44: Taught. Prompts, database, visibility, table permissions and CSV export.
• Lovable: Catalogued. The alternative with more control over the code.
• Bolt.new, v0: Catalogued. Other prompt-to-app builders.
• OpenCode: Catalogued. For the one-file personal tool in T06-L01 · Build a Small Browser Tool You Will Actually Use.