Introduction

A veterinary practice whose working referral tool was killed by a plan restructure that tripled their bill and forced five of eight users down to view-only; and a charity's grant tracker abandoned within three weeks because a trustee reviewed applications on paper on Sundays — a step nobody would ever have described.

The tool that worked, and then cost three times as much

A veterinary practice had a referral problem. Cases came in from four other practices, went to one of six vets, needed follow-up at intervals nobody was tracking reliably, and lived in a spreadsheet that two people edited and nobody trusted.

Selin built them a tool in six weeks. Records for cases, relations to referring practices, a view per vet, an automation for follow-up reminders, a simple portal for the referring practices to check status. Eight people used it. It worked. The practice manager said it had saved her a day a week, and meant it.

Four months later the platform changed its pricing. Not dramatically, and not unreasonably from the vendor's point of view — a plan restructure that moved from a flat team price to a charge per editing user. The practice's monthly bill roughly tripled.

They could not absorb it. So they cut five of the eight users down to view-only access, which was the cheaper tier — and the tool immediately stopped working, because the entire point of it was that the vets updated their own cases. Within a month, follow-ups were being tracked in a spreadsheet again, by one person, from emails.

Nothing about the build was wrong. The data model was sound, the automations were reliable, the interface was good enough that people used it voluntarily. The business the tool depended on changed its price, and there was nowhere to take the tool. No export that produced a working application. No migration path. The data could come out; the tool could not.

That is rule one, and it is the fact that most distinguishes this trade from every other kind of software work.

The tool nobody used

The second story is quieter and more common.

A small charity tracked grant applications. Selin sat with the fundraising manager, mapped the process carefully, and built exactly what was described: applications, deadlines, a status field, reminders, a reporting view for the board.

It was used enthusiastically for three weeks.

Then it was not. Nobody complained. Nobody asked for changes. At the six-month check-in the fundraising manager was apologetic and vague, and it took twenty minutes to find the actual reason: one of the trustees reviewed shortlisted applications on paper, at home, on Sundays, and marked them up in pencil. That had never come up, because it was not part of the process anybody would describe — it was just how Margaret did it. The tool had no place for it, so the manager kept a parallel spreadsheet to prepare Margaret's pack, and once there were two systems the tool was the one that stopped being updated.

The process the client describes is not the process they run. The difference is never in the main flow. It is in an exception, a workaround, a private spreadsheet, or a person who simply knows — and a tool built on the described version is a tool that gets abandoned without anybody deciding to abandon it.

What this book is about

This is a manual for building internal tools, portals, databases and workflow applications for small organisations without traditional programming, alongside a job.

It covers requirements, data models, user roles and permissions, interfaces, automations, integrations, testing, deployment, documentation and support. But the reason those two stories open it is that platform skill is not what decides whether this works as a business. Four structural facts do, and most no-code advice mentions none of them.

The four rules

Rule one — the platform is the business, and its pricing is not yours.

Your client's tool is not a thing they own. It is a configuration inside somebody else's product, and that product's owner sets the per-user price, the plan structure, the record limits, the feature set and the deprecation schedule. They can change any of it, and unlike almost any other kind of software there is no meaningful way to take the tool elsewhere — the data will come out, and the application will not. You chose the platform, which means the client will experience its decisions as yours.

Rule two — the process they describe is not the process they run.

Everybody describes the clean version. The real version has exceptions that outnumber the rule, a workaround somebody invented in 2019, a spreadsheet that exists because the official system does not do something, and at least one person who holds a piece of the process in their head. A tool built on the described version encodes a fiction, and its failure mode is not a bug. It is quiet abandonment, discovered months later, with nobody able to say exactly when it stopped.

Rule three — every platform has a ceiling, and you find it late.

Record counts. Relation depth. Performance with real volume. A conditional case the automation builder cannot express. A permission requirement the model does not support. You do not hit these in discovery, when everything looks feasible. You hit them at eighty percent complete, after the client has committed and started restructuring how they work, and all three available options are bad: a workaround that makes the tool fragile, a second platform bolted alongside, or a rebuild.

