This is a question many founders have when considering an app. Unfortunately the price ranges from development agencies can sometimes create more confusion. One tells you it's at least $100k, and another say $10k - $15k max. What are you supposed to believe?
In the real world, estimating a software project is notoriously difficult.
To make it look easy, some agencies use online cost calculators. You check a few boxes, and it spits out a number.
Let's be honest, these tools are marketing gimmicks. They generate a lead for the agency, but they give you, the client, a dangerously misleading sense of certainty. It's a scam.
Large organizations have specialists whose job is to analyze, break down and plan out requirements. Small businesses and start-ups also need to fulfill this role somehow.
When you work with a development agency / freelancer there are 2 main pricing models:
- time and materials
- fixed price, fixed scope
The most popular model, by far, is 'time and materials'. You pay for the time spent on your project, typically daily or hourly rate. If the project takes longer than initially thought you have to pay more. And if it takes less... well, let's be honest, it never takes less. It can take more, or much more.
You're basically at risk for any and all technical tasks that take longer then expected.
This model works well if you can be confident in the initial estimates.
However, a good rule of thumb with these estimates is to ask yourself: "if this project cost twice as more as I believe now and would produce half the results I'm expecting would I still go ahead with this project?"
What this means is that you and your contractor agree on what needs to be built, then you get a price and that's now set in stone. You can't change what is being built, which is bad because you can't adapt to user feedback or new information, but the contractor can't change the price on you.
This model seems attractive because you're guaranteed to not go over budget.
But it does have a couple of pretty nasty issues:
1. You can't adapt to new information
During development you'll use the product or you'll talk to users that have tried the product and there will be inevitably some things you want to change. Well, now you can't do that. You're on a train and it won't change directions until it reaches its destination. Whether that destination makes sense for you or not.
A sophisticated developer would be open to renegotiating the scope while keeping the price the same. In this scenario you add a feature and also remove features to balance it out. This is great if you can prioritize and leave out some features. It's not so great if you don't have any features you can live without.
2. Someone draws the short straw
Either the contractor adds enough buffer in the budget to handle any errors in estimation, or they'll lose money on the project. So you either pay the contractor's insurance or you work with a really unhappy contractor that's going to try to cut the project short by any means necessary.
This doesn't become an issue if you're contractor has done many projects that are almost identical to yours.
For example, it could work if you're running a Yoga studio and you want a website built by somebody that does yoga studio websites. But it wouldn't work if you want to build an Uber for furniture movement because no agency has done 5 other Uber clones.
In my experience, the final product was never 100% captured in the initial plan, so you need some room to change course along the way.
When you run a business though you need to put a price on it so you can make a decision. You need to know if you're going to afford it, first of all, and second you also need to make a profit.
A reliable estimate isn't a price an agency gives you after a 30-minute call. A reliable estimate is the output of a dedicated planning phase.
You can be happy with your plan if you get clarity on:
- how your product works in the best of times
- how your product handles the unexpected (i.e. no internet, bad user input, unexpected errors from APIs, etc)
- what are the risky features, because you need to address them early
- why you build each feature, meaning, how each feature is related to a user or a business goal
If you have all that in place you maximize your chances for success. Some skip these out of hubris or because they don't know it's possible, but based on my experience I'd strongly advise against it. It's a small investment in planning and strategy before you commit a large amount to development.