Four builds, in the order they hold each other up.

The revenue pipeline rebuilt as one continuous, auditable chain: estimate, approval, schedule, invoice, payment. Every handoff produces a record. Every action that leaves your building passes a gate. Every stage taps into the same audit log, so a disputed invoice is a query rather than an argument.

This is the build with the fastest visible payback, because it closes the joints where work you already did fails to turn into money you actually collected.

We map your current pipeline stage by stage and mark where things fall through. Then we rebuild the worst joints first, so value lands before the full pipeline is done. Automations go in behind human gates and get promoted to unattended only after they have been observed being right on your real work.

• Versioned estimates built from your real cost basis, not a markup guess
• Customer-facing approval that produces a record of which version was accepted, when, and through what channel
• Scheduling bound to the accepted scope, so booked work and sold work cannot drift apart unnoticed
• Invoices generated from approved scope plus what the field recorded — each line traceable to its source
• Change orders captured where they actually happen, then priced and attached to the job
• Payment reconciliation with exceptions surfaced instead of absorbed
• A per-job audit trail your bookkeeper can read without you in the room

On top of the system of record (CX-101). If you already have one system that holds your jobs honestly, this can be the first engagement.

A question-answering interface over your own business data. You ask which crews ran over on labour last quarter, or which customers have accepted work that was never scheduled, and you get an answer with its work shown — the query it ran, the rows it read, the date range it used.

The hard part is not the language model. It is the refusal: when the data cannot support an answer, the system has to say so rather than produce a confident, plausible, wrong number. That behaviour is engineered, not prompted.

Schema and semantics first: we write down what your business words actually mean — what counts as a job, when revenue is recognized, which statuses are terminal — and encode that vocabulary. Access paths are scoped per role and read-only by default. We evaluate against a set of real questions with known answers before anyone in your company is allowed to trust it.

• A defined vocabulary of your business terms, written down and versioned
• Read-only access paths scoped per role — the field crew and the owner do not see the same rows
• Answers that show the query and the underlying records, not just prose
• Explicit refusal when the data is missing, stale or ambiguous
• An evaluation set of real questions with known answers, run against every change
• Conversation history stored in your tenant, exportable, never used to train anyone’s model
• Optional write actions — always proposed for approval, never executed straight from a chat message

After there is one place worth asking. It is also the interface owners feel first, which makes it a good second build and a poor first one.

The foundation under the other three, and the reason we describe the practice as engineering rather than consulting. Isolation, provenance, append-only history and gated automation are designed in from the first table — they cannot be added later without rebuilding the thing you already paid for.

It is also available on its own: a review of a system you already run and no longer entirely trust, delivered as a written report of what is verifiable, what is assumed, and what is silently guessing.

Inside a build, it is not a phase — it is the standard every table, job and integration is held to. As a standalone review, it is a bounded engagement: we read the schema and the code paths, trace where values come from, test what happens when an upstream source fails, and hand you a prioritized list with the fixes we would make.

• Single-tenant provisioning — your database, your storage, your keys, no pooled index
• Provenance recorded on every field an automation writes
• Append-only history, so corrections are entries rather than overwrites
• Approval gates on every outward action — customer email, invoice, payment, supplier document
• Monitoring that alerts when a source goes stale or an integration starts failing quietly
• Failure behaviour specified: missing data is recorded as missing, never defaulted to zero
• Export in open formats, on request, without an offboarding negotiation

Under everything. If you only buy one thing from this sheet and you already have systems, buy the review.