In my many years in software development I have seen a lot of very successful projects, and unfortunately quite a few that were not successful. Those ones that were not successful all had a number of factors in common and I'd like to explain those to you now, so that you don't fall into the same trap.
The truth is, those that did fail, all failed well before the first line of code was even written.
I think of developing software a little bit like building a house. Before you start building the house, and before anyone comes in to even lay the slab, there's a lot of work that needs to be done. That would include deciding what your budget is, how big should the house be, how big is the block of land, drawing up the plans, how many bedrooms do you want, how many bathrooms, how big is the garage, how big do you want your kitchen, fitting everything in, making the compromises, working out, before the first nail is hammered in, before the first drop of concrete is poured, every single detail.
In software development, there can be a tendency to have a great idea and jump into building the application before all those details are worked out. And development agencies themselves can be partly to blame for this. They might accept scope that they feel hasn't been properly understood, maybe not surveyed, no real understanding of what the market actually wants.
And if this is the case they can furiously build exactly what the client asked for. And then find that nobody actually wants to use it. On occasion, the client can even then blame the developer, even if the developer was just doing what they were contracted to do.
The responsibility goes a little bit further, though, and the answer is that the project just needs to be clear at the start.
A good clear project has a very good understanding of scope: what exactly is going to be built and why. Who are we building this for? What do those people want?
A good, thorough discovery, and then a workshop where you understand exactly what the scope is that meets those exact points, and then exposing that to as many stakeholders as possible so that decisions can be made. Is this feature important? Do we really need that? Is this actually going to make us money?
And all of this of course comes down to generating your MVP (minimum viable product).
Think of this as the smallest set of features possible that you can release to your public that will achieve some end goal (probably making you money) or achieving some level of value to your users. It definitely won't be everything, and nor should it be. Adding features, even if they are easy to do, can create confusion and a lack of focus and your users end up saying "Now how do I do that thing that I actually want to do?"
So don't make your software development a feature factory. Don't keep building despite lack of users, lack of marketing, lack of uptake. If you need to, go back beyond the start. Figure out: What is it that I want to achieve here? How do I want to get that done? What will people pay for or want to use? It's not too late to go back and get that done.
And if you have a clear idea, you will be able to build a very successful piece of software.
