About
Estimora did not start as another tool. It started with a number none of us could defend: the margin we thought we had sold.
The problem we knew too well
We were project managers, product owners, and delivery leads. Producing an estimate was never the hard part — we could do that in a day.
The hard part came later. Somewhere around week nine, somebody would ask whether the project was still making money, and the honest answer was that nobody knew. The numbers that decided the deal lived in a file nobody had opened since it was signed.
- the estimate was treated as a sales artefact, not as a commitment
- hours were logged in Jira or ClickUp and never compared to the plan
- when an overrun surfaced, it surfaced at the invoice
- and nobody could tell a cost somebody accepted from one nobody noticed
Where it actually goes wrong
The first version of this product was an estimation workspace, and it was genuinely faster than a spreadsheet. Then we started measuring delivery against those estimates, and found the failure that changed what we were building.
Jira ships with Adjust automatically switched on, so every worklog is subtracted from the remaining estimate. A team that logs hours and never re-estimates produces a report that reads 0.00% deviation for the entire life of the project — right up to the week everything closes and the truth arrives at once.
The most confident number in the delivery tool turned out to be the least maintained one. A report built on it is not wrong occasionally. It is wrong in exactly the situation it was bought for.
What we actually needed
Not more estimation features. Something that keeps working after the deal is signed:
- a commitment that keeps its own hours, rates, cost and margin, so a rate rise never rewrites a deal closed last spring
- delivery hours measured against that commitment automatically, not collected by hand
- a second opinion that does not depend on anybody remembering to re-estimate
- an alert that fires on a change of state rather than every morning
- and a record of the decision that was taken, so it can be read back months later
Why we built Estimora
Estimating is still step one, and the workspace that does it is still here — a commitment has to come from somewhere. But it is no longer the end of the story.
The won version is frozen into a commitment. Hours arrive from Jira or ClickUp each night and attach to the plan they belong to. The outcome is computed twice: once from what the team declares is left, once from what the closed work proves. When those two disagree, that disagreement is the finding.
It is the tool we wanted on the projects where we found out too late.
What we refuse to do
A tool that watches money has to be believable on the days it says something you do not want to hear. So there are things it deliberately does not do:
- no single blended health score — two honest forecasts in tension say more than one unfalsifiable number
- no invented figures — every number names its source and how complete the data behind it is
- no rewriting of history — a commitment is a copy, and change happens by creating the next version
- no daily noise — mail goes out when severity moves, not while it drifts
The outcome we care about
We do not measure success by features. We care about whether a delivery lead can:
- say what a running project is worth without reconstructing it from memory
- find out about an overrun in week six rather than at the invoice
- defend the numbers in front of a client, with the source of each one
- and tell a cost somebody accepted from a cost nobody noticed
Better estimation was never only about speed. It is about knowing, while there is still time to act.