The build where writing code would have been the wrong answer.

The problem

Napier is a B2B technology PR and marketing agency in Chichester, founded in 1984. Quoting was slow, so their MD built an Airtable base himself to speed it up. Two pricing modes: a fixed selling price, or an hourly rate pulled from a standard rates table.

It worked, and then it ran into the wall that every MVP built by its own user runs into. Activity types were free text, so the same category got typed four different ways. There was no way to duplicate a quote, group lines under headings, or archive anything. Quantities read as bare numbers with no unit, so a "5" could mean five hours or five press releases. The editing interfaces were rough enough that using them was its own friction.

The brief was to make it robust and easy to use, under one hard constraint: no code. Native Airtable and automations only.

What I did

The constraint is the interesting part, so start there. A developer's instinct here is to argue for custom software, or at least a script or two. That instinct is wrong, and it is wrong for a reason worth naming: Napier's real requirement was not capability, it was maintainability. They can afford custom code. What they cannot afford is a system only its author understands, in a building where nobody writes code. The moment I add a script, I have made myself load-bearing, and the base degrades the day I stop answering messages.

So the explicit goal of the engagement is to put myself out of a job. Leave behind something documented and simple enough that their team runs it, extends it, and stops needing me.

• Turned free-text activity types into a managed table, so categories are chosen rather than retyped, price-list items can be moved between them, and quote lines can be grouped by type. This is the change everything else depended on.
• Made quotes actually workable: duplicate a quote with a new client and name, copy selected lines between quotes, insert heading lines for structure, add notes, and a unit field so quantities read as what they are.
• Added an archive path, and a delete that warns first, kept behind a system-management area rather than sitting next to everyday controls.
• Rebuilt the quote interfaces up to the standard of the best screen they already had, so the polish is consistent rather than a new dialect.
• Sequenced by trust, not by size. The engagement runs about ten proposed ideas to one approved per cycle, so I lead with small, visible wins. The unit field first, then notes, then archiving, then the structural work. Earning the right to touch the important parts beats being right about them early.

The detail that mattered: choosing not to be clever. Every improvement had to survive being handed to a non-technical team with no developer on staff. That rules out the elegant solution roughly half the time, and it is the correct trade whenever the system has to outlive the person who built it.

Outcome

• Quoting is faster and the base is legible to the people who use it daily, with no code in it.
• The team extends it themselves, which was the point. The success signal is them asking for features because they can now imagine them, not because they are stuck.
• Ongoing engagement, and the client relationship is the healthy kind: happy, low-drama, and increasingly self-sufficient.