Replacing a business that ran on email and spreadsheets

Every valuation Archers produce passes through the same sequence: a request arrives, someone assigns a valuer, a fee is estimated and agreed, the valuation is carried out, a report is drafted, reviewed, approved, and submitted to the regulator. Then it is invoiced.

All of that ran on email, spreadsheets and individual memory. It worked — until volume and headcount grew, at which point the cost of it working stopped being invisible. Nobody could answer “where is this one?” without asking someone. Nothing was reportable. Two people doing the same job did it differently, and both were right, because there was no defined way.

Archers’ staff need depth: assignment, drafting, review, approval, invoicing, full history. Their external partners — agents, brokers, referrers — need almost none of that. They need to submit a request, approve a fee, and collect a finished report.

So it is two applications over one database and one permissions model. Staff get the CRM; partners get a portal that shows them exactly their own work and nothing else. Role- and permission-based access throughout, because “who can see this” is a question a regulated firm has to be able to answer precisely.

The output of all this is a valuation report in a format the regulator defines. That constraint shapes everything upstream: the fields captured during a valuation exist because the report needs them, and the review workflow exists because someone has to be accountable for what is submitted.

So the reporting engine is template-driven — structured data captured in the app is mapped onto branded report templates and rendered to PDF. Reports move through draft, review, changes-requested and approved before anything leaves the building.

Next.js and TypeScript throughout, Postgres with a typed ORM, authentication with fine-grained roles, file storage with signed URLs, and infrastructure defined as code with separate staging and production environments wired to Git.

None of those choices are exotic. That is deliberate: a firm this size should never be in a position where only one person on earth can maintain their core system. The stack is conventional so that it is replaceable — including replacing us.

If your business runs on a process that lives in email, spreadsheets and the heads of three people who have been there longest, the hardest part of replacing it is not the software. It is writing down what the process actually is — including the exceptions — and then deciding which of them deserve to survive.

That is the work we do first, and it is why we sell it separately. The build is the easy half.