← FIELD NOTES
CASE NOTEFeb 4, 2026·4 MIN READ

A whole firm's client database, on a stack that costs nothing to run.

From the build log. A small South African accounting firm wanted one place to see its clients, its fees and its overdue returns. We built it in a single session, put it online, and the monthly bill came to nothing. Here is why that is the right answer for a firm this size — and where it stops being the right answer.

B
Brynn
FOUNDER, TRANSFORMATE

A small South African accounting firm came to us with a problem most small firms have. Their client information was scattered across spreadsheets, and the question of which audit returns were overdue lived mostly in someone's gut. They didn't want a sprawling system with sixty features they'd never open. They wanted one place to look: who the clients are, what's owed, what's late.

We built it and put it online in a single working session. The part worth writing down isn't how fast that was. It's that the whole thing runs for nothing a month — and that this was the correct choice for a firm this size, not a corner we cut to save them money.

The right-sized tool

Think of it like the difference between a corner shop and a supermarket. A supermarket needs loading bays, refrigerated warehouses, a fleet of trucks and a team to keep it all running. A corner shop needs a good set of shelves and a till. Put supermarket machinery behind a corner shop and you haven't made it more capable — you've just saddled it with running costs and maintenance it will never use.

Most professional firms get sold the supermarket. A practice with a few hundred clients gets pitched a server, a monthly platform fee, and a maintenance burden it isn't equipped to carry. What it actually needs is the well-stocked corner shop: sortable, filterable client lists you can export to a spreadsheet, a view that flags the returns where a fee is missing, a detail page you can edit in place, and a few charts for anyone who wants the shape of things at a glance. Every one of those was built on top of data that was already theirs.

A few hundred clients and a handful of users is not a small version of a big company's problem. It's a different problem, and it has a different right answer.

The honest opinion here is that small firms are routinely sold far more than their numbers justify. A practice with a few hundred clients does not need its own server humming away in the background. Putting one under them mostly buys recurring cost and a job nobody on staff wants.

Where the limit actually is

So is "free" too good to be true? No — but it has an edge, and you should know where it is before you walk towards it.

The free option works because the firm is small and it's the only one using the system. Hundreds of clients and a few daily users sit comfortably inside what the no-cost tier allows. That holds while the firm stays the only tenant and the data stays modest.

There was also a line we wouldn't cross, and it had nothing to do with cost. Running another business's automatic processes on infrastructure we own is a legal question, not a convenience one. So when this firm outgrows the free tier, the plan is already set: they rent their own space, in their own name, and we point the system at it. Nothing gets rebuilt. We designed for that day from the start, rather than pretending it would never arrive.

The transferable bit

Before you pay for anything, count two things: how many records, and how many people. If the answer is hundreds and a handful, the no-cost setup isn't the cheap version. It's the right one — and the effort goes into the screen the firm will actually use every day, instead of into machinery nobody will ever see.

For the technical reader

The front end is React, built with Vite and styled with Tailwind, with Recharts for the graphs (five chart types). It deploys to Cloudflare Pages. Data sits in two separate Supabase projects on the free tier — one handling the project board and sign-in, the other holding the client records proper: 425 clients, 483 financial rows, 92 audit-regulator-return entries, and the addresses behind them. Existing data was migrated in through ETL scripts rather than retyped. Change notifications run through n8n, so an edit or a moved job emails the right people without anyone polling.

No dedicated server, no container to patch, no standing bill. The free tiers of Cloudflare Pages and Supabase aren't a trial that quietly degrades — for a dataset of a few hundred clients and a handful of daily users they are simply enough.

The exit path was designed on day one: when the firm grows past the free tiers, the move is a rented server in their own name and a connection-string change. The schema travels as-is, so the migration is a configuration change rather than a rebuild.

IF YOU LIKED THIS

Want one of these in your inbox once a month?