Your estimate is wrong.
A recurrent topic in my 1x1s is how to estimate correctly. Why is this such a hard question to answer? Because it is attached to another even more unpleasant question: “why is this taking so long?“
An estimate has the power to change a requirement’s scope. Once you get a number from an engineer and realize the cost is above your expectation, creativity kicks in. How this feature can be so expensive? How can we make it cheaper?
Estimates expose your internal deadline, your sensitivity to cost, and your (or your customers’) patience. It is a question that you should not rely 100% on your engineers to answer.
Time is a misleading way to get an estimate. When you ask for an estimate, the engineer’s natural impulse is to put it in the form of time: “I can have this ready in five days.” How can you trust something will take five days if the engineer has never done something similar?
You want the answer in category form: low, medium, and high effort. What’s exactly low vs. high effort? That’s something you need to agree with your team and compare with reality as you measure your team’s speed.
A newbie non-technical founder will push an engineer to a corner and ask for an estimate. Then she will question the time given in an effort to get the feature faster. The engineer will make compromises along the way, and the feature will take more time than the original estimate, with the additional grievance of being plagued with bugs.
Do you want an estimate? Know your team speed, then answer the question yourself.