What shipping a feature actually costs after the demo
The build is the visible cost. Error handling, monitoring, and the on-call pager are what decide whether a feature survives its first month in production.
Hammad Iqbal
Software Engineer
A feature that works in the demo and a feature that survives production are two different deliverables, and most estimates only price the first one. The gap between them is where timelines quietly slip.
- The demo proves the happy path works — it says nothing about the other four paths.
- Logging, retries, and alerting are usually built after the first incident, not before it.
- Budget a second, smaller pass a few weeks post-launch instead of pretending the feature is 'done' at merge.
The demo is the cheapest part to build
Wiring a form to an endpoint and rendering the response takes an afternoon. Making that same flow behave correctly when the network drops mid-submit, the token has expired, or the user double-clicks the button takes considerably longer — and none of it shows up in a demo.
This is why estimates that are anchored to 'get it working' consistently run short. The visible 80% of a feature is often 20% of the actual engineering effort.
Observability is a launch requirement, not a follow-up ticket
If a feature ships without a way to see it failing, the first sign of trouble is a user complaint. Structured logging around the risky steps — payment capture, external API calls, background jobs — costs very little to add while you're already in that code, and a lot to retrofit once something has quietly broken for a week.
- Log the input and outcome of anything that calls a third-party service
- Alert on error rate, not just on total downtime
- Give yourself a way to replay a failed job without redeploying
The real cost curve shows up in week three
Week one is polish and edge cases found by QA. Week three is the edge case nobody thought of — a user on a slow connection, a timezone bug, a plan tier the pricing logic didn't account for. Planning for a follow-up pass, rather than treating launch as the finish line, is what keeps that week from becoming a fire drill.
Price the feature you're actually building — the one that has to keep working after you stop watching it, not the one that looked good in the walkthrough.
Have a project this kind of thinking applies to?
Tell me what you're building — I read every message myself.