Bid-Leveling: the first app, designed from a blank page and one long conversation

What bid-leveling actually is

When a general contractor prices a job, subcontractors send in bids for their portion of the work. Those bids never arrive in the same shape. One electrician includes the panels, another excludes them. One includes a bond, another does not mention it. One quotes labor and material together, another splits them.

Leveling is the work of making those bids genuinely comparable — finding what each one includes and excludes, adding back what is missing, and putting them side by side so the estimator can see the real number rather than the quoted one. Get it wrong and you either lose the job or win it at a price that costs you money.

Most estimators do this in a spreadsheet they built themselves and would not let anyone else touch.

Starting with the person, not the product

I had no construction background when I started. That turned out to be useful — I had no choice but to ask the Director of Estimating to explain everything, and to keep asking until it made sense.

We started with what he used now: which tools he had tried, which he had abandoned, and specifically where each one failed him. Not a feature wishlist. A catalogue of frustrations, each attached to a real moment in a real bid.

Then we went the other direction — what would the ideal version look like if nothing constrained it, and what would he actually give up to get there. Somewhere between those two conversations is where the product is.

What the interviews turned up

• The existing tools were built for how software wants bids structured, not for how subcontractors actually send them. Every one of them started by asking the estimator to do data entry the way the tool preferred.
• The genuinely hard part is not the arithmetic. It is scope — knowing what each bid quietly leaves out. No tool was helping with that, which is where all the risk lives.
• He was not looking to be replaced. He wanted the clerical part — transcription, alignment, totalling — to stop eating the hours he needed for judgment.

That last point set the design principle: the software does the bookkeeping, the estimator does the thinking, and the interface never pretends to know which bid is better.

Designing it

I designed the MVP in Figma down to every click interaction — every screen, every state, what happens on hover, what happens when a bid is incomplete, what happens when a scope item exists on one bid and not another. The specification was written so the developer could build it without needing to interpret intent, because he was remote and asynchronous and every ambiguity would have cost us a round trip.

Then I stayed in it. As the build progressed I sat between the product owner and the developer, translating his domain expertise into use cases and written UX direction, and revising the design where the working software revealed something the conversations had not.

Why this one mattered

Bid-Leveling was the proof that the process worked. Audit the landscape, interview the person who owns the problem, find where existing tools fail them, specify completely, iterate through the build. We ran that same loop for the eighteen applications that followed, and for the environment that holds them together.

See the full Todos Build platform →