Case study: Building Contractor Co-Pilot

We built Contractor Co-Pilot because we have lived inside the problem.

The founder of Ochre grew up in his family's landscape business and spent years as a commercial estimator inside it. The job was supposed to be: figure out what each project would cost, write the quote, get it out the door. The reality was: nothing was unified. Pricing lived in someone's head or in last year's spreadsheet. Labor rates lived somewhere else. Blueprints came in as PDFs that had to be re-measured by hand on a printed copy. Customer history was in an email thread. Change orders were in a notebook. Margin calculations were redone from scratch on every quote.

Picture the actual workflow. A plan set comes in for a commercial property — a hardscape job, a parking lot, a multi-phase site. The estimator pulls the PDFs onto a screen, prints the relevant sheets, gets out a marker, and walks through them measuring. Square footage of patios. Linear footage of retaining wall. Cubic yards of soil to move. Each measurement gets typed into a spreadsheet. Then the estimator goes hunting for the rate that matches each line — checking last year's pricing, calling a supplier for an updated material quote, asking the foreman what the labor crew can actually finish in a day. By the end of the day there is a number. The owner asks, "Are we sure?" The estimator shrugs.

This is not unusual. It is the construction back office. Most contractors run their business this way and have for decades. The cost is invisible because everyone pays it.

CC is our attempt to take that cost down.

What CC actually is

CC is an operating system for construction businesses. It runs the back office: estimating, takeoffs, projects, change orders, invoices, costs, suppliers, clients, scheduling, and the dozens of documents that move between them. It uses AI inside that system to help draft quotes, read documents, and connect information that would otherwise live in separate places.

It is not a chatbot. It is not a single AI feature bolted onto something else. It is the room where the work actually happens — with AI built into the parts where AI helps, and out of the parts where it does not.

This distinction is worth being explicit about. Most "AI for construction" software is a bolt-on: a model sitting next to the spreadsheet the contractor actually uses, available to answer questions but unable to finish a quote, persist what you taught it, or stay coherent across the dozens of decisions that go into a project. The work still lives somewhere else; the model just visits.

We built CC the other way around. The work lives in the system. The AI lives inside the workflows where it earns its keep — drafting quote line items from blueprint measurements, classifying incoming customer emails, summarizing change-order conversations into a written record, suggesting cost-catalog matches when a new material gets entered. The operator is always one click from the AI's output, can correct it inline, and the correction feeds back into the system. The model is part of the workflow, not adjacent to it.

We built it as a small team — really, as one person doing the work — over roughly seven months of focused effort. We restarted it in earnest in July 2025, worked day jobs while building it at night, and committed to it full-time on February 28, 2026.

We work in disciplined phases. Foundation first, then verification, then user experience, then launch. We hold each before moving to the next. Polish on a shaky foundation compounds breakage; we would rather slow down for that than fix it after the fact.

We are publishing this case study because the lessons that came out of the build are the lessons. The patterns that hold up in a real construction system are the same patterns we hand to your team when we work with you.

The flagship: blueprint takeoffs

Of everything CC does, the part we are proudest of is the takeoff system — the workflow that turns a blueprint PDF into an estimate.

The way most contractors do takeoffs: print the blueprint, get out a marker, measure each thing, type the totals into a spreadsheet, look up the rate for each line, multiply, write the quote.

