Database for small business: 7 checks before you buy or build
A client calls with a new phone number, and you change it in three apps. A database for small business is one place that holds each kind of information you keep, once and linked. Before you buy or build one, it should pass seven checks: every item stored once and linked, your full export in a file you can open, accounts in your name, a written statement of where the data is stored, your other tools reading from the same place, one place that decides who sees what, and changes tried on a copy first.
In plain words, a database is a set of lists that know about each other. Your client list, your quotes, your invoices and your appointments each have a list, and each invoice points to its client and its quote instead of copying them.
Most pages on this search give you a list of products. We give none. We give the checks, so you can judge any option, including ours. The checks come from running our own business on one database we own, and each one is answered from that system below. This page is by the clevrstart team: we build these systems, and we run our own business on one database we own. For the whole idea of one place for everything, read our guide to a single source of truth, which explains the rule this checklist tests.
Why a spreadsheet or a pile of apps is not one place
You probably started with a spreadsheet, and that is fine. Airtable's comparison of databases and spreadsheets notes that because spreadsheets are flexible and user-friendly, "they're often the first tool people reach for when working with structured data." A spreadsheet holds a list well. It does not hold the links between lists: the invoice row does not know which quote it came from.
A pile of apps has the opposite problem. Each app keeps its own copy of your clients, and the copies drift. One app has the new phone number, another has the old one.
Before you choose anything, list what you keep and where. Our page on how to organize business data shows the list step by step.
The seven checks
Run each check on any option you are looking at. The last column shows how the system we run our own business on answers it, from our own records.
The seven checks, and how ours answers them
| The check | How to check it | How ours answers it |
|---|---|---|
| 1. Each thing kept once, and linked | Open an invoice: does it name its client and its quote? | Clients, quotes, invoices and time sit in one database; an invoice names its client and its quote |
| 2. You export everything yourself | Export your client list and open it in a spreadsheet | We hold ourselves to the export test below |
| 3. The accounts are in your name | Ask whose name is on the hosting and the domain | Opened in your name before the first line ships |
| 4. Where the data is stored is written down | Ask for it in writing | Written down for each project, not assumed |
| 5. The tools you keep read from it | Ask if QuickBooks or your calendar reads it, or keeps its own copy | Our booking software syncs with Google Calendar; our dashboard reads the tools you already use |
| 6. Who can see or edit what is decided in one place | Count the login lists | One users table for every app, since 2026-08-18 |
| 7. Changes are tried on a copy first | Ask how a change is tested before it goes live | Every step rehearsed on a full copy; the old databases kept for a week |
Checks 1 and 2: linked, not copied, and exported by you
Check 1 is about links. In a database that passes, an invoice does not hold a copy of the client's name and address. It points to the client. When the client changes their phone number, you change it once, and every quote and invoice shows the new one.
Check 2 is the export test, and it is the one that decides who owns your information. Ask one question: can you export everything you put in, in a format something else can read, without asking anyone? A pass is one open file, such as a CSV, for each kind of information, with its links kept. A fail is a PDF per item, a file of totals with no lines, or a message that says to contact support. We set this test out in full on our page about what a business operating system is.
Here is what to look for, as an illustration:
A client export: what passes, what fails
| Passing client export | Failing client export |
|---|---|
| One row per client: name, phone, email, address | One PDF per client |
| Each quote and invoice file names its client | Totals by month, with no client lines |
| You download it yourself, from a menu | A message that says to contact support |
To run it, export your client list and open the file. Google's help page on how to import data sets and spreadsheets explains how to open a CSV in Google Sheets. A passing file has one row per client and every field you typed in.
Checks 3 to 7: what to ask, and what ours does
Check 3: the accounts are in your name. If the hosting or the domain is in the builder's name, you do not own the place your information lives. Our page on hosting and your data says it plainly: hosting, domain, repository and third-party accounts "are opened in your name before the first line ships," and the code transfers to you on the final payment.
Check 4: where the data is stored is written down. You should know which country and which service hold your information. The same hosting page notes that where your data lives "is written down for your project, not assumed."
Check 5: the tools you keep read from it. You do not have to replace QuickBooks, your calendar or Google Business Profile. In a system that passes, they read from the one place instead of keeping their own copy. Ask the vendor one exact question: when I change a client's phone number here, does QuickBooks show the new number, or does it keep its own? That is how we build. On our services page, our booking software "syncs with Google Calendar." Our dashboard is another example: it reads the tools you already use.
Check 6: who can see or edit what is decided in one place. Count the login lists. Before 2026-08-06, each of our apps had its own login tables. Since 2026-08-18, one users table serves every app, so who sees what is decided once.
Check 7: changes are tried on a copy first. Ask how a change is tested before it touches your live information. When we moved our own apps into one database on 2026-08-06, we rehearsed every step on a full copy first, and we kept the old databases until the new one had run clean for a week.
How to run the checklist on any option
You can run this before you spend anything. Four steps, in order:
01
List what you keep, and where
02
Ask the seven questions in writing
Send the checklist to any vendor or builder you are looking at, and keep the answers.
03
Export a sample
Before you commit, export your client list from the option you like and open it in a spreadsheet.
04
Ask what the price becomes as you grow
Ask in writing what you will pay with twice the clients or twice the team.
Our free business data inventory makes the list in about five minutes and shows what you keep in more than one place.
If you are thinking of a build rather than a product, our software cost calculator estimates what a first version costs. Our page on what changes when your data is in one place covers what you gain after the move.
Next step: the call
Bring your list and the seven answers. If you want help, the first step is a call: thirty minutes. Scope, feasibility, complexity, then a number. The call and the number are free; you owe nothing until you accept one.
Questions about a database for small business
01Why is a spreadsheet not enough for a small business?
02What is the export test?
03Why should the hosting and domain be in my name?
04Do I have to replace tools like QuickBooks or my calendar?
05How should changes be tested before going live?
Start
Book a free call
Thirty minutes. Scope, feasibility, complexity, then a number. The call and the number are free; you owe nothing until you accept one.
More on the topic