The short version
“It depends” might be software development’s favourite answer, but it shouldn’t end the conversation. Ask what’s taking the time, what could be simplified and what’s working so far. You want enough engineering to keep customers happy, without spending months solving problems you don’t have yet. Sometimes development needs more time. Sometimes it needs a smaller to-do list.
The (slightly) longer version
You've asked your developers to build a new feature. It sounds fairly straightforward, but they've come back with an estimate of three weeks. You were thinking more like three days - is it genuinely that complicated, or are your developers taking you for a ride?
Software development is notoriously difficult to estimate, even for people who've been doing it for years. Something that looks simple can turn out to be incredibly complicated, while something that looks difficult might be surprisingly easy.
There isn't a standard amount of time a feature should take, but there are ways to work out whether development is progressing sensibly. Here's what I'd look for and what I'd ask if I were concerned things were moving too slowly.
Why seemingly simple changes can take ages
One of the frustrating things about software is that how complicated something looks often has very little to do with how complicated it is to build.
Imagine asking your developers to add an option for customers to change their subscription. On the screen, it's perhaps a dropdown and a button. Behind the scenes, though, there could be changes to billing calculations, refunds, invoices and what happens to customers who've already paid.
Then there's the state of your existing software. You might have heard developers mention technical debt. Essentially, it's what happens when shortcuts or earlier technical decisions make future changes harder. Sometimes taking a shortcut is a perfectly sensible decision for a startup, but those compromises can become expensive if they accumulate.
If your developers say something is complicated, ask them to explain why. You don't need to understand the code, but you should be able to understand what's making the work difficult, what's uncertain and what other parts of the product might be affected.
It's also worth asking whether all that complexity is actually necessary. Developers can quite reasonably worry about technical problems that aren't yet important to your customers. Perhaps they're designing the system to handle a million users when you've only got ten. Ask what would happen if you took the simpler approach for now, what risks that introduces and how difficult it would be to improve things later.
How much engineering do you actually need?
Before deciding development is too slow, I'd want to understand what you're trying to achieve and who's going to use the software.
Imagine you're launching an app that helps groups of friends decide what film to watch. If the recommendations are occasionally a bit rubbish or there's a minor interface bug, it's probably not the end of the world. You can get something into people's hands, see whether they find it useful and improve it as you learn.
Now imagine you're building software that a large supermarket chain uses to organise deliveries to its stores. If that goes wrong, lorries might not get where they need to be and shelves could be left empty. Understandably, those customers will have much higher expectations around reliability and testing.
Both products need sensible security and data protection, but the amount of engineering required to make them fit for purpose is very different.
I've seen what happens when businesses get this balance wrong in both directions.
On one project, a critical part of the product was rushed through under enormous deadline pressure, with very little testing. When it started failing, customers were repeatedly experiencing serious problems with a service they depended on. Complaints mounted and large numbers of customers left. The business had saved time during development, but paid a far greater price in lost customers.
At the other extreme, I've seen a product spend months in development with beautifully structured code, extensive automated tests and sophisticated systems designed to handle thousands of users. Technically, it was excellent. The trouble was that when it launched, it had no customers. With hindsight, a simple website and a few conversations with potential customers might have been a much better place to start.
Neither team set out to make a bad decision. They'd simply ended up investing too little or too much engineering effort for what the business actually needed at that stage.
If the estimate seems too long, look at your options
If your developer estimates three weeks and you were expecting three days, I'd start by asking which parts of the work are adding the most time and complexity.
Perhaps a particular requirement is surprisingly difficult to implement. Could you simplify it? Does the feature need to handle every possible situation immediately, or could some functionality wait?
This is where you can make a real difference as a founder. You understand your customers and what the business is trying to achieve, so you can decide what's essential and what's a nice-to-have. Your developers can explain the technical trade-offs.
I'd also challenge whether the proposed level of engineering is appropriate. If you're building an MVP to test an idea, do you really need an elaborate, highly scalable system? Perhaps a much simpler approach would be good enough for now.
On the other hand, if you're building something customers will depend on for critical tasks, cutting back on testing or reliability could be a terrible decision.
There's nothing wrong with ambitious deadlines, and occasionally pushing the pace can help everyone focus. But constantly asking developers to deliver more than they think is realistic can lead to shortcuts, technical debt and a product that becomes increasingly difficult to maintain.
Rather than simply asking developers to work faster, work with them to figure out what you can simplify, what can wait and where cutting corners would create unacceptable risks.
You should be able to see progress
One warning sign I look out for is a large feature that's been under development for weeks, but nobody can show me much that's actually working.
I've seen developers, particularly less experienced ones, disappear down a rabbit hole where something is always nearly finished. There's just one more problem to fix, then another, and suddenly three weeks have passed.
Larger features can often be broken into smaller pieces that are built and tested individually. Imagine you're building a sophisticated video editing feature. Rather than waiting for the entire thing, perhaps your developers could first get basic video trimming working. You can try it internally, check it's heading in the right direction and give feedback before they build the rest.
Whether those early pieces should be released to customers depends on your goals and their expectations. For an MVP, getting something useful into people's hands quickly can be enormously valuable. For an established product with demanding customers, more testing or a limited beta might be appropriate.
Once customers are using the functionality, look at your analytics to see how they're using it. Speak to some of them too, particularly those who tried it once and stopped. Understanding what they expected and what actually happened can help you decide what to build next.
Not every improvement will be visible to customers, of course. Developers sometimes need to work on security, reliability or underlying systems. But for substantial work, you should still expect regular demonstrations or other clear evidence that progress is being made.
Could you be slowing things down yourself?
It's worth looking at how often you're changing your developers' priorities, too. Startups naturally change direction as they learn more about their customers, but switching between tasks isn't always as simple as putting one thing down and picking up another.
Developers might have already made changes based on the original requirements. A seemingly small change of direction could mean reworking something they've built, reconsidering other parts of the system or abandoning work that isn't quite finished.
Sometimes changing direction is absolutely the right decision. I'd just recommend asking what impact it will have before doing so. You can then decide whether the new idea is important enough to interrupt what's already underway.
Five questions to ask your developers
If you're concerned something is taking longer than it should, here are the questions I'd start with:
What's making this more complicated than it looks? Ask them to explain what's involved and whether all that complexity is actually necessary for your customers.
What are we still unsure about, or waiting for? Are there technical unknowns, decisions they need from you or dependencies on other people? What's the plan for resolving them?
Could we get a smaller version working sooner? Which parts are essential and which could be postponed? What would we be giving up?
Can you show me what's working so far? For larger features, ask for regular demonstrations rather than waiting until everything is finished. It's much easier to correct misunderstandings early.
What would we be compromising if we needed this sooner? Would you be removing functionality, simplifying the technical approach or taking risks that might affect customers?
A good developer should be able to help you work through these questions. They won't always have an immediate answer, particularly when dealing with something unfamiliar, but you should be able to have a productive conversation about your options.
If you're repeatedly getting vague updates, missed deadlines and no clear explanation of what's happening, that's worth investigating further.
Ultimately, you don't need to understand how to write code to make informed decisions about development. You need to understand what's taking the time, what your customers actually need and what trade-offs are available.
Sometimes you'll discover your developers are taking perfectly reasonable amounts of time. Sometimes you'll uncover problems that need addressing. And sometimes the quickest way to get moving will simply be to build less.
