Find me on: LinkedIn Twitter

The other day a CEO asked me, “How long will it take?”

I knew what he was thinking. So I kind of shocked him when I said, “If we started tomorrow, we could hit the market in about four months.”

Obviously, he was expecting a mobile app development timeframe much longer than that. Or maybe he was expecting the usual, ubiquitous, “Well, that depends…”

But the reason he was shocked – and the reason my answer was so different from his expectation – was that we were envisioning completely different points in the lifecycle of that product. Perhaps we were envisioning completely different lifecycles altogether.

Final vs. Evolving Software Products

In his mind, that CEO was thinking of an “end product.” A fully complete, commercial software product with all the extensions, bells, and whistles. All packaged, shrink-wrapped and pretty enough for a retail store shelf. He was wondering how many months – or years, maybe – he would need to invest in this mobile app development project before he could finally launch it and start generating some income.

I knew that’s what he meant because, traditionally, that’s how software was built.

Today, however, our strategy for building commercial software is quite different. Today we use Agile methodologies to provide more speed, flexibility, and efficiency into every project. Today, we use the concept of a Minimum Viable Product (MVP) to hit the market sooner and tailor our development to the real needs of customers.

You could say it’s a philosophical difference between building a final software product versus an evolving one.

Instead of waiting until the very end of your mobile app development to unleash a (theoretically) fully developed product on the market, the MVP strategy gets a sellable product to market as quickly as possible – and lets the market dictate how the product evolves from there.

As for what exactly constitutes the MVP, it boils down to this:

  1. It’s the first version you put into customers’ hands because you feel like there’s enough there to make a usable product
  2. You’ve been sharing your development with prospective customers every two to four weeks and they finally say, “We want THAT!”

When either of those two conditions has been met, you’re ready to ship your MVP.

Trimming Your Project Down

The evolving product strategy is a huge shift in the software development lifecycle and has several distinct advantages:

  • You get to market much earlier and can start generating income to offset your investments and/or operating expenses much sooner
  • You build and prioritize only those features the market actually wants and is willing to pay for
  • You avoid investing time and resources in features that the market doesn’t care about and isn’t willing to pay for

That last bullet alone shaves a tremendous amount of time and money from just about any mobile app development project. If a feature doesn’t add real value to your product, why waste the time to build it?

Eliminating unnecessary tasks from your timeline brings that “final version” day much closer – although by that time, it may look quite different from what you originally envisioned.

Most importantly, you’ll be presenting the features that are most valuable to customers first. This gives you a stronger and more sellable product. It also allows you to target specific segments of customers, focusing on growing your market share among those who will be most satisfied by the current product.

Estimating Your Milestones

Your most important early milestone will be launching your MVP, of course. Beyond that, when considering the time and cost of a mobile app development project, you can base it on your monthly development costs. Simply budget those monthly costs and fund the evolution of your product as long as it makes sense to do so.

Sometimes, however, your stakeholders and customers will need to know when to expect a particular feature down the road. These kinds of milestones can be found by breaking the features down into user stories and applying the methods found in our free Software Development Estimate Template to calculate a time range.

Assuming these features remain top priorities in your production sprints, you can then estimate when each milestone can be reached along the way.

Just Keep Building Until…

In Scrum-based software development, we follow short cycles of two to four week production sprints. Features are reprioritized before each sprint, so actual development should always address the highest priority items at that time.

This process could continue indefinitely. Your MVP is just the first major milestone… development shouldn’t stop or even slow down until much later.

So how do you know when to stop?

Just keep on building until the next sprint is no longer providing real value.

At some point, the costs of sustaining your mobile app development team on the project will outweigh the marginal value of the features produced. This typically occurs once your product is performing all the tasks it needs to, and the prioritization process starts packing “tweaks” and “cosmetics” into your sprints.

That’s when your software team should probably start transitioning to your next high value project. Cosmetics and performance tweaks are important, of course, but those kinds of efforts can be conducted by much smaller maintenance and update teams.

Your core software development team should be considered an invaluable strategic asset. As such, you always want them working on the highest priority, mission critical projects you face.

So Really… How Long?

How long does it really take to build a commercial software app?

We can get an MVP to market in as little as 8 weeks.

After that… well, it depends. You can provide estimates for specific features. You can allocate a “total spend” and build as much as you can until it runs out.

Or you can keep building until the marginal returns on your production sprints no longer justify the mobile app development team’s presence on that project.

If you’re building software right, you won’t know what that “final version” looks like, anyway. You’re going to listen to your customers, and let the market guide you to the best software product possible.

Share This Article