Custom estimating and job costing software

The spreadsheet is not the problem. It is the specification.

When an estimating workbook has been refined over years, the pricing logic inside it is the most valuable asset the business owns. It encodes real markups, real waste factors, real crew rates and real knowledge of which jobs go wrong.

The failure mode is not the logic. It is everything around it: only one person can edit it, two versions are emailed and diverge, nobody can tell which quote went to the customer, and it cannot be used from a job site. The spreadsheet has outgrown its container.

So the first thing we do is read it. A workbook that captures how you actually price work is a better specification than any requirements document, and we review it before quoting anything fixed.

What gets built

• Customer and project records, so a quote belongs to something
• The estimating engine — your assemblies, your rates, your markup rules
• Labour and material costing, with crew rates and burden handled properly
• Markup and profit as separate, visible numbers rather than one blended fudge
• Quote and proposal PDFs that go out looking like your company
• Revision history — which version the customer accepted, and when
• A job-costing dashboard: estimated against actual, per job

That last one is usually the point. Most firms can estimate. Far fewer can tell you, with confidence, which completed jobs made money and why.

What the spreadsheet cannot tell you

Reading the workbook gives us your pricing logic, but it leaves out the things that live in your head. Which customers get which markup and why. What happens when a supplier price moves mid-quote. Who is allowed to discount, and by how much. Which quotes are deliberately priced to be lost.

Those rules are the difference between software that reproduces your spreadsheet and software you actually use. They surface in conversation, not in cells, which is why the workbook review is a conversation rather than a file transfer. It is also where most of the genuine risk in the project sits: an estimating system that quietly prices work wrong is worse than the spreadsheet it replaced.

Estimating and job costing are two systems

They get named together and built together, but they answer different questions. Estimating asks what this job should cost. Job costing asks what it did cost. The value is in comparing them, and that comparison is only possible if the estimate is captured in a form the actuals can be matched against.

In practice that means agreeing your cost categories once and using the same ones on both sides. If the estimate is broken into assemblies and the actuals arrive as invoices and timesheets against a job number, no dashboard in the world will reconcile them. Getting this structure right at the start is unglamorous and it is the single decision that determines whether the job-costing screen is useful or decorative.

Where the data has to come from

Actual costs live in three places: payroll or timesheets, supplier invoices, and whatever accounting package you run. An estimating system that requires someone to re-key all three will be abandoned within a quarter, because the re-keying is the job nobody wants.

So the integration question has to be asked early. Some accounting packages offer a proper API. Some offer a file export. Some offer neither, and the honest answer is a structured import that someone runs weekly. All three are workable, but they cost different amounts and they change what the dashboard can promise. Find out which one you are dealing with before scoping, not after.

Change orders are where margin disappears

Most construction estimating software handles the original quote well and change orders poorly, which is backwards, because change orders are where profit is won and lost. Work added verbally on site and never priced is the most common margin leak in the trades, and it is invisible until the job closes.

The system needs a path for capturing a change while standing on site: what changed, the cost, and a customer approval that is recorded. It does not need to be elaborate — a timestamped record with a name attached settles almost every dispute that would otherwise be one person's memory against another's. Build that in from the start rather than adding it after the first argument.

Decide who owns it before you decide what it does

Builds start at $1,900 for platform access, $3,800 to own your modules outright on a perpetual platform licence, and $14,400 for a full custom build with 100% of the IP assigned to you. Hosting from $99/month, optional maintenance from $175/month, changes at $125/hour. Nothing recurring starts until launch.

The ownership question changes the price more than the feature list does, and it hinges on a single decision: is this software for you, or is it a product you intend to sell to other firms in your trade? The second is a real and often better business, but it has to be said out loud early, because it changes the licensing and the architecture.

A worked example: Vytera

Vytera came to us with exactly this situation: a set of hard-won Excel workbooks covering estimating, labour and material costing, markup and profit, and wanted them turned into a web platform for small construction and skilled-trade businesses — customer and project management, quote PDFs, and a job-costing dashboard.

We quoted all three ownership models rather than choosing for them, because the right answer depended on whether they meant to resell it. Phase one landed in the $1,900–$5,800 band depending on that choice, with the workbook review done free before any fixed price was committed.

Timeline

Six to eight weeks for the access and module-ownership tiers, sixteen to twenty for a full custom build. Development and staging hosting are free during the build.

Tell us what the business does and what it has to accomplish. We will tell you honestly if a cheaper option fits you better.