It's widespread knowledge that software project estimates are ridiculously inaccurate. It doesn't matter whether an estimate is for a relatively minor feature or a rather big project — it always will be much longer than expected.
But that's okay [1]. Nobody can see the future. 🔮
While we can't see the future to predict cost, later we should be able to, at least, answer the question:
HOW MUCH DID THIS FEATURE/PROJECT COST TO BUILD?
However, our observation is that in the software industry this question is even harder to answer than to give an (inaccurate but honest) estimate. This is why there is a common sentiment that early-stage SaaS companies don't and even can't know their margins and COGS.
Part of the issue is that there is a huge mess from misunderstanding the difference between estimates, effort, uncertainty and due dates. No tool can fix that.
But another part of the problem is that existing work management tools either brute force the problem via time tracking or reversed estimates — an input field on a task asking the engineer to enter time spent on that task. Everyone "loves" this field. It's also as inaccurate as the "Estimate" field.
In todo.space we are trying a different approach to reporting.
Footnote:
[1] What is not okay is when this inaccurate, naive, early estimate that everyone knows — will be wrong, is mistaken for a due date which, in its turn, is mistaken for the gravitational constant or another fundamental value of the universe that cannot be changed.