Have you ever hired a contractor to build a piece of technology?

Let’s say, for example, you wanted to build a simple membership site for your new startup.

How would you know what to pay? What technology stack to use? What timeline to expect?

And when presented with a quote, could you actually tell if you were getting a fair deal?

This is, single handedly the biggest frustration for many new entrepreneurs, small business and lifestyle business owners who are trying to build software.

Since I’ve been both on the paying end, and the paid end of such contracts more times than I can count over the past two decades, I would like to give you a few tools to help you figure out a fair deal in a way that you can start using today.

We will do this by examining your minimum quality threshold, your minumum viable product, and your future requirements.

Let’s start with your quality threshold!

First off all, you need to understand that not every piece of software is created equal.

Sure, your nephew could create a membership portal in one afternoon. And if we are comparing, I could build the same bare bones functionality in about 20 minutes…

But, that wouldn’t nescessarily give you a good quality solution!

Passing functional tests and performing according to specs does not make a piece of technology good.

In this sense, software is very much like a car. Some software will last a long time. Others will break apard with “rough” usage.

Which do you need?

I start talking about the quality threshold even before specifications, because is the most important factor when it comes to what you pay.

You need to be honest with yourself and the environment the software will be used in. That is, you need to know your fault tolerance.

We call this your minumum quality threshold.

Can you expect your customers to follow users manuals, or will you need your software to gracefully handle bad customer behavior?

Will you have dozens of people using your website in a given day, or millions hitting it every hour?

And if your software fails, will it result in car accidents, missed medical treatments or delayed food delivery for staving people? Or will some customer simply have to refresh their browser…

You need to think about this before you even post a project on Elance or type up a job description on Craigslist.

Determine your minumum quality threshold and then word it in your contract so that you only pay for that minumum amount of work.

Next, comes the minimum feature set you need, which we call “minimum viable product.”

Are you just testing an idea on the app store? Are you trying to build a prototype to show off in your seed round fundraising? Or do you have paid customers lined up to use your new piece of software?

In very simple terms, what’s the minimum functionality you need implemented to achieve your business goals. That is your minimum viable product.

You need to write this down, point by point, into what we call a “work breakdown”. And you need to stricly stick to it and only pay for it’s direct implementation, nothig else.

Remember, 80% of the cost of software comes from implementing edge cases. And in our experience, a lot of software buyers end up paying for a lot of edge cases that they absolutely do not need.

In fact, reducing initial project scope to an MVP is the single biggest cost savings we offer our clients. You cannot really budge on quality and future expectations. But you can select intelligent scope that makes business sense and helps you achieve your goals with minimum risk.

Speaking of future expectations we come to your “future requirements.”

This is where choice of your technology stack selection comes into play.

Staying on the membership site theme, here are some examples of technologies you can chose from:

1) Self Hosted out of the box solution (i.e. WordPress, Drupal, etc.)
2) SaaS (software as a service) Solution (i.e. GroupAhead, Memberzone, etc.)
3) Custom PHP solution hand coded with a few membership libraries
4) Custom solution built in Rails framework with membership gems
5) Custom solution built in Django framework using an open source membership app
6) Custom solution built with Node.js & Angular
7) Custom solution built with etc…
8) etc. etc. etc.

Each one of these have their pros and cons, and depending on your situation, one will be better than the rest.

In general, the self hosted out of the box or SaaS solutions will be the cheapest to get going to test markets, but they will be very limited in terms of customization. They can get you where you wish to go, but if you are working on a software with any degree of complexity, be ready to ditch that prototype and start again six months into your business.

Custom solutions will cost more, and be more risky. They will take longer to build and to test. They will also require more project management and a comprehensive design to get the right behavior out of the software. Yet, they are a a nescessary evil. If you wish to raise any meaningful funds or build innovative software, you will need a custom solution.

What really matters in a custom solution is how much you are utilizing existing free technologies (i.e. membership gems in Rails, .NET’s MVC authentication framework, etc.) so that you are not paying a developer to implement a generic piece of code that others already have completed for public consumption.

I harp on this point, because I’ve seen several dozen authorization implementations for membership sites in practically all markets, which essentialy became very expensive throw away code. You don’t want to pay for that, when it really only takes 20 minutes to setup that functionality when you know which free technologies to use.

In the context of a custom solution, the language and framework choice is pretty much irrelevant. It all depends on your in-house expertise and ability to hire developers. There are a lot less Ruby on Rails developers than Python ones, hence they cost more to hire. There are many PHP developers, but very few good ones which are generally very employed. The specific choice will really depend on what you want to build.

What I’m trying to convey is that you need to think about your future requirements and in house expertise *BEFORE* you start your project.

You need to think hard about the tech stack question and build a real tech strategy before hiring anyone.

And whatever you do, don’t leave this selection up to the developer!

If you are not ready to pick the correct tech stack, you are not ready to start the project and a pay a developer to do any work…

If you have someone who is pitching you an idea and asking for funds, and they have not selected a tech stack and a development & operations strategy – they do not deserve your money!

But, I digress…

If you have determined your minimum quality threshold, and minimum viable product, and have clear future expectations, and you’ve picked your tech stack – now you can figure out how much you should pay.

So, how much should you pay?

A better question is, what will the return on this investment be? How much value will this software create in your business.

Fundementally speaking, as long as you are turning a profit, the software is worth it.

What’s really important is getting the project successfully completed on time, up to your quality standards and ending up with software that other coders can work on.

Sacrificing these absolute requirements to shave off a few hundred or thousand bucks from the budget is business suicide. Unfortunately, that’s the self-murder most software patrons practice with their first projects.

Assuming that you are not compramising these principles, you can use the formula below to determine the fair budget for your software project.

A = hourly freelancer rates
T = total number of hours project is expected to take
C = number of developers on project

Your Offer Budget is A*T. This is the price you negotiate.

Your “Technical Slack Fund” is A*T*C*0.3 which is a 30% extra buffer you add per developer to project unexpected expenses, inefficiencies in managing non-salary workers and itteration costs due to miscommunication.

That means, your Real Budget becomes A*T + A*T*C*0.3 (or AT(1+0.3C) for the math geeks).

You do not disclose your real budget to your contractors, but you need to make sure you have these funds if any of your development effort goes south and you need to recover investment by completing the project.

Ok, you may think that this is all fine and dandy, but still might get stuck on the fair freelancer hourly rate.

We have our in-house research where we publish quarterly freelance software developer rates on our mailing list. If you don’t want to do the research yourself, feel free to join the list and see how much things cost out in the real world.

Best and good luck in your project!

Adam