Labor estimates that get smarter after every job.

The problem

In technical services, the materials on a quote are easy. Every part has a price and a part number. Labor is the guess. How long does it take to install forty cameras across three buildings? To cut over a phone system on a live floor? The answer lives in one or two senior people's heads, and it walks out the door when they do.

So estimates get built from memory and last quarter's spreadsheet. The job is won or lost on a number nobody can defend. And when it goes over, the miss shows up in a margin report months later, disconnected from the estimate that caused it. Nothing in the process learns.

What we built

DarkBird encodes labor knowledge as reusable templates, uses them to build estimates through a guided conversation, and then feeds real project hours back in so the templates correct themselves over time.

• Capture the knowledge once. What a task actually takes, at what quantities, by whom, gets written down as a reusable template instead of living in someone's head.
• Scope by conversation. An AI interview asks the questions a senior estimator would ask, in the right order, and assembles the estimate from the answers.
• Produce the client document. A scope of work in the firm's own house style, generated from the estimate rather than retyped from it.
• Push it into the systems they already run. The approved estimate becomes a real project plan in ConnectWise or HaloPSA, with no re-entry.
• Close the loop. Actual hours come back from the PSA, get compared against the estimate task by task, and adjust the templates for next time.

That last step is the whole point. Plenty of tools produce a quote. Very few make the next quote better.

How we built it

The interesting part of this project isn't the feature list. It's the engineering standards we held ourselves to, because those are the same standards a client project gets.

We measured the AI instead of trusting it

AI features are easy to demo and hard to trust. Two real customer projects had stalled: one ran nine rounds of questions without producing a usable estimate, another ran twenty-two. Rather than rewrite the prompt and hope, we built a scoring harness first and measured the existing behavior against a fixed set of real cases. The baseline turned out to be worse than the complaints suggested.

Then we changed one thing at a time and re-measured. Along the way the harness caught two genuine production bugs that no amount of reading the code would have found, including a data-matching defect that had been silently broken since the day it shipped.

Security was a starting condition, not a phase

The platform is multi-tenant: several companies' commercial data in one system. Isolation is enforced at the database itself rather than trusted to application code, so a mistake in a screen can't leak another company's numbers. Credentials for connected systems are encrypted and only ever decrypted on the server, never handed to the browser. The site runs a strict content security policy to limit what a compromised dependency could do.

Tests so it can keep changing safely

Software you're afraid to change is software you've rented. Every change runs through type checking, the full unit suite and browser tests before it can ship, and the pipeline blocks the merge if any of it fails.

Documentation the build refuses to let rot

Every consultancy says documentation matters. Saying it doesn't keep it current. So we wired the requirement into the build: ship a new settings screen or API tool without documenting it and the build fails. Documentation stopped being a good intention and became a rule the machine enforces.

It meets the existing stack where it is

DarkBird doesn't ask a firm to abandon the systems they already run. It connects to ConnectWise, HaloPSA and HubSpot, and exposes its own API so it can be driven by other tools, including AI assistants. That's the same principle we apply to client work: improve the flow, connect what's there, don't force a rip and replace.

What this means for your project

You're probably not building a labor estimation platform. But the parts that made this one work are the parts that make any build work:

• The process gets fixed before the software gets written. We modeled how estimating actually happens before a line of code existed. Automating the broken version would only have made it fail faster.
• AI gets held to a number. Not "it feels smarter." Measured against real cases, before and after.
• It connects to what you already own. New software that doesn't talk to your existing systems just adds another place to type things twice.
• It's built to be handed over. Tested, documented, and structured so someone else can safely maintain it. We build to leave.