I’ve seen enough mistakes in my time that I pride myself these days in being able to help my clients avoid them… People often end up spending an awful lot of money building the wrong thing and that’s stressful for everyone involved. So here’s my top 2 list from the last decade of building web-apps…
1) Confusing the App with the Product
It’s so very rare that I encounter an app that is actually a product in itself – these builds are characterized by the fact that the App is doing something that your client would normally do.
90% of the time this is not the case. Most apps do something that you (the app owner) would normally do. ie they serve out content to a user orthey process payments, or they manage interactions between two parties etc…
If you think about the implications of this it means that for most Apps you are in fact building automation for something that you could do yourself manually.
Therefore the amount of money you are about to spend on that automation needs to be compared with the ongoing cost of performing that operation manually.
So lets say you develop an app to perform negotiations between a freelancer and a client: you need to compare the cost of automating each part of that process with actually doing it yourself manually as part of your business.
Some parts of the process will be cheap to implement/expensive to do and vice versa. So each needs to be judged on its own merits.
2. Being too rigid on what features you need for launch
So you’ve got something mega exciting in your head. You’ve drawn it out on paper… You want someone to build it – somehow – within your budget…
Let’s be clear about something at this point: no matter who you are and how good your imagination is or even how much experience you have of your industry, you simply don’t know how your clients are going to react to using your new web app.
You quite simply *have* to have budget in reserve to start changing things once the product is launched.
And more to the point your initial build should be the *minimum* possible product to take to market. That way you can immediately start learning from your users’ feedback.
Then every dollar you spend is going to building things that people actually want (and will therefore pay money for).
It’s important to have a long term vision/goal for the project but it’s important to remember that that goal must be flexible to what happens in the intervening time – especially in the area of implementation details.