This is an AMP version of the article, its original content can be found here.
How Much For This Software?
"Here is the specification; how much will it cost to create this software?" I hear this almost every day from clients of Teamed.io and prospects that are planning to become our clients and outsource the software development to us. My best answer is "I don't know; it depends." Sounds like a strange response for someone who claims he knows what he is doing, doesn't it? "Here is the 20-page specification that explains all the features of the product; how come you can't estimate the cost?" I can, but I won't. Here is why.
Let me ask you something else: Why do you need an estimate? Yes, I mean it—why do you ask me how much it will cost to develop the software for you? I can tell you why.
Because you don't trust me.
And obviously you have good reasons for that, simply because we both know that a software product is something that can stay in development forever and never be finished. Look at YouTube, for example. How much do you think it would take to create a website like this, where users are able to upload their videos and then stream them? A few days for a good web developer. Will it stream video? Yes, it will. Will it be ready to compete with YouTube? No, it won't. Add a few hundred developers to the team, a few years, and a few million dollars, and even then you will be behind YouTube. Simply because it's a never-ending process. Any software, no matter how big or good it is, always needs more and more improvements and bug fixes.
Thus, when you ask me how much it will cost to create a system similar to YouTube, according to your specifications, my honest and accurate answer should be: "All of your money, and it won't be enough." Will you sign a contract and outsource the project to me after that answer? No, you won't. That's why I have to lie and promise something like "three months and $40,000." Why would you trust me? If you're smart enough, you won't.
My point is that no matter what I promise you, I will be wrong. Terribly wrong.
What is the solution? What do you do? I totally understand that you do need a number to make your plans and secure the money. You need to choose the right software outsourcing partner, and you need to know what to expect and when, but ...
You're asking the wrong question!
This question has only one valid answer, and it's the answer nobody will ever give you—the development will take forever and will consume all your money. All other answers are simply a lie.
I'm sorry if I've delivered bad news to you.
But let's get back to the original problem: Why are you asking me how much it will take to develop the software if you know it's a never-ending process and there is basically no limit? Because you want to make sure your $40,000 will be used the right way and will produce the maximum it can produce. To get this assurance from me, you're asking for an estimate. I'm telling you that your software will be ready for $40K, and you sleep well. Until the moment you realize you've been fooled. By your own self.
Your concern is perfectly valid. You want to spend no more than $40K, and you want to get a product that will help you achieve your business goals. For example, you want to get into the market and acquire your first few thousand users. In other words, your biggest worry is that your dollars will be turned into the right amount of the right software.
Any software team can consume your $40K, but each team will produce a different amount of software with different quality.
My point is that instead of asking how much a software project will cost, you should ask how much software we can create for each dollar you give us and what quality will it be.
Basically, don't ask us to estimate how much gas it will take to get to the finish line, because there is no finish line. Instead, ask us how much we charge per gallon and how many gallons we consume per mile.
Different teams use different metrics to measure their results (to be honest, most of them don't use any). We, at Teamed.io, use hits of code, bugs, pull requests, test coverage, and a few other metrics as measurable indicators of quantity and quality. We know exactly how much software we can produce for each $100 you pay us.
Collect those numbers from other teams and compare them. Also, make sure you can control these numbers during the course of the project. That's the guarantee you're looking for. Now you know what you're buying and how much you're paying for it. In other words, like I said above, having these numbers in front of you will assure you that your money is producing the maximum amount of software it can produce, at the highest quality.
The only question left is how you can know you're buying the right software. In other words, you know how much we charge per gallon and how many gallons we use per mile, but how do you know we're driving in the right direction and not making too many circles or detours?
There is only one mechanism to guarantee that: regular checkpoints. You should ask us whether we deliver the software in small and regular increments, and whether we allow you to conduct regular independent reviews of our progress. Also, make sure we prioritize our technical goals, use milestones, versionalize releases, publish release notes, etc. Make sure that in the course of our journey, you are able to control the progress and make corrections.
To summarize, this is wrong (because there is no "there"):
Hey driver, how much will it cost to get there?
And this is right:
Hey driver, how much do you charge per mile, and do you have a map?
Hope I've made my point clear :)