Last verified 23 September 2026. Base44's test database needs the Builder plan: US$50 a month, or US$40 billed yearly. Private apps need any paid plan, from US$16 a month billed yearly. Only the Elite and Enterprise plans can restore earlier data. Details for experts at the end of this book.

The idea in one page

At Level 2 you proved the app works for one colleague on one day. At Level 3 it has to keep working for everyone, on days you're not there, after changes you haven't made yet. That takes five parts.

Four facts shape how you build it.

1. Table permissions work on whole tables. Table permissions are Base44's rules for who may read, create, update and delete the rows of each table. They can't say "members may update the notes field but not the status field". So design the roles around tables. If two roles need to change different things, either only one role updates that table, or the thing goes into its own table.
2. Your preview shows your view. You built the app and you're an admin. You see every row and every button. A colleague with the User role sees something else. Test each role from its own account, in its own browser window.
3. The last save wins unless you design against it. If two people open the same record and both save, the second save replaces the first, and nobody is told. For a team of eight that's rare, but it's exactly the kind of error nobody notices until the invoice arrives.
4. Every prompt can change something you didn't ask for. Base44's AI builder, the part that turns your prompt into code, rewrites code to make your change, and sometimes it touches a screen or a rule next to it. That's why the test sheet exists, and why it runs after every change, not once.

What stays yours: the roles, the known answers and the decision that a change is ready to publish. The AI builder writes screens. You decide what correct means.

Worked example: two apps, four quadrants

Both situations use the four-quadrant method from T01-L01 · From Idea to Working Result: The Four-Quadrant Method. The first is told in full; the second shows what changes. The names, numbers and test results are illustrations.

Lab: reorder requests in the antibody list

Structure it. Aylin, the postdoc who built the antibody list, writes down what the group now expects. "Group members ask for an antibody to be reordered in the app. Petra, the lab manager, and Jonas, her deputy, order from the requests on Tuesdays and Fridays and record what they ordered. A good result: nobody orders the same antibody twice, every request shows its status, and the app runs for a week without me."

Understand it. Before prompting, she sits with Petra for twenty minutes and goes through the last month's requests, which came by email and sticky note. Three things come out. Petra sorts requests oldest first, because the oldest ones hold up experiments. About one request in ten is a duplicate of an open one. And people want to fix a typo in their request after sending it.

Her first design follows the last point: members create requests and may update their own (Creator Only on update, the rule that lets only the person who created a row change it), and Petra and Jonas update any request. Then she checks what the table can enforce. Creator Only on update lets a member change every field of their own request, including the status. A student could mark his own request as ordered, and Petra would never see it. Hiding the status dropdown from members wouldn't change that, because the permission is on the table.

Back to Structure it: "Members create requests and read all of them. Only Petra and Jonas update. A member who made a mistake creates a new request and writes 'replaces R-17' in the reason; Petra declines the old one. Before a new request is saved, the app warns if an open request for the same antibody exists." Losing the typo fix costs a little convenience. In return the status means what it says.

She writes the design down before she touches the AI builder. In plain words: one new table for requests; every member can create and read requests; only the two managers can change them; only admins delete. To tell members from managers she plans a field called app_role to the User table, Base44's built-in list of everyone who can sign in. User Property Check is the permission rule that reads that field:

Choose tools. She stays in Base44. The group already knows it, the data is in it, and the two things she needs, a role field checked by the table permissions and a separate test database, are built in. The group upgrades the team account to the Builder plan for the test database. The alternative she considers is Lovable, whose built-in database runs on Postgres, a widely used database, with security rules written in SQL, its query language. Those rules can be finer than whole tables. It would also mean rebuilding and re-testing an app that works. That's a good trade only when the Base44 rules can't express what you need. Hers can.

Build it. She switches on Test Data first, which gives the app a second, empty database for trying things, so nothing she tries touches the real list (the clicks are in Details for experts). Then she fills the test database by hand in Dashboard → Data, with the Test switch on: six made-up antibodies and six made-up requests. Because she typed them herself, she knows the right answer to every question the app will be asked:

She counts the open requests twice before writing that last number down.

Then she builds in small steps, one prompt each. After every step she opens the testing link (Publish → Testing link), which shows her unpublished changes working on the test data only, and runs the matching lines of her test sheet.

The first prompt, in plain words: make the requests table, a form to fill it in, a warning when the same antibody already has an open request, and a list of open requests, oldest first. The last line, Change nothing else, keeps the AI builder away from the rest of the app:

She asks the AI builder only to add the app_role field to the User table. The permissions she sets by hand, as in T06-L02 · Build a Small Shared Tool From a Prompt, and Test It With a Colleague: the four rules under Dashboard → Data → OrderRequests → Permissions. She doesn't ask the AI builder to do this. A rule you set and read yourself is one you can explain to the deputy.

The second prompt adds the states. The first draft of the "Open requests" page shows an empty table when nothing is open, and a raw error message when a member's save is refused. In plain words, she asks for a sentence instead of every blank table or raw error, one that says what's going on and what to do next:

The third prompt deals with Petra and Jonas working at the same time. In plain words: just before a manager's change is saved, look at the request again; if someone changed it in the meantime, don't save, and say who did:

This narrows the window to a second or two, which is enough for a team of eight. A database that refuses the second save outright is the kind of thing that belongs to Level 4.

Now the test sheet, a table in the operating note with one line per thing that must be true. To run a line, sign in as the account in the second column, do what the third column says, and compare what you see with the last column:

Line 7 fails on the first run: the app shows the refusal message, but it also shows the request's catalogue number in the message text. She asks the AI builder to remove it, reruns lines 7 to 10, and all pass. After the lines pass, she runs Base44's built-in security scan from the Security tab and reads what it reports before she publishes.

Hand it over. The part that makes the app the group's is the operating note, kept next to the app in the group's shared folder. It answers five questions: where the app is and who looks after it, who may do what, how to change it safely, what to do when it's down, and how the data is backed up. Collaborators are people invited to edit the app, not just use it. CHANGES.md is a plain text file with one line per published change. CSV is a plain table file any spreadsheet opens:

Then the rerun. She gives the note to Jonas, who didn't build anything, and asks him to make one small change on his own: rename the reason "new experiment" to "new project". He makes the change, runs the test sheet through the testing link and finds that line 5 now fails, because the AI builder also shortened the duplicate warning. He restores the wording with a second prompt, runs the sheet again, and publishes. That's the operating note doing its job: the change that broke something never reached the group.

What it taught her: the new table took one evening. The roles, the test copy and Jonas's rerun took twice as long, and they're what let her go to the next conference without her laptop.

Company: kit bookings in the demo-kit list

Structure it. Marco, the sales rep who built the demo-kit list, writes: "Reps book a demo kit for a customer visit. Svenja in logistics ships it and marks it returned and checked. A good result: no kit is booked twice for the same days, and Svenja sees next week's shipments on Monday morning."

Understand it. He looks at the last two months. The double bookings all have the same cause: a rep books by looking at the list, and another rep books the same kit ten minutes later from his phone. His first idea is to let reps edit their own bookings to move the dates. The same table rule stops him that stopped Aylin: a rep who can update a booking can also mark it shipped. Back to Structure it: reps create and cancel bookings through a request; only logistics updates. And the app must refuse, not just warn, when the dates overlap an existing booking.

Choose tools. Same Base44 app, same Builder plan, with the sales lead's agreement. The overlap rule is the one piece he can't set in the table permissions, so he asks the AI builder for it as a check before saving, and makes it a known-answer line in the test sheet.

Build it. His test copy has six made-up kits and four bookings, one of them TEST-K-03, booked 12 to 20 November. His key test line reads: Rep: book TEST-K-03 for 10 to 14 November → refused, "TEST-K-03 is booked 12–20 Nov". A second line checks the edge: book TEST-K-03 for 21 to 23 November → saved. The first run fails the edge: the AI builder treated the 20th as overlapping the 21st. He fixes the prompt, and both lines pass. Svenja runs the whole sheet on her own the following week. Her operating note has one line Aylin's doesn't: "If the app is down, bookings go into the shared calendar 'Demo kits' and Svenja copies them in."

Where it stops. In week three the sales lead asks whether the app could create the shipping order in the company's ERP system, the central business software for orders and stock. Marco writes it into the note as the first thing that isn't his to build. Connecting to company systems, using the company's own sign-in and keeping records the company must keep is Level 4 work with IT, and T06-L04 · Put Your Team App on the Organisation's Own Database, and Prove You Can Restore It starts there.

In both cases the AI builder wrote the screens in minutes. What made the apps dependable was deciding what the table can enforce, writing down right answers first, and watching someone else change the app safely.

Where your build stops

A Base44 app with two roles, a test copy and an operating note is right for a group of up to a few dozen people with ordinary work data. Stop and talk to IT, or move to T06-L04 · Put Your Team App on the Organisation's Own Database, and Prove You Can Restore It, when any of these comes up:

• Personal or confidential data goes in: patient or participant data, HR matters, customer contacts. First ask your data protection contact (T12-L01 · Decide What You May Paste Into AI at Work).
• Other systems need to read or write it: purchasing, ERP, the institute's sign-in.
• Losing a day of data would cost more than a morning's work to re-enter. On most plans you can't restore earlier data, only export it.
• More than two roles or more than one team need different views of the same table.
• Nobody is left who can maintain it. A deputy is the minimum.

Stopping isn't failing. The app did its job: it showed what the team needs, and the test sheet shows IT exactly what it must do.

What goes wrong

Buttons hidden, table open. Symptom: members can't see the status dropdown, but one of them changed a status anyway, through a page the AI builder added later. Fix: set the rule in the table permissions, then test the refused action from a member's account, as in line 7.

Testing as yourself. Symptom: everything works for you; the first member sees an empty page. Fix: one account per role, each in its own browser window, and at least one line of the test sheet per role.

Known answers you never checked. Symptom: the test passes, but the expected result was wrong from the start. Fix: write the expected results from the records you typed, count again before the first run, and include a record that must not appear.

The sheet runs once. Symptom: a small change in April breaks the duplicate warning, and nobody notices until two vials arrive. Fix: the whole sheet before every publish, written into the operating note as a step, not a suggestion.

Real data in the test copy. Symptom: someone copies the real list into the test database "to make it realistic". Fix: test records are made up and start with TEST-. The test database is for known answers, and you only know them for records you invented.

No fallback. Symptom: the app is down on a Friday and nobody knows how to request an antibody. Fix: one line in the note and one sentence in the app's error message: where to go instead, and who enters it afterwards.

The deputy on paper. Symptom: you're away, the app breaks, and the deputy has never opened the editor. Fix: the deputy makes and publishes one real change, with the test sheet, before you call the app handed over.

Do it yourself (3 hours, two sessions)

1. Structure it (15 min). Write two sentences: who depends on the app, for what, and what "working without me" means. Name the two roles.
2. Understand it (25 min). Go through a month of the work with the person who depends on it most. Find the duplicates, the conflicts and the edits people want. Check each planned role against what the table permissions can enforce, and rewrite your design if they can't.
3. Choose tools (10 min). Confirm Base44 still fits, or name what it can't express. Check the plan has Test Data, and agree who pays.
4. Build it: test copy and sheet (40 min). Switch on Test Data. Type in six to twelve made-up records starting with TEST-. Write a test sheet of about ten lines with known answers, at least one per role, one refused action and one conflict.
5. Build it: roles, states and the save check (50 min). Add the role field and set the table permissions yourself. Prompt for the screens, the states and the save check, one prompt at a time, running the matching sheet lines through the testing link after each.
6. Build it: note and rerun (40 min). Write the operating note. Give it to your deputy. Watch them make one small change, run the whole sheet and publish, without your help. Fix the note wherever they got stuck.

Exit check

What you hand in: a published Base44 app and its operating note, with:

• two roles set in a User field and enforced in the table permissions;
• a test database with made-up TEST- records;
• a test sheet of about ten lines with known answers, covering each role, one refused action, one empty state and one conflict;
• the operating note: link, maintainer, deputy, account holder, publish steps, fallback, weekly export, and where the app stops;
• the rerun: the date your deputy ran the sheet and published a change.

It passes when a colleague who didn't build the app runs the whole test sheet through the testing link and every line matches, and the deputy has published one small change without your help.

Rule to remember

An app is the team's when someone else can change it, test it and publish it without you.

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-L02 · Build a Small Shared Tool From a Prompt, and Test It With a Colleague: the private app and table permissions this book builds on.
• T06-L04 · Put Your Team App on the Organisation's Own Database, and Prove You Can Restore It: your organisation's own database and API, backups and a real restore.
• T12-L03 · Give an Unattended Workflow Limits and a Stop a Colleague Can Use: who is responsible when the app runs on its own.
• T16-L03 · Test a Tool on Your Own Work Before Your Team Depends on It: checking a platform before a group depends on it.
• T17-L03 · Explore What Already Exists Before You Build: whether the institute already runs something that does this.

Tools

• Base44: Taught. Roles, table permissions, Test Data, testing link and Version History.
• Lovable: Catalogued. The alternative when you need rules finer than whole tables.
• v0, Bolt.new: Catalogued. Other prompt-to-app builders.
• Supabase: Catalogued. The open-source database platform, run on your organisation's own server, that T06-L04 · Put Your Team App on the Organisation's Own Database, and Prove You Can Restore It teaches.