Rule four — there is no staging, no version history and no undo.

The entire promise of no-code is that people who are not developers can change things. That promise is real, which means they will — and there is no branch, no review, no deploy step, and frequently no undo. Somebody deletes a field on Tuesday afternoon and the data in it is gone. Somebody edits a shared view and it changes for everybody. Somebody adds an automation that triggers another automation. The change is live at the moment it is made, on the only copy that exists.

And the interaction is the whole risk. Rule two makes the tool wrong. Rule three makes it unfixable in the obvious way. Rule four makes it breakable by anybody. And rule one means the ground it stands on belongs to somebody who has never heard of your client. That is why procedure and process-reading, rather than platform fluency, are what make this business work.

The numbers this book is built on

The economic unit is revenue per tool under support — what a tool returns across a year of changes, platform updates, new requirements, permission adjustments and the questions that arrive because somebody new joined.

The leading indicator is hours per tool-month, tracked as a curve. It should fall sharply after the first months as the tool settles and the client learns it, then flatten. A tool whose hours never fall has a findable cause.

The master variable is adoption — the share of intended users who actually use the tool in a normal week. It is not a soft measure. It predicts renewal, referral, expansion and whether the client keeps paying platform fees at all, and it is the direct consequence of rule two. A tool with high adoption is a business; a tool with low adoption is a spreadsheet with extra steps, waiting to be cancelled.

And the risk indicator is the count of supported tools without a recent tested data export. Target zero. Because rule one means you cannot take the application anywhere — but you can almost always take the data, and a client facing a price change, a deprecation or a platform decision with no current export is a client with no options at all. It is the analogue of an untested backup: nothing happens the quarter you skip it, and when it matters it is far too late.

How to use this book

Read Part One in order. Chapters 5 to 8 are the four rules in full, and everything afterwards depends on them.

Everything else can be read as needed. Part Two sets the business up — screening, discovery, the plan, the budget, the questions for somebody qualified, the platform standard and pricing. Part Three is the work itself: data models, roles, interfaces, automations, integrations, deployment and clients. Part Four is the money and the records. Part Five is the year, the procedures, the numbers and the plans.

There are sixty-eight resources at the back and one hundred and forty-eight AI prompts, four per chapter. The ⚠ symbol marks a risk, a load-bearing constraint, or a clause in a prompt you should not delete when you adapt it.

Two things to do before anything else. Read your own employment contract, including any intellectual property and conflict clauses. And take Chapter 15 and Resource 18 to somebody qualified where you are — liability, personal data on a platform you do not control, where that data physically sits, who is responsible for what between you and the vendor, and insurance — before you accept a client rather than during your first year.

And one habit to start immediately: a scheduled, tested data export for every tool you support. It is the only protection any of your clients have against rule one, it takes minutes, and it is the first thing that stops being done.

©2026 James Henderson / https://localhandyman.work

Chapter 1 — What No-Code App Development Actually Is

You are not building software, you are encoding somebody's real working life — and it has exceptions nobody has mentioned.

1.1 The job is not building the tool

Building the tool is perhaps a quarter of it, and it is the quarter people picture.

The rest is finding out how the work actually happens rather than how it is described, deciding what a record represents before anybody builds a screen, working out whether the platform can do the thing at all, getting people to use something that changes their day, and then keeping it alive on a product somebody else owns.

The distinguishing feature of this trade is that you are not building software. You are encoding a process — and the process is somebody's real working life, it has exceptions nobody has mentioned, and it is currently held together by a spreadsheet and a person who knows.

⚠ If you are good at platforms and bad at asking questions, this business will not work. The failures are almost never technical. Chapter 6.1.

1.2 What you are actually selling

Not screens. Not automations. Not a database.

You are selling a process that runs, that people actually use, and that somebody is keeping alive. Four separate things: that it models the real work, that it works on the platform, that the people it is for open it voluntarily, and that somebody is watching when the ground moves.

