Base44 for Teachers, September 2026: Zero-Code School Utilities and the Two Kinds of Credit

The lab technician is at the staffroom door for the third time this week, holding a handwritten book: "Sir, who signed out the microscope set last week? It is in the book but I cannot read the name." Before recess ends the physics panel head opens a browser and describes the problem once; by lunch he has a web page with logins, a database and a full loan history. No code, no quotation from anyone.

What Base44 changes is the threshold for deciding whether a small annoyance is worth a system at all. What it charges for is not how often you build, but how often other people use what you built.

The gap it fills

Base44 is a vibe-coding platform: describe a requirement in plain language and it generates a running web application with an interface, backend logic, a database, user authentication and hosting. Wix acquired it in June 2025 for roughly US$80 million in initial consideration plus earn-out payments through 2029, and it still operates as its own product.

Its difference from the other coding tools in this series fits in one line: Codex, Claude Code and Cursor assume you can code, and Base44 assumes you cannot. For where all nine tools sit, see comparing AI tools for teachers in 2026.

Be equally clear about what it is not. There are no classes, no schemes of work, no rubrics and no concept of student safety gating. It is an app builder, not an education product, which makes it right for the school problem that has no software but resurfaces every year: equipment loans, event sign-ups, parent surveys, a panel resource index. The real barrier is descriptive rather than technical — closer to writing a lesson plan than to writing code.

Two kinds of credit

Base44 bills along two parallel lines and schools usually notice only the first.

Message credits are consumed while you talk to the AI to build, so they track your own workload. Integration credits are consumed after the app is live: every time somebody inside it triggers an integration action — sending an email, calling AI, uploading a file — the allowance drops. That second line has nothing to do with whether you are still editing. It follows your audience.

The consequence is blunt. A loan register used by twelve science teachers has allowance to spare; take the same design to 200 pupils using it weekly and the free plan's 100 integration credits a month can be gone on day one.

What the five plans include

From the official pricing page as of September 2026, in US dollars, exclusive of tax, all on annual billing.

• Free: US$0, with 25 message credits and 100 integration credits a month, up to 5 apps, including authentication, database and analytics.
• Starter: US$16 a month, with 100 message credits and 2,000 integration credits, unlimited apps, in-app code edits and a custom domain.
• Builder: US$40 a month, with 250 message credits and 10,000 integration credits, adding manual AI model selection, a free domain for a year and GitHub integration.
• Pro: US$80 a month, with 500 message credits and 20,000 integration credits, plus early access to beta features.
• Elite: US$160 a month, with 1,200 message credits and 50,000 integration credits, the highest allowance and dedicated support.
• Enterprise: custom pricing through the sales team.

Base44 states that annual billing saves 20% against monthly, putting monthly rates at roughly US$20, US$50, US$100 and US$200 — check the pricing page for exact figures. Credits can be topped up, and any third-party service you connect (Stripe, SendGrid, OpenAI) bills you directly, outside all of the above.

Two clauses deserve remembering. Manual model selection requires Builder or above, with Base 1 (Base44's own model), Sonnet 5, Opus 5, GPT-5.6 Terra, GPT-5.6 Sol, GPT-6 Astra and Fable 5.1 on the list, while Free and Starter run on Auto. And the terms state that free and trial credits are promotional, subject to modification, reduction, suspension or discontinuation at Base44's sole discretion and without liability.

An afternoon's build

Take the loan register above: twelve science teachers, around thirty loans and returns a week.

Decide what stays out

Set the rule before typing anything. This app records no student data at all — only the borrowing teacher's initials and the subject. The database is on Base44's infrastructure, not the school's, so the most effective privacy protection is designing those fields out of existence. See on-premises versus cloud deployment for schools.

Start in Discuss mode

Do not press Build first. Switch to Discuss mode with Ctrl + . (Cmd + . on macOS) and settle open questions there at 0.3 credits per message, where one wrong attempt in Build mode can cost several.

I need a loan register for a secondary school science lab. Users are 12 subject teachers; no students involved.
Two things I have not decided, so let us talk before building:
1. About 80 items, some borrowed as a set (a box of 15 beakers) and some individually.
   Should quantity be a field, or should each item be its own record?
2. I want overdue items flagged, but without sending emails. What is the most direct on-screen approach?

Only then switch back to Build, and ask for one change at a time. Request ten things at once and you typically get seven right and three wrong, and undoing the three costs more than the original ask.

Add a "days overdue" column to the loan list, shown in red only when overdue and left blank otherwise.

Do not adjust appearance through conversation. Click Edit at the top of the editor and change type, colour and spacing on the preview; manual edits cost no credits and version history covers them, so a bad afternoon is recoverable.

After it goes out

One step before publishing cannot be skipped: walk the whole flow twice with two different accounts, checking whether the second teacher can see the first one's records. Broken permissions are the most common fault in self-built apps, and the consequence is a privacy incident rather than an ugly screen.

Free-plan apps stay on a Base44 subdomain; the school's own domain needs Starter or above. Have the IT panel head review it before launch and write the app into the school's IT usage policy — it is part of the school's systems now, not a personal side project.

Then start at the smallest useful scale. Run one panel for a month and watch how fast integration credits actually drain, because no published allowance tells you how many integration actions your particular app fires per click.

Something built in an afternoon has to be looked after for three years — decide who owns it in year three before you start.

Three years later

The most realistic risk in school IT is not intrusion but staffing. When the colleague who built the thing transfers or retires, nobody knows how to change it, where the credentials are, or how to get the data back.

Three things therefore have to be left behind on build day: credentials held centrally by IT; one page stating what the app does, which roles exist and where to change each part; and one complete data export actually performed rather than assumed possible.

That last point needs the terms read carefully. The pricing FAQ states that you own your code, data and users, with two-way GitHub sync exporting the full source into your own repository — but the plan comparison lists GitHub integration from Builder upwards, so schools on Free or Starter should get the export route confirmed in writing before paying.

Age sits here too. A Base44 account holder must be at least 13, or 16 in the EU, so primary pupils cannot open an account to build anything. Whether they may use an app you built is a separate layer, and the answer returns to the earlier rule: collect no student personal data and the question does not arise.

When not to use it

Three situations should stop you.

First, the app would hold student names, marks or behaviour records. Not because Base44 is insecure, but because accountability and control sit on opposite sides: the school explains itself to parents and the EDB while a third party holds the servers.

Second, the thing is becoming a standing school system, replacing attendance, assessment records or home-school communication. Standing systems need vendor maintenance, a support channel and an export guarantee, none of which an afternoon produces.

Third, the app would include an AI chat feature for pupils. Base44 will happily put a chatbot inside your app, but nothing gates it, nothing filters unsuitable content, nothing handles a pupil raising self-harm, and nothing leaves a record for a teacher to review. Every safeguard is the builder's to imagine, and a panel head has no business needing to know any of it. See student AI safety and the school knowledge base.

The line is clear enough: utilities nobody sells belong in Base44, and anything involving students, personal data or grant accountability belongs on a platform with gating and records. Edor.ai is the second kind and does not generate applications — that loan register really is faster to build in Base44. See the EDB HK$500,000 AI grant and 10 requirements for an education AI platform.

Common misreadings

• The claim: once the app is finished it costs nothing until I edit it again. What actually happens: message credits track your work, integration credits track your users. Touch nothing at all and the allowance still drains while people use the app.
• The claim: the free plan can carry a school utility indefinitely. What actually happens: the terms describe free credits as promotional and reserve the right to reduce or discontinue them at any time. Free is for proving an idea, not for carrying a process people rely on.
• The claim: not knowing how to code means permissions and data are not my problem. What actually happens: who can see whose records follows from your description. Cross-checking with two accounts before launch is the only way to catch a permissions mistake.

Three things to try on Monday

1. Find one staffroom annoyance with no software behind it — equipment loans, room bookings — and write the requirement in three sentences. If you can write the three sentences, you are ready to try.
2. Ask three questions in Discuss mode before building anything, then count the credits used. That figure tells you how long the free plan survives your use better than any review can.
3. List the self-built tools already running in the school and fill in two columns for each: who holds the credentials, and whether a data export has ever been tested. The blank rows are where the next staff transfer will hurt.