The way CC does it: upload the PDF; set the scale per page, because different sheets in the same set often have different scales (a site plan at 1" = 30', a detail sheet at 1" = 10'); and draw four kinds of measurements directly on the screen — area, linear, count, and volume. Each measurement automatically becomes a line item in the estimate. The estimate fills in with cost matches and proposed labor tasks, ready for the operator to review.

Walk through it with a typical scenario. An estimator opens a plan set for a commercial parking-lot job. Page one is the site plan; she sets the scale. She draws the parking-lot perimeter — area measurement, square feet — and the system records the geometry as data, not just pixels. She draws the curb line as a linear measurement. She drops counts on the lighting standards. Page two is the grading detail at a different scale; she calibrates that page separately and draws the cut and fill volumes. As she works, each measurement becomes a line item in the estimate behind her, with the unit attached and a proposed cost match pulled from the catalog. The estimate she would have spent the rest of the afternoon writing is mostly written when she finishes drawing.

That last clause — "ready for the operator to review" — is where the whole product turns. The AI drafts the quote. A person reviews it before it leaves the building. The judgment stays with the owner. The speed is the machine's. That line is what CC is for.

This is the hardest thing in CC. Drawing on a blueprint at full scale has to feel like marking up a paper printout — zero lag on pan and zoom, no flicker when you stop moving, no half-saved measurements when something fails. Estimators have been using markers for decades; the bar to clear is "as fast as my hand on paper," or the switch is not worth making. We rebuilt the canvas from scratch when our first version felt sluggish. None of that work is glamorous. All of it is necessary, because if the tool feels slower than a marker on paper, nobody uses it.

The lesson worth naming from this is simple: the tool is only as good as the data behind it. Beautiful measurements going into a sloppy cost catalog produce a beautiful, confidently wrong quote. The takeoff system is the bridge between capture and intelligence. Both halves have to be tight.

Patterns that held up

A handful of patterns kept reasserting themselves across the build. They are the patterns we now bring to other businesses.

The line between AI and human judgment is the whole product

The estimating workflow is the clearest example: AI drafts; a person reviews. AI works best when it is asked to draft, retrieve, classify, or summarize — and worst when it is asked to decide. Every screen that violated that line had to be redrawn. Drawing it correctly was most of the design work, and getting it wrong on a single screen was usually obvious quickly: an operator pushing back, a draft that was confidently wrong, a workflow that began to feel like a fight rather than a co-write. The right line is the one where the operator stops feeling like they are babysitting the model and starts feeling like the model is leaving them with less of the boring work.

Bad data in is automated bad data out

CC cannot estimate accurately if the supplier prices are stale, the labor rates are wrong, or the project schedule never got entered. The AI is a multiplier. It multiplies the quality of the inputs. The first stretch of any new use of the system is almost always: clean up the data. Decide on a single source of truth for prices, for tasks, for clients. Take the spreadsheet that lives on someone's desktop and make it shared, structured, and current. Until that is done, the model is making confident guesses on top of nothing. The fastest way to lose trust in an AI tool is to let it produce polished outputs from broken inputs; the operator notices the broken outputs first, and after that nothing the system says is taken at face value.

Boring tools, used well, beat clever ones

The most reliable parts of CC are the most boring. A list of materials with prices kept current. A tagged history of what each customer paid last time. A category tree that stays consistent across a year of estimates. The clever parts — chains of AI calls, multi-step reasoning, novel interface patterns — break more often, cost more to maintain, and feel less trustworthy to the operator. We default to boring and add cleverness only when a real workflow visibly required it.

Speed of correction matters more than accuracy of first draft

The AI will be wrong sometimes. The question is how fast the operator can correct it, and whether the correction sticks. Every screen in CC that involves AI output is designed with a one-click fix and a way for the fix to feed back. A bad line item gets edited inline; the edit becomes a signal for the next draft. A blueprint measurement the AI missed gets added by hand; the system learns the page. Without that loop, accuracy degrades and trust evaporates.

Hardening before polish

The temptation is always to chase the demo. We instead set up disciplined phases — foundation, verification, user experience, launch — and refused to advance to polish work while the foundation still had correctness bugs. Every dollar of polish on a shaky foundation compounds breakage. Hardening, in practice, is the unglamorous middle: tightening the database invariants nobody sees, fixing the webhook handler that silently drops a duplicate, auditing the security policy that protects every read, making sure two simultaneous saves cannot leave the system in a half-committed state. None of it is what a customer sees on the demo. All of it is what keeps a product from falling apart when the work gets real. This is the hardest discipline to maintain, and it is the one that makes the system worth handing over.

CC and Ochre share a philosophy

The reason this case study lives on Ochre's site is that CC and Ochre are the same firm with the same belief, expressed in two different ways.

The belief is straightforward. A business should not have to rent capability from someone else. Not from the vendor that set up your AI tools. Not from the consultant that handed you a deck. Not from the agency that built your automations and disappeared. The capability — the knowledge of how it works, the ability to change it when conditions change, the judgment about when to trust the model and when to override it — has to live inside your business.

CC is the product expression of that belief. The contractor runs it themselves, on their own data, on their own terms. Every AI output sits one click from a correction the operator owns, and the correction feeds back into the system. The owner's judgment stays where it should be — with the owner. The model serves the operator. The operator does not serve the model.

Ochre is the service expression of the same belief. We do not show up to do AI for your business. We show up to teach your team how AI actually works, hand over the frameworks we use ourselves, draw the AI-and-human-judgment line on your specific workflows, and stay close while your people build. When we leave, the capability lives inside your business — because the people in your business are the ones who built it.

Different surfaces. Same posture. Same refusal to make you dependent on us. The patterns above are not just product design choices; they are what that belief looks like when you actually build with it.

What this means for an Ochre engagement

When we work with your business, we bring the experience of having built CC into the room. Not as theory — as lived discipline. The same one that produced CC's takeoff workflow. The same one that says no to a polished demo when the foundation underneath it is shaky. The same one that draws the line between AI and human decision on every screen rather than letting the model drift into territory it should not own.

The early stretch of any engagement looks the same regardless of industry: figure out what AI is actually being asked to do, find where the data lives and where it does not, draw the line between AI and human decision on each workflow, and start with the part of the back office that breaks worst. We hand over the frameworks. We sit close while your team builds. And we leave you with a system you can keep sharpening once we are gone.

For the methodology behind this work, read The Enabler's Playbook. For the data foundation that makes any of it possible, read Organization context before models.