Photo by Pascal van de Vendel on Unsplash

If you're leading an app development project and tearing your hair out because your development timeline slipping, this article gives you some of the root causes, and solutions to get back on track. 

The reason I put this together is that I work with quite a few product directors, startup founders and CTO's who are looking to accellerate their product development.  

Let's start by looking at why your development timeline has gone awry.

Why is my development timeline slipping?

There's a thing that happens in software projects which might resonate with you. It feels like you've got so, so far, yet the finishing is taking forever. This phenomenon is called the Ninety-Ninety rule, as observed by Tom Cargill way back in 1985.

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.^[1][2]

To give an example, a few years ago, a well funded FinTech founder was exploring finding a new app developer to accellerate his development. He said this to me:

"We're tearing our hair out because the app has taken much longer than expected and there's no end it sight"

He had a 12-week plan to develop and launch your MVP or Beta version. Now it's week 30 and still going on. What happened!? The weekly meetings aren't helping; he was just hearing about more delays and find more bugs. That TestFlight build he was promised was 24 days late, and when it did arrive it had more bugs than the last one. 

Sound familiar?

Well, this is a really common problem. 

There are millions of reasons and factors that make software projects run late. But here's the top 3 that affect founders and CTO's in my experience.

1. Mismanaged communications
2. The estimate was too optimistic
3. You didn't get good planning advice

Let's talk about them one by one.

1. Fix poor communications

Question. If a project is running late, but everyone knows this in advance and understands and accepts the situation, is it still a problem?

You'll probably say "yes". But this is situation is better than being constantly in the dark and disappointed.

Humans seem to get most upset when expectations are broken. So you need to establish a relationship with an app developer where your expectations are well managed, the communications and transparent and timely, and you feel in control.

How to prevent 

When building a team, the general rule is that hiring is 90% cultural fit and 10% skill. Apply this rule when hiring an app development firm. Meet the leadership team and the people doing the work. Spend time getting to know them. Make sure the communication and work ethic is at a standard you can accept. It is far more likely that communications will be good and expectations clearly set.

Another option is to do a small trial engagement. Ask the developer if they have any offerings you'd find valuable in the £1,000-£5,000 range so you can test working together. 

How to fix 

First, if your app developer is repeatedly setting expectations and then breaking them, you need to fix the communications. To fix communications, first set the boundary. Explain that it's not acceptable. You'd rather have bad news than fake news. 

Secondly, I've found that great communications starts with rhythym. At Pocketworks, we create a weekly slot to meet up, review progress, discuss problems and plan the next steps. Some weeks there is a ton of progress, some weeks there is less to say and the meeting is literally five minutes long. That's ok, the habit is the important thing here.

The weekly meeting creates gentle pressure to keep things moving. But what if it doesn't work? Well, that probably means that your supplier can't get enough hands working on your product, or that they've hit problems and lack the skill or experience to get through. I'd suggest you respectfully ask questions about the root cuase during your weekly meeting.

If communicatinos can't be fixed and you still feel in the dark, consider changing suppliers. Changing suppliers can be incredibly painful to do, but you have to think about the long-term and the bigger picture. It's harder to get customers and future backing if you've not pulled a team together that can deliver.

2. Get better estimates from your developers

You need an estimate of time and cost so you can plan your product launch and work within your budget.

When you explain your idea, developers have to work out a plan to create the app and give you an estimate of what this will cost. Often they'll do a lot of groundwork to help figure this out, which is usually chargeable.

Even in 2026 when we have AI-driven-development accellerating development, estimates can still be way too optimistic. 

And yes, AI agents and humans still get it wrong.

The sad truth known to all industry insiders is this: estimating bespoke software projects is an impossible thing to do well. Even for seasoned experts such as IBM or agile software guru Kent Beck.

So, it's not surprising you were given a bad estimate. The good news is that there are things that can be done.

How to prevent

Looking at historical performance is your best option. Ask the app developer for real data from a similar project they did. Speak to references to validate the estimated timeline.

Ask the developer if anything significant has changed since that project was done. E.g. is it the same team? How many projects will run in tandem with yours? Is there anything that could affect the estimate?

Delays are often due to crossed streams when working. Agree to a way of working and make sure that it fits with your weekly commitments. And most importantly, ensure everyone knows their responsibilities. 

These next three tips are sound trivial, but they can make a massive difference. 

How to fix

It's too late. The best thing to do now is to up your estimating game. That means using data and observing how quickly things are getting done (e.g. one feature a week) and then forecasting how much is left. Your supplier should be able to do this. 

Put another way, let's say your a restaurant and your hire Bespoke Cakes Ltd to make 200 individually bespoke cakes. They say it will take ten weeks. On average, this means they'll need to make 20 cakes a week.  After two weeks, you observe they are making roughly ten cakes a week. What do you do? Hope for the best? Nope. The right thing to do is to use that data to forecast.  In this case, your new forecast should be 20 weeks, which is twice as long as they told you.

The main thing is you're using data rather than promises, so you'll get better estimates. Your app developer could use similar forecasting techniques to give you better estimates of when things will be done.

Poor estimates aren't the only root cause of slipping development timelines. More often than not, the plan didn't allow room for the activities that need to happen to take a digital product to successful launch. Let's look at planning next.

3. Plan for the hidden app development costs

According to the clients I speak to, app development agencies fall into two camps:

1. The ones that push back
2. The ones that roll with it to get the sale

When it comes to planning, most leaders want a company that pushes back and helps them come up with a more robust plan. This is partly so that they can sleep at night, not worrying about having to babysit a product development team. It's also partly so that they can get better outcomes (more adoption or traction, increased revenue). 

Your low-quality plan can easily double the time it takes to develop an app, platform or SaaS product. If you're a non-technical founder or director who's new to digital delivery, it's difficult to know what constitutes good advice and a good plan. 

Here's a few things you can do:

How to prevent

If you're working with an experienced team of app developers, you should be given pretty sensible planning advice. 

As a little test, have you had any of the following advice (you should have):

• "We've allowed for the hidden app development costs"
  
  There's a lot of boring stuff that goes into app development beyond features and design. I talk about this in Badly Drawn Mobile. One example is the pilot phase, which is where you test on a small cohort and then react to the feedback from real customers. This takes time and money, so you need it in your plan.    
  
  
  
  
• "We have quality assurance people that will test the app for you."
  
  
  
  You can't give a buggy app to your customers. And testing an app properly takes time. So you want to hear them talk about quality practices because it means that there is some degree of quality. If there is no QA in your plan, your app timeline is going to slip as you wrestle with quality issues throughout. The app will feel 90% done and the last 10% will take forever.
  
  
  
  
• "We test as we go, not just at the end."
  
  
  
  It's better if your developer tests as you go because it means that bugs are caught as they are created, and therefore developers can fix them whilst a feature is still fresh in their minds. This saves time. Over the course of the development, this could save a lot of time. 
  
  
  
  
• "We'll focus on one platform first, such as iPhone."
  
  
  
  It's much quicker to build and test an app on one platform first and do the second platform once the design and features have started to settle. This way, if you need to make changes, you're not doing it twice, which takes more time. Even with cross platform app that's AI vibe-coded with Flutter or React Native, you'll move faster if you focus on one platform first.
  
  
  
  
• "We think you're scope is too big."
  
  
  
  Most founders plan to build too much. They don't realise how long apps take, and app developers are often too optimistic about timeframes (us included). You want an app developer who encourages you to develop a smaller app and who pushes back. This way, you'll get something to market faster. 
  
  
  
  
• "You'll get working software every week or two."
  
  
  
  I can't emphasise the importance of this enough. Every week or so, you should have something in your hands that a customer can use. This is the only measure of real progress. Most projects are 90% done 50% of the time, meaning everything is almost done. You think you're almost there only to find out you're really nowhere near. Make sure stuff is finished from the very first week or two.

So, in a nutshell, some widely accepted good advice is: 

• Have your developer create tiny increments of your app and make sure each one is customer-ready. Avoid "everything started, nothing is done".  
• Make sure you get a drop of the app and can run it on your phone at least every two weeks.
• Try to reduce your scope down to 2-3 features max; you can always increase it later.
• Look out for quality practices. Is there a tester on the team? Will they test often?
• Don't build on iOS and Droid at the same time. Instead, stagger it or do one after the other.

How to fix

If you're not getting good advice, it may simply be that your supplier isn't quite as experienced as you'd like. The fastest solution is to bring in some outside expert help and have them work with you and your supplier to make sure the planning and execution are sound. 

For example, consider hiring a fractional delivery manager or fractional CTO.

If you're not sure how to find help, drop me a line, and I can see if there is anyone in my network (or even if it's something I can help with). 

Key takeaways

• Spend a good chunk of time getting to know your potential app developer. It's going to be a long partnership. Ditch them quickly if you are continually let down; it seldom improves over time.
• When you get an estimate, ask questions to validate it and for actual data from previous apps.
• Check for hidden app development costs (as covered in our Badly Drawn Mobile guide)
• Observe how quickly things are moving, and use that to forecast how long something will take. Don't just rely on promises. 
• Check the advice you get against the good-practices list above
• Pull in outside help if you don't like the direction you're getting