Work / Workflow product

The Quote Import Tool That Returned 30-60 Hours a Week to a 12-Person Estimating Team

A ~50-person controls contractor quoted every job by retyping the same facts through three disconnected systems, twice at the seams. A deterministic browse-review-save tool closed both seams, shipped through beta into production, and grew across product lines, export paths, and pricing workflows after launch.

Anonymized. Client, employer, project, manufacturer, part, and pricing identifiers are removed; the mechanism and the numbers are real.

The user and their week

An estimator at the contractor built each quote by moving the same set of facts through three systems. Takeoff markups went into a vendor design and BOM tool, and that tool's device list went into the quoting system, retyped by hand at both seams on a workflow the team ran hundreds of times a year.

One of those systems also carried a defect: it silently summed unit prices when it consolidated duplicate rows, corrupting the quote's money with no warning to the person keying it in. The estimator worked on a locked-down workstation: no Python, no installs, no admin rights, no localhost, no network.

Why it mattered

The twelve-person estimating team ran roughly 300 quotes a week. Inside that flow, the seams I inherited covered one manufacturer's share of the work, about 10-20% of the team's quotes.

That put 30 to 60 of the team's weekly quotes inside the tool's scope, at roughly an hour of manual re-entry apiece, the exact shape of the 30-60 hours a week the tool would eventually give back. The other 80% of the team's flow ran through different manufacturers with different schemas at each end, the same three-seam shape repeated, and stayed out of scope for this build.

The bet, and what was rejected

I bet on a portable, offline Windows executable an estimator could run with no install and no server, because the locked-down workstation ruled out anything else. The first build used Streamlit for speed to a working mapping, shipped in 21.0 hours, and covered only the vendor-BOM-to-quoting seam.

That MVP proved the mapping and then died on the environment: Streamlit needs a localhost server and a browser, both ruled out by the same constraint that set the whole architecture. I rewrote the UI as a native desktop application, no web server, no localhost, no network, and used the rewrite to add the second seam, takeoff parsing, plus duplicate-row consolidation, in 11.5 hours.

Productizing the tool into a paid service tier came up later and was evaluated and deliberately turned down; see Adoption below.

Acceptance criteria, set before build

What the record does show is the constraint that fixed the delivery shape before any parsing logic existed: locked-down workstation, no install, no admin rights, no network, which forced a single portable executable distributed by shared drive or email. The properties that held for the tool's whole life read like the bar it was actually built to: no runtime AI so the conversion stays deterministic, fully offline, all-or-nothing output so a partial quote can never be emitted, and a save button that stays disabled until the data validates, with no warn-and-proceed path around it.

What shipped

A parser, validator, and XML/CSV builders covering the vendor-BOM-to-quoting seam, packaged as a standalone Windows executable
A native desktop rewrite adding the takeoff-to-BOM seam and duplicate-row consolidation
Beta round 1: a Removed Items view, auto-exclusion of about 20 known-bad parts flagged for manual entry, phase order matched to the real field workflow, copy/paste support for the manual re-entry step
Beta round 2: removed items split into must-key-by-hand versus safe-to-ignore, plus a warning against shipping a quote with manual-entry parts missing
Post-launch: a second export path bypassing the BOM tool, a sibling product line folded in, auto-add of a required accessory for five incomplete-assembly prefixes, and pricing against a 171-product master sheet with unmatched parts flagged

Three systems, two seams. Every quote used to be retyped at both of them. The tool sits across both seams now and will not save until the data checks out.

What failed, and what changed

Neither beta round produced feedback about the conversion math. Every note was about what the tool hid and the order it asked the estimator to work in.

After launch the failures moved upstream. The vendor's price-summing defect got an override table on my side of the seam, since the source sat outside my control and could not be fixed there; that override then matched too broadly and rewrote prices it should not have touched, and I scoped it down two months later, the fix for one data-integrity bug having introduced a second one in the same column.

The vendor's export format changed twice in eight days and broke production both times; the code still carries a column-alias workaround as a scar from that rename. A feature once shipped into the wrong workflow step, was disabled pending correct placement, then re-enabled and relocated five weeks later, and internal phase naming was swapped a second time to match how the estimators actually worked the job.

Across all of it, every post-launch fix traced back to an upstream schema change or a workaround for one; none were bugs in the conversion logic itself.

Result

I shipped the tool over 45.0 hours of build effort across 24 phases, 37 commits over 236 days, 2,168 lines of code, 13 shipped executable builds, and 12 documented releases.

It has been in production since early 2026, still on the shipped version, with no rollbacks after release and 6.0 hours of lifetime post-launch maintenance.

Reach is an estimated 50 people: about 30 given the tool and expected to use it, and about 20 more with access and no expectation to.

Against that, the estimating team's 300 weekly quotes include 30 to 60 that fall inside the tool's scope, each previously costing about an hour of manual re-entry, for an estimated 30 to 60 hours a week returned to that team. That figure is an owner estimate from watching the workflow; nothing measured it, since there is no usage telemetry, no before-and-after error rate, and no measured time-per-quote, because the offline-executable delivery model was never instrumented.

Even so, against 45 hours of total build effort, the tool repays its own construction cost inside the first week or two of use at the low end of the estimate.

Adoption, and what carries forward

The tool is dormant and stable now: it stopped changing because the workflow it serves stopped changing. Known debt remains on record: two forked version-numbering schemes with shipped builds under each, two user guides that still describe the abandoned Streamlit build and contradict the current config on price passthrough, an empty fixtures directory, and test dependencies missing from the project's own virtual environment.

What carries forward is the interface contract, a single offline executable, no install, no runtime AI, browse-preview-save, which became the template for later tools built the same way. I evaluated moving the tool into a paid service tier and turned it down: the defensible part of the work is the domain trap list built up through the post-launch fixes, and the converter itself is the reproducible part.

The clearest lesson for the next build is to instrument from day one. I have a complete build and cost record and no usage data, so I can state exactly what the tool cost and only estimate what it saved; the fix is one line appended to a local log per run, timestamp, phase, row counts, error count, version, collected whenever a number is needed and built in at v1 because nobody goes back and adds it later.