Free tool · A model, not a benchmark
The schema is a week. Price the other eighteen months.
Estimate your build
Use your team’s assumptions to compare the engineering cost.
| What you end up building | Months |
|---|
Read this before you forward it
This is our judgement, not a study.
It also excludes the part that costs more than the build: running it. On-call for financial correctness, the migration when the second rail arrives, and the fact that the person who understands it can resign.
The itemised version of the same argument, including the three situations where building it yourself is the right call, is in build versus buy. If you decide to move, the safe path is in migrating off a balances column.
Questions
The fair objections.
Where do these numbers come from?
They are a model, not a benchmark. The base estimates are our own judgement of what each part takes a competent team, and every one of them is on screen so you can disagree with it. We deliberately do not present this as research, because it is not.
Is it not in your interest to make the number big?
Yes, which is why the assumptions are visible and the multipliers are named. Set the sliders to what you actually believe. If the honest answer for your situation is four months, the tool should say four months, and then buying is probably the wrong call.
Does this include running it?
No, and that is the bigger number. This estimates getting to a correct first version. It does not include the on-call, the migrations, the second currency two years later, or the engineer who owns it leaving.
What is not in the estimate at all?
Anything upstream or downstream: your chart of accounts, the money movement itself, the integrations with processors, and the reporting your finance team will ask for on top. Those are yours either way.
When should I ignore this entirely?
One currency, one product, balances that only belong to you, and no auditor in the picture. Then a table really is the right answer and no estimate changes that.
