Shipping on honest timelines — the studio's internal discipline

Every software studio has an opinion about estimation. Most of them are wrong in the same way: they either pad everything by 2x and pretend that's "honest", or they give the optimistic number and call it "confidence." Neither survives contact with a real project.

We have shipped roughly a dozen client projects and three internal products since founding in early 2026. The estimation discipline we use came from getting it wrong repeatedly, noticing the pattern, and writing it down. This is the process.

The rule: ship on the promised date, not the hoped-for one

The most expensive timeline mistake we made in the studio's first few months wasn't underestimating. It was shipping late once, then overcorrecting into padding that made proposals look unserious.

The fix was simple but hard: publish a plan, track weekly burn against the plan, and make the gap visible to the client from week one. If we are two days behind in week two, the client knows in week two. We don't wait until week six and announce a three-week delay.

This sounds obvious. It is not. The temptation to "catch up quietly" before admitting the slip is nearly universal among engineers. We kill it with a mandatory Friday update that includes a burn chart showing planned vs actual, with a one-line explanation for any gap.

The planning discipline

We do not estimate in hours. Hours are a unit of billing, not of prediction. We estimate in days, always as a range: 2-3 days, not 2.33 days. The range is the estimate. The single number is a lie that happens to be more precise.

Every feature breaks down into tasks that are 1-3 days each. If a task looks like it will take longer than 3 days, it hasn't been broken down enough. The act of breaking it down usually surfaces the unknown that was hiding inside.

The task list goes into a linear document — we use Linear, but the tool doesn't matter. What matters is that every task has an owner, a status, and a dependency chain. No task is assigned to "the team." Every task has a name next to it.

Once the task list exists, we add 20% buffer to the total for integration and unknowns, not to individual tasks. Padding every task by 20% is disingenuous — it hides the real uncertainty inside a false precision. A single buffer at the end says "we think this is the work. Here's the margin for what we missed."

The Friday update that replaced status meetings

We killed status meetings. They are the most expensive coordination mechanism in software, measured in context-switching cost per unit of information transferred.

Instead, every Friday, a written update goes to the client. It contains:

1. Burn chart. Planned workdays vs actual workdays consumed. One line.
2. Completed this week. Three to five bullet points, each with a shipped artifact (a deployed feature, a resolved bug, a delivered design).
3. Planned next week. Three to five bullet points.
4. Risks. Anything that could derail next week's plan. If there are no risks, that's the statement. We don't invent them.
5. One decision needed. Always. If there is no decision for the client to make this week, the update is missing something.

This update takes twenty minutes to write. It replaces an hour-long meeting, plus the thirty minutes of context-switching on either side. The client gets more information, not less, because the written format forces precision that conversation allows to stay fuzzy.

The conversation we have when the timeline breaks

Every timeline breaks eventually. The question is whether you tell the client before or after the ship date. Before is a conversation about scope and tradeoffs. After is a conversation about trust.

When we see a slip coming — and we can usually see it two weeks out — we present three options:

1. Ship on time with reduced scope. Cut the features that aren't essential to the launch goal.
2. Ship the full scope late. Move the date, explain why, and show the new burn projection.
3. Add capacity. Only if it actually helps. Adding people to a late project usually makes it later, but for well-partitioned workstreams it sometimes works.

The client picks. Our job is to present the options honestly, with a recommendation, and then execute whichever one they choose.

What we're still bad at

Integration surprises. Third-party APIs, legacy systems, undocumented internal workflows. These are the things that blow estimates. We're better at surfacing them early — we now explicitly list "integration unknowns" as a risk category in every plan — but we still get surprised sometimes. Honesty here means admitting we were surprised, not pretending we weren't.

Multi-stakeholder projects. When three decision-makers at a client organisation each have veto power and different priorities, the timeline is not about the code. The code is fine. The timeline is about decisions. We now flag multi-stakeholder governance as a timeline risk at project kickoff.

Feature creep from demos. Every demo generates at least three "small" change requests. We now budget one day per demo for the follow-up work. It is always used.

The takeaway

Honest timelines are not about being pessimistic or optimistic. They are about making the plan visible, tracking the gap publicly, and treating a slip as a scope conversation, not a surprise.

The studio's reputation is built one shipped-week at a time. The Friday update is the cheapest reputation insurance we have found.

Ship on the promised date. If you can't, tell them early and present the options. The options exist. The surprise is the avoidable damage.