A question I regularly get asked is some variation of "How long will this take", "How much will this cost" and "How do I make this happen". I often find my answer can be difficult to follow, because it relies on several truths that are kind of stacked on top of each other, and I have to explain each of them before I can properly address the question. So this is my attempt to do that, in blog form.

Software is not Like buildings

When designing and architecting a building, the steps are (roughly): "Create the plan, build the thing, stop building it, get people using it". It's not advised to begin using the building before it's finished, and it's rare that you continue to work on it after it's complete.

Software products, and in particular new product ideas are not like that. The first usable version that's built will evolve a lot - both in terms of new features/functionality and maintenance/bugs. And it's completely normal to have people using some version of the product while new features are being added.

Knowing that, speaking about a software project as something that will eventually be complete enough for users to start using it, and for all work to stop, isn't useful.

A more useful way to think about building software is with phases - that way you can still draw a line in the sand for when you'd like to get the first people using it, whilst acknowledging that more work will likely be required. The "Prototype Phase" is when you're building the first usable version, and the "Steady state", when you're evolving and iterating the product. There's no right way to do this, but here are some ways we've seen it done.

Scenario A

Build the prototype, switch to a skeleton team, show it to users, get investment, then continue with the steady state.

This approach is often used when a working prototype is needed in order to get to the next step (get investors, hire team etc).

It's a bad idea to use a different team for the Prototype phase and the Steady State, because...

• It's generally not easy to find good people/teams, so in order for things to go well you have to get this right at least twice, and...

• There is a compatibility component if you use multiple teams/people. If the team working on the steady state had no involvement in the prototype, they may want to swap/change languages/frameworks/infrastructure. Often they will elect to rebuild the prototype from scratch in their own stack.

Scenario B

In this scenario we build the prototype and switch straight into the steady state.

If you have strong conviction that your idea will, work, and access to funding, this is the best approach to take, because...

• When there's no gap in the middle, it's easier to ensure that the same team/developer is involved for both the prototype and the steady state.

• The team/developer will generally develop a rhythym, and having ongoing dev work happening no matter what is a great forcing function to ensure the business/product side figures out what users want & what direction to be moving in.