Why Is This Taking So Long?

Ask a developer how long something will take. They’ll give you a number.

Double it. Add two weeks. You’re probably still optimistic.

This isn’t about incompetence or padding. It’s something more structural, and once you understand it, the question changes from “why is this taking so long” to “how do we make it easier to estimate in the first place.”

The Bicycle Problem

How long does it take to cycle from Paris to Berlin?

Think about it for a second. Maybe ten days if you’re riding seriously. Fine. Reasonable answer.

Now: it snowed in May. Your wheel buckled somewhere outside Cologne. There’s a repair shop but you don’t have the address, your maps app only works in French, and you don’t speak German. The route you planned goes through a border crossing that’s closed on Thursdays.

How long does it take now?

This is what software estimation actually looks like. Developers aren’t estimating abstract time. They’re estimating a path through a problem they haven’t fully solved yet, using tools that behave differently in combination than they do in isolation, in a codebase with history and constraints they may not fully understand, with requirements that will shift at least once before they’re done.

When a developer tells you something will take two weeks and it takes six, they weren’t lying to you. The wheel buckled. And the repair shop didn’t have the right part. And it started raining.

That said, bad estimates aren’t the main reason projects run slow. The main reasons are different, and more fixable.

Reason One: You Handed Over a Ten-Year Vision

This is the most common one. I’ve been guilty of it myself.

When a founder talks about their product, they see the final image. Where it’ll be in five years, what it’ll do for ten thousand customers, how it’ll change the industry. That’s good. You need that vision.

The problem is when that vision gets handed to a development team as a specification for version one.

A developer who hears about the ten-year vision builds for it. Not because they’re wrong, because they’re professionals who take quality seriously. They start with the architecture that can support everything. They plan for scale before you have users. They make decisions for a system that doesn’t exist yet and might never need to.

I was involved in a project where we built a microservice architecture. For non-technical founders: that means we split the whole system into small, independent pieces that each do one thing. Every senior developer who looked at it said the same thing. Technically excellent. Every standard followed.

And then the startup pivoted.

Not once. Three times.

That architecture wasn’t designed for any of the three directions the startup actually went. It wasn’t bad work, but every change took longer than it should because we were working around a complex system built for a product that no longer existed.

The founder looked at us and asked: “Why does every single thing take this long?”

Completely fair question. The answer: we built the Eiffel Tower when they needed a cabin.

There’s one question I now ask before any architectural decision: “If we need to make a major pivot next month, how much does this cost us to change?” If the answer is “a lot,” we talk about whether that complexity is actually justified right now. Sometimes it is. Most of the time, it isn’t.

Reason Two: Silence on Both Sides

Development runs slow when nobody says anything until it’s too late.

The pattern goes like this. Kickoff happens, the team gets to work, weeks pass. No bad news means things are going well. The team is heads-down, so they don’t send updates unless asked. The founder is busy with everything else, so they don’t ask.

Six weeks later, everyone sits down and realizes they’ve been building in different directions.

Going back to the bicycle: when the wheel buckled, the right moment to say something was when it buckled. Not at the end of the trip when the deadline has passed. Because the founder might know someone in Cologne. Maybe the route makes more sense to change. Maybe the whole plan needs rethinking. The information in the middle isn’t an interruption. It’s the job.

This goes in both directions. I watched a startup where the founder was having a great run on sales - bigger clients, more serious contracts. What the team didn’t know was that larger contracts meant payment terms of 60, 90, sometimes 180 days. On paper the business was doing well. The bank account was empty because the money hadn’t arrived yet.

Nobody told the team.

They kept building. They kept hiring. And then the reality arrived as a shock instead of something the whole team could have planned around together. The trust that broke in that moment took a long time to repair.

Reason Three: Decisions That Disappear

There’s a slower version of the silence problem that shows up later.

Every project accumulates decisions. Why was this built this way? Why did we choose this approach over the alternatives? Why does this piece exist at all?

When those decisions aren’t written down anywhere, they live only in the heads of the people who made them. When those people leave, the decisions leave with them. The next developer who touches that code either spends days reverse-engineering the reasoning, or works around it to be safe rather than risk breaking something they don’t understand.

Both approaches are slow. And both are avoidable.

I’ve watched teams spend a week trying to understand a decision that took twenty minutes to make, because nobody left a note. The habit that prevents this costs almost nothing: every code change references the task that caused it. Whatever project management tool you use - Jira, Linear, Trello, any of them - each task has a note: why we’re building this, what we decided not to do, what problem we’re solving.

Four sentences is enough. A new developer who joins six months later can understand the context for any decision without needing to find the people who made it.

What Actually Helps

None of this requires expensive processes or a new set of tools. Three things that make a real difference:

Brief with problems, not solutions

When you tell a developer “build feature X,” you get feature X. When you tell them “users are dropping off at this step and we’re losing 30% of sign-ups,” you might get three options: one of which is feature X, and two of which are simpler and faster. The best developers in early stage push back. They ask “do you really need all of this?” If yours never pushes back, that’s the thing to worry about. Here’s how we structure these conversations in practice.

Ask the pivot question on every architectural decision

Before committing to any significant technical approach, ask: if we need to change direction next month, how much does this cost us? You’re not building a startup for the next ten years right now. You’re building proof that it’s worth ten years of your life. Those are different sizes of problem.

Make decisions findable

Every task gets a note. Every git commit references that task. Five minutes of documentation per feature saves weeks when people change and the context needs to be rebuilt.

Once the structural problems are addressed, the next question is whether the product itself is ready to ship. Here’s the launch readiness checklist we use.