Clients buy the first two. They assume the third — because they asked for it, so obviously people will use it. And they have not considered the fourth at all. Chapter 4.3.

⚠ Sell the four, priced separately, from the first conversation. A tool sold as a finished object is a support conversation you will have anyway, later, from a weaker position. Chapter 27.1.

1.3 Why "an app" is the wrong unit

The word hides an enormous amount.

"A simple tool to track jobs" can mean one table, three fields and a filtered view, which is an evening. It can mean the same thing with five user roles who must not see each other's data, an integration with an accounts system, an approval step, a client-facing portal and four years of historical records to migrate — which is three months. Both are described identically, by the same kind of client, in the same tone.

The unit that predicts effort is not the tool. It is the number of user roles, the number of integrations you do not control, the number of exceptions in the real process, and how close the requirement runs to the platform's ceiling. Chapter 11.3.

⚠ When somebody says "just a simple database", the word doing the work is "simple", and it means they have pictured the main flow. Chapter 6.1.

1.4 The four rules, in brief

Rule one — the platform is the business, and its pricing is not yours. Your client's tool is a configuration in somebody else's product, and there is no meaningful way to take it elsewhere. Chapter 5.

Rule two — the process they describe is not the process they run. The difference hides in exceptions, workarounds, a private spreadsheet, and a person who simply knows. Chapter 6.

Rule three — every platform has a ceiling, and you find it late. At eighty percent complete, after the client has committed. Chapter 7.

Rule four — there is no staging, no version history and no undo. Anybody can change anything, live, on the only copy that exists. Chapter 8.

And the interaction is the risk. Two makes the tool wrong, three makes it hard to fix, four makes it breakable by anybody, and one means the ground belongs to a company that has never heard of your client.

1.5 What makes this different from writing code

Worth stating plainly, because people arrive here from both directions and both sets of assumptions fail.

From coding. There is no version control, no branch, no code review, no test suite, no rollback and frequently no undo. Chapter 8.1. There is also a hard ceiling you cannot engineer past, which is unfamiliar and infuriating.

From spreadsheets. There is a data model, and getting it wrong is not a formatting problem — it is a rebuild. Chapter 20.7.

And from both. The tool is on somebody else's platform, at somebody else's price, with somebody else's roadmap.

⚠ The technical skill that matters most is knowing where the walls are before you promise anything, which is knowledge rather than ability and takes real time to acquire. Chapter 7.9.

1.6 Who is realistically good at this

Not the fastest builder.

Somebody who can watch rather than ask. The single highest-value skill in the trade is sitting next to somebody and saying "show me the last five" instead of "how does this usually work". Chapter 11.2.

Somebody who notices the workaround and asks why it exists rather than designing it away.

Somebody who will tell a client the platform cannot do the thing, early, when it is a scoping conversation rather than a crisis.

And somebody who writes things down, because there is no code to read later and the tool does not explain itself.

⚠ Temperamentally, the trait that matters most is patience with people describing their own work badly. Everybody does it, it is not a failing, and impatience with it produces tools nobody uses. Chapter 6.2.

1.7 What it costs you in a normal week

Build blocks. Evenings and weekend mornings, where the visible progress happens.

Change windows. Small, frequent, and interrupting — a new field, a permission fix, a report somebody needs. Chapter 33.2.

And obligation load — the standing awareness of every supported tool: a platform announcement, a plan change, an integration that might have expired, an export that has not run. Chapter 33.1.

⚠ The second one is what surprises people. A supported tool generates a steady trickle of small requests, and a trickle across eight tools is a river. Chapter 29.2.

1.8 The skill that actually decides your margin

Not platform fluency.

It is getting the requirements right the first time, which means the data model and the roles, which means having found the real process. Chapter 20.1.

A tool built on the wrong model is not fixed by more work — it is rebuilt. A tool built for the described process is not fixed by training — it is abandoned. Both failures happen at the requirements stage, and both are invisible until much later.

And that compounds into adoption, which is this book's master variable, because a tool nobody uses produces no renewals, no referrals, no expansion and eventually no client. Chapter 35.4.

