A regulated valuation platform, live in four weeks

Every valuation Archers produce passes through the same sequence: a request arrives, a valuer is assigned, 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. As volume and headcount grew, the cost of it 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, 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 answer precisely.

The output 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 on AWS through SST — separate staging and production environments wired to Git.

None of those choices are exotic. That is deliberate: a firm this size should never depend on one supplier to keep its core system running. 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 the 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 deciding which of them deserve to survive.

That is what the scoping sprint does, in the first two weeks of every project. The build follows the plan.