A dBASE alternative you can open right now.
Flat pricing, unlimited users, no per-seat fees — and no sales call to find out whether it's any good. The button below opens a real, working database in your browser: Microsoft's own Northwind sample, rebuilt in Bionic Forms, with its customers, orders and line items all wired together. No signup, no email, nothing to install.
Where this is up to
- Works today, on any OS, in your browser — nothing to install, and there are desktop apps for macOS, Windows and Linux as well.
- Windows is a download now; there is no iPhone or Android app yet. The Windows app is not code-signed yet, so the first time you run it Windows shows a blue “Windows protected your PC” box — click More info, then Run anyway. Some antivirus flags it for the same reason. A certificate is bought, not written, and we would rather ship the app and say this plainly than keep you waiting on a purchase order. The phone apps get built the moment someone needs them.
- Offline is a desktop feature. The encrypted local database ships with the desktop app — macOS, Linux and Windows. In the browser it is not true: that needs a connection, and I'd rather say so here than have you find out on a train.
- The local database file is encrypted on disk (adiantum full-file encryption), and the key lives in your operating system's own secure store rather than in the file.
- I'm not going to pretend this is urgent. If your dBASE application still runs, it runs. The question is what happens the day it stops, or the day the person who maintains it moves on.
- Calculation fields do not calculate yet. Collections, fields, links between records, screens and permissions all work. A calculated field can be created and labelled, but nothing works out the value, so it shows as empty with a note saying why. If the worth of your app is mostly in its calculations, that is worth knowing before you move anything rather than after.
What it actually looks like
Both of these are the CRM template as it ships — one click from an empty account, no setup. They are screenshots of the running product, not mockups.

A grouped list view. Fields are changed in the app’s settings, or by asking the assistant, never by accident from the list.

The same app's dashboard. The charts read live from the records above, not a separate reporting tool.
How the pricing works
Flat, by what you build — never by how many people use it. Add the whole team, the contractor, the client who needs read access: the price doesn't move.
What happens when the person who built it leaves?
That's the question this is really built around, and it's the one I'd genuinely like to hear your answer to. A departmental app usually outlives the person who wrote it, and what's left behind is often a file nobody can safely change.
- The app is described, not codedDoc types, fields, views and workflows are structured definitions — the next person reads what it does instead of reverse-engineering a script.
- Every change is a revisionRecords keep their history, so "who changed this, and when" has an answer after the original author is gone.
- The data is a database on your machineOffline-first and encrypted, syncing when it can. If my company disappeared tomorrow, the file wouldn't.
- Roles are part of the appPermissions live in the app definition, so handing it over doesn't mean rebuilding who can see what.
What you can do yourself, today
You don't have to wait for anyone to move your data. The app reads a .dbf table as it is
(dBase III, IV and 7, FoxPro and Clipper all write the same family of file), so there is no export step:
drop it in and it builds a collection in one step — a field per column, each typed from what the column actually holds (dates as dates, amounts as numbers, a column of a few repeated values as a dropdown), named from your data, with a meter while the rows go in. Anything it typed wrong you change afterwards in the app's settings.
One limit, and it is memo fields. Their text lives in a separate .dbt file, and the app does
not read that yet. If a table has memo fields with anything in them, it names them and imports nothing,
rather than bringing the table in with the notes missing. For those tables, export a CSV from dBase
instead, or send us both files and we will load them for you.
Where it can't tell, it asks rather than guesses. A column of dates like 03/04/2026 could be
the 3rd of April or March 4th, and the rows it would get wrong look exactly like the rows it would get
right — so it stops and asks you which, and won't import until you answer. If one value anywhere in the
file can't be read, nothing is imported at all: a half-loaded collection is worse than an empty one,
because you can't tell which records made it and running it again duplicates the ones that did.
Import your tables into the same app, one file after another and in any order, and it looks for the links between them — an order that names a customer ID gets connected to its customer, so you can open one and see the other. It only links where both the column name and every value agree; where it isn't sure, it leaves the values alone rather than guessing.
Where it stops: it moves data. It does not convert screens, programs or reports — there is no automatic conversion of an existing application. Rebuilding the screens is still work someone has to do, in the app's own designer. What this gets you is your own records on the screen in a couple of minutes, so you can judge the rest against real data rather than a sample.
What this is not
It isn't a dBASE importer — there's no automatic conversion of an existing application, and I'm not going to pretend a rebuild is a click. It isn't a spreadsheet, it isn't a form builder, and it isn't finished software with a track record. It's an honest early product with a pricing model that doesn't punish you for adding people, and I'm looking for a handful of people willing to tell me where it falls short.
What it costs to find out
Nothing, and there is no call to book. Open the demo, click around a real database, and decide for yourself. If you want your own, the free tier is genuinely free and takes a minute.
When you are ready to bring your own data, the app reads your dBASE tables directly and works out how your tables relate to each other — that is the part described above, and it is self-serve. You do not need me for it.
Or do not build it yourself. Describe the app your business runs on and we will build a working version of it and show you — no fee, no card, and the app we build fits the free plan. How that works.
Still comparing? dBASE is xBase, so the roundup I wrote for Visual FoxPro covers most of the same ground — every xBase replacement I could find, including the ones that beat this one if keeping the code matters more than leaving it behind. The FoxPro page is the closer sibling to this one.
Bionic Forms is built by Matt Bidwell (Bionics LLC). If something here reads as overclaiming, tell me and I'll fix the page — that's a promise I can actually keep at this stage. Either way you can reach me at matt@bidwellhq.com.