⚠ The economics of this trade are decided in the first week, in a room, watching somebody work. Chapter 11.2.

1.9 What this book assumes

That you have a job and a few evenings. That you can learn a platform properly — one, deeply, rather than five superficially. That you have very little to spend beyond a subscription and a domain.

That you have not yet built something that eleven people depend on, which is where everything changes.

And that nothing here names a platform, a vendor, a plan, a price, a limit or a feature — because all of them change, and a specific quoted from memory is exactly what rule one and rule three punish. Everything in this book tells you what to verify rather than what the answer is.

1.10 Chapter summary

Building the tool is a quarter of it. You are encoding somebody's real working life, and it has exceptions nobody has mentioned. You are selling four things — that it models the real work, that the platform can do it, that people use it voluntarily, and that somebody is watching — and clients buy two. "A simple tool" ranges from an evening to three months, and the predictors are user roles, uncontrolled integrations, process exceptions and proximity to the platform's ceiling. It differs from coding in having no version control and a hard wall, and from spreadsheets in having a data model whose mistakes are rebuilds. The people who do well watch rather than ask, notice workarounds, and say early when a platform cannot do something. And margin is decided in the first week, in a room, watching somebody work.

AI prompts for this chapter

Prompt 1 — Separating the four things being bought

Here is a client enquiry about an internal tool: [PASTE]. Separate what they are asking for into four things — that it models how the work actually happens, that the platform can support it, that the intended users will actually use it, and that somebody maintains it as the platform changes. ⚠ Do not estimate hours or cost. ⚠ Do not name any platform, vendor, plan or feature. ⚠ Identify which of the four the enquiry does not mention at all, as questions for me to ask.

Prompt 2 — Unpacking "just a simple tool"

Here is how a client described what they want: [PASTE]. List every ambiguity that could change the effort by more than double — number of user roles and what each may see, integrations and who owns them, historical data to migrate, approval or review steps, external or client-facing access, and reporting needs. ⚠ Do not resolve any ambiguity by assuming the common case. ⚠ Do not produce a specification. ⚠ Output questions only, ordered by how much the answer changes the work.

Prompt 3 — Self-assessment against the four rules

Here is my background and available time: [PASTE]. Ask me the questions that would establish whether I am suited to a trade where the platform's pricing and roadmap are not mine, where clients describe their process inaccurately without meaning to, where the platform has a ceiling I will find late, and where any user can change the live tool irreversibly. ⚠ Do not reassure me. ⚠ Do not treat platform fluency as the main variable. ⚠ Include patience with people describing their own work badly as an explicit question.

Prompt 4 — Counting my three kinds of time

Here is my week: [PASTE]. Separate it into build blocks, change windows for supported tools, and background obligation load. ⚠ Treat obligation load as consumed capacity even in weeks when nothing happens. ⚠ Treat small change requests as frequent and interrupting rather than batchable. ⚠ State how many supported tools this week could realistically carry, and what the number depends on.

⚠ AI checkpoint for this chapter

One — did it name a platform, vendor, plan, price or limit? All of those change, and a stale specific is exactly what rules one and three punish. Chapter 37.4.

Two — did it estimate effort from a description? The predictors are roles, integrations, process exceptions and ceiling proximity, none of which appear in a first email.

Three — did it treat platform fluency as the main variable? Getting the requirements right decides margin; the platform is learnable and the process is not guessable.

Four — did it treat small change requests as batchable? They are frequent and interrupting, and a trickle across eight tools is a river. Chapter 33.2.

Do This Now

1. Write down, in one sentence, what you are selling — and check it includes adoption and maintenance.

2. Count your three kinds of time separately: build blocks, change windows, obligation load.

3. Read your employment contract, including the IP and conflict clauses, this week.

4. Decide now that you will verify every platform specific against current vendor documentation rather than memory.

5. Complete Resource 1, the ten-question self-assessment, and Resource 3, the four-rules reference.

©2026 James Henderson / https://localhandyman.work