Why I built CSR Foundry

For twenty years, I've watched cost estimators do extraordinary work inside tools that were already outdated when I started.

The pattern is consistent. A new hire spends their first six months learning the company's estimating workflow — which is really a patchwork of a twenty-year-old Windows desktop application, a shared network drive full of spreadsheets nobody can find, and a handful of tribal customs that live only in one senior estimator's head. They produce estimates that drive real decisions on real projects worth tens or hundreds of millions of dollars. And every part of the process — the software, the file management, the review cycles — is held together by estimator willpower.

The estimators are good. The tools are the problem.

The specific pain

I don't mean "the tools are a little clunky." I mean specific, recurring, load-bearing failures:

• Estimates live in spreadsheets with formulas that break when someone inserts a row. A bad insert in the wrong place silently zeros out a summary total, and nobody notices until the bid is already out the door.
• Production rates, crew compositions, and unit prices from last year's jobs get copy-pasted into this year's estimates, with the copy-paste degrading a little each time. The institutional knowledge that should compound instead decays.
• Reviewers mark up PDFs, email comments back, and hope the estimator incorporates them before the next version. There's no real audit trail. Nothing prevents the same error from recurring on the next pursuit.
• Multiple estimators can't work on the same project simultaneously. When they try, they ship spreadsheet copies back and forth and manually merge edits, which is both slow and risky.

These aren't edge cases. These are Tuesday.

Why nobody fixed it

Partly because the incumbent software vendors have no pressure to change. Construction estimating is a specialized market; the costs of switching are high; the existing tools technically work. Partly because every adjacent discipline in construction — design, scheduling, project controls — has modernized in the last decade, which absorbed the attention and capital that might otherwise have gone to estimating.

And partly because the people who know what estimating software should do — practicing estimators — don't typically write software.

What I decided to build

CSR Foundry starts from three choices:

First: estimates should be structured like the work, not like a spreadsheet. Cost folders mirror the work breakdown structure. Edit a leaf, and the parents recalculate — not through a formula that can break but through an actual tree data structure that can't. Reference libraries hold crews, equipment, materials, and production rates where every estimate can draw from the same source of truth.

Second: AI should assist, not replace. The AI sidebar in CSR Foundry can read a spec section and suggest bid items. It can flag quantity inconsistencies. It can summarize a 200-page addendum. It doesn't write to the estimate without the estimator's explicit approval. The estimator stays accountable for the number, because the estimator is the one who actually has to answer for it.

Third: institutional knowledge belongs in the product. The reference libraries aren't just a convenience — they're the mechanism by which every estimate compounds the company's learning instead of duplicating it.

Early access, now

CSR Foundry is in production use with early access users today. If you've spent any time estimating with tools that make you feel like you're fighting them — I'd like to hear from you. Early access is open at sales@csrfoundry.net.

The tools won't improve themselves. Let's go.