How long will it take to build my app?

Our favorite most asked question.

And we get it. We want to know that too.

But the problem with that question is that it infers that we know when something will be “complete.” It supposes we can predict the future.

If you’re building something worthwhile, you’re participating in a research and development process, which is inherently unknown. The more you try to predict further and further into the future, the less accurate you become.

Agile has become commonplace over the last 20 years after a group of software developers wrote the Agile Manifesto. The manifesto includes 4 values and 12 principles. The first three of which are particularly relevant here:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.

The question “how long until this is complete?” is evidence of Martin Fowler’s, one of the authors of the manifesto, recognition that we are slipping into an Agile Industrial Complex.

Our challenge at the moment isn't making agile a thing that people want to do, it's dealing with what I call faux-agile: agile that's just the name, but none of the practices and values in place.

The original mantra of agile was very simple. It's a set of rules for fast, iterative development. It has evolved into a lot of complex processes around providing estimates, level of efforts, point values, and complexity; which sneakily slides the process back into traditional waterfall development.

The reason why? Uncertainty is scary. People don’t like it. And when we feel afraid about something, our instinct is to reach for planning.

If we do more planning, we can reduce our anxiety around uncertainty. And it works. Projects get planned. Anxiety is lowered.

But the problem with planning, similar to predicting the future, is that outside variables change all the time. If you designed a solution for the market in February 2020, shut your door and went heads down to build the product, and then launched your product in September 2020, the needs of the market you designed for probably don’t exist anymore.

So what is the solution?

As nebulous as it may feel, going back to the basics of the agile manifesto provides a lot of principles that are still relevant today.

Build something very small as quickly as you can and then iterate

On the surface, that doesn't sound like an answer to “how long will something take?” But perhaps that’s because we’re proponents of a different question.

“What is the smallest thing I can build, test, and get feedback on?”

Then, implement that process for the duration of your business.

In doing so, you’ll create something useful for your market, because feedback is driving your product growth. It may not look like the original app you would have designed at the onset. But it will look closer to what your users want.

So how long will it take to build my app?

The life of your business.

So instead of asking how long it will take to build your app, ask yourself what is the smallest thing you can build, test, and get feedback on.

Then do that again and again and again.

Because you’re not actually building an app.

You’re building a product process that produces technology to supports your business growth.