PrecisionDocs

PrecisionDocs Platform v1: what we built and why

A retrospective on the first year of PrecisionDocs. The pieces that worked, the pieces we threw out, and the decisions we still argue about on Slack.

· 10 min read · PrecisionDocs Team

We started PrecisionDocs as a report wizard. The product we shipped a year later is a chat agent. The distance between those two things is most of what we learned in year one.

The original thesis

The first version of the product was a structured wizard for Due Diligence Reports. The user entered a parcel, walked through a series of forms, and at the end received a Word document that looked like every other due diligence report a junior engineer has produced in the past fifteen years.

The wizard worked. The document it produced was defensible. But every user we talked to, after the first time they used the product, did the same thing on the second visit. They ignored the form and typed a question.

The question was the signal. The form was a forcing function we had imposed to make the AI behave, and the users were routing around it.

The pivot to chat

We rebuilt the interface around the question. The chat agent we shipped in the second quarter of 2024 could answer ordinance questions, pull flood zone data, retrieve soils reports, and produce a draft memorandum when asked. The report wizard became one of the agent's tools.

The tradeoffs were immediate and, in retrospect, obvious.

The good. Users got answers in minutes that used to take days. The unit of work shrank from "produce a report" to "answer the question I have right now." That was the unit of work the users had wanted all along.

The hard. The chat interface required the agent to be right far more often than the wizard had. The wizard had hidden the ambiguity inside a rigid flow. The chat surfaced it. If the agent misread a zoning classification, the user saw it instantly. That raised the quality bar, and we spent the rest of the year raising the product to meet it.

What we threw out

Several pieces went to the scrap heap.

The multi-step report wizard. It was polished, technically interesting, and nobody wanted it.

An autofill feature for variance applications. We built a prototype, ran it past three licensed engineers, and every one of them said the same thing. They were not going to sign a filing they had not written. The feature was shelved before it shipped.

An internal "confidence score" that rated each answer from zero to one hundred. We used it for telemetry in development. We decided not to show it to users. A confidence score is information the model has about itself, not information the user can act on. A better answer than "this is 78% correct" is "here are the three sources I used, go check them."

A proprietary "flood risk score." Same reason. The FEMA zone letter is the industry standard. The user already knows what Zone AE means. Inventing a new scalar on top of it was substituting a confidence trick for the actual information.

What we kept

Citations, from day one. Every factual claim the agent makes links to a source. This was not negotiable. It is the reason the professionals in our audience trust the output.

Public source by default. The agent prefers FEMA, USDA, USGS, Municode, AmLegal, and county GIS over proprietary aggregators. We use aggregators where the public source is unreliable or missing. We label the difference.

The document store. Users upload the parcel's prior reports, surveys, and title work. The agent reads them, cites them, and uses them as a supplement to public data.

The audit trail. Every research session produces an exportable record of questions, tools called, and sources consulted. It exists because the professional needs to reproduce the work.

The pieces that are still contested

Memory. Whether the agent should carry context from one session to the next, and how much, is an active debate. The trade-off is personalization versus the risk of the agent silently importing wrong assumptions from a prior project.

Pricing. We started with a token-based model and moved to a seat-based model. The seat model reads better to the professional services firms we serve. The token model gave us cleaner unit economics. We are ending up closer to seat, with token caps as the abuse control.

The right depth for environmental data. Wetlands, endangered species, and contaminated site data vary enormously by state. Building a uniform pipeline across fifty states is a project that is always larger than the estimate. We cover the high-volume states well and the long tail with degradation.

The lessons, transferable

One. A rigid UI is a hiding place for an uncertain product. If the model is not confident, a form can fake confidence. A chat cannot. Chat is the honest interface, which is why it is also the hardest one to ship.

Two. The audience for a professional tool is smaller than the audience for a consumer tool, and they have sharper opinions. If the product is not right, they will tell you. They will also trust it forever once it is right. That is a better long-term business than viral growth.

Three. Citations cost latency. They earn trust. Trade latency.

Four. Professionals do not want their license outsourced to a confidence gauge. They want the evidence. Build for the evidence.

Year two is about making the agent good enough that a working professional uses it the way they use a calculator. Not the thing that does the work. The thing that makes the work honest.

More insights