In this video, I’m going to go through EXACTLY how software outsourcing agencies estimate and price their projects.
This is information that no one ever gives out, and as far as I know apart from me having done a blog post on this about a year ago, no one is letting YOU as a client of an agency look to behind the curtain to see how much everything costs, and how much profit the agency is making out of you.
Because if you know how they’re pricing their projects, and how much profit they’re making, you’re much more likely to get a fair deal.
So let’s do it…
Contents
We’re going to split this video into three parts.
Firstly, we’re going to look at how much the actual process of software engineering costs (because from that you can work out the agency’s likely profit).
Secondly, we’re going to look at how the agency estimates the cost of your project (spoiler warning: it’s applied guesswork).
Thirdly, we’re going to look at how you can get a good specification, because with a good specification you get a good estimate, and probably get a good output for your spend – and we’re also going to look at ways in which outsourcing can go wrong for non-technology founders.
In this video, we’re not that concerned about in which country the outsourcing agency is based. This is quite a UK-centric video, and most founders end up outsourcing their work to an overseas company. When we break down the pricing, we’re looking at costs related to domestic outsourcing, costs related to outsourcing “nearshore” (which to all intents and purposes means Eastern Europe, typically centreing on Poland) and costs relating to outsourcing “offshore”, which historically has meant Asia, typically centreing on India.
In every case, the entire process of software development can be described as having a human being with certain skills sitting in front of a computer and tapping away at a keyboard producing software code. There are other human beings involved in the production process, but their role is to make ancillary contribution to the overall effort with the aim of producing output more efficiently.
The risk that we’re trying to control is to stop the developer from building the wrong thing, and by wrong thing we mean they’re taking time to build something that doesn’t actually make it into the final version of the product. You as the customer still have to pay for things that don’t actually make it into the final version of the product – so your overarching objective is to instruct the developers in such a way that they are tending to produce less waste.
For example, if as a software project manager you listen to a customer and they tell you what to build, the better you understand that determines whether the developer will produce waste along with their work or not.
Of course, ideally the project manager gets their understanding SPOT ON, but that’s why software developers get surrounded by teams of people. It’s to help reduce waste and drive efficiency.
As we look at each region – domestic, nearshore, or offshore – the actual work doesn’t from region to region, but the cost of raw materials does. The biggest “raw material” cost for an agency is the cost of labour, and what people are trying to do by outsourcing to different countries is taking advantage of that reduction in raw labour cost.
All things being equal, it should be possible to give the same project to a provider in each of the same regions and all you would see as a customer is the reduction in the total cost as you enjoy the benefits of different labour rates.
However, it doesn’t QUITE work like this because the universe likes to see balance. For whatever reason it’s harder to manage projects the further physically distant you are from the provider – almost certainly this has to do with cultural differences. But that’s the first thing it’s important to remember – the more physically distant, the harder the project is to manage, and the harder the project is to manage, the more waste will increase. Ultimately what you are trying to do is avoid producing so much waste that the project fails.
This is why nearshore outsourcing to Eastern Europe became a thing in the first place; original exercises to outsource overseas saw development being done in India where the price of labour was substantially cheaper. Nearshoring to Eastern Europe – its a middle-ground between culture not being too different (and as such the project is easier to manage), but the raw cost of labour being meaningfully cheaper.
The way that the arithmetic works from the agency is quite simple. Imagining yourself as the agency need to employ a member of staff, which means that you need to commit to paying them an amount of money per year. You also need to pay whatever taxes apply and, usually, an office for them to sit in and a computer to use. If you’re a nice employer, you also need to pay for their various learning and development bits.
Again as the agency owner, you then need to make sure that you can sell that time. You will not sell 100% of the available capacity, but in the UK at least you are budgeting to be able to sell 15-16 days per month. The amount of days you’ll be able to sell in different countries will flex as a result of culture and and/or how robust employee protection laws are locally (sadly).
Using UK numbers, you can expect to pay a senior developer about £70,000 a year, plus National Insurance and accommodation, computer, etc; to keep the numbers round, you can budget around £100,000 per year per developer in the UK.
There are 21.5 working days per month (ignoring bank or public holidays), but if we adjust to that 15 days per month utilisation, you have a cost base for a £100,000 per year developer which adjusted nets out to about £550 per day, or about £70 per hour.
The agency then needs to add profit to that, so call it 25% markup to get an hourly rate of roughly £90 per hour. This is actually a little low compared to reality, but let’s continue on that basis.
If you look at nearshoring – e.g. Poland, Croatia, etc. -- the price to the customer goes down because the labour cost is substantially cheaper. The PRICE to the end customer – looks more like £50 per hour. So that’s a 45% reduction.
If you look at offshoring – e.g. India, Thailand, etc – PRICE cost goes down further still to £20 per hour. So from the UK pricing, that’s a 78% reduction. Again, this is like-for-like so I have adjusted for exchange rates, and allowed for profit to be taken, etc. price.
This is the “design of the trap” that catches so many non-technology founders off guard, because it’s not as easy as to say that “offshoring to India is a fifth of the cost”, even though the hourly rate looks to be 1/5th of the price, because it is SUBSTANTIALLY harder to outsource software projects to Asia than it is to outsource software projects domestically. It’s hard in a high-level video to explain why that is, but there are so many factors impinging on this, so I’m going to ask you to take this on trust.
Those numbers are NOT like for like – it is not as simple as saying that nearsourcing to Poland with halve your cost and offshoring to India will… “anti-quintuple?” your spend.
Once you have the hourly rate, you’re then free to try and suss out the total project cost. In my content, and generally in the world of tech business entrepreneurialism, we have this concept of the “minimal viable product”, or “MVP”, this being the smallest piece of software that you can build to prove that you have product-market fit in whatever you are trying to take to market.
Regardless of the industry you are in or what your product does, there is a sort of a “baseline mass” of software that you need to build in order to start that journey of converging on product-market fit. You have to built enough of something to have something meaningful that people can look at.
Weirdly, regardless of the industry you’re in or what your product does, this baseline mass stays relatively static, it’s almost like a “consistent application of effort”-type of thing. You need to expend something like 100 days effort to create something that has the mass of a meaningful MVP.
In the pricing above, that gives us about £70k for domestic outsourcing, £40k for nearshoring, and £16k for offshoring.
But just to make sure you are properly “slowing your roll”, even just saying that I’m already regretting it because this is so much more messy than it looks. By way of a specifics, I have known offshoring companies in India and Pakistan take a 100-day project and estimate it at 300 days work, thus tripling their price. Or putting in additional “value adds” that bloats the price. And there’s always the old trick of getting through the original spend, not really getting anywhere, and going back to the customer to hit them up for more spend.
Also, and this is key for startups – if you are a UK business and outsource to the UK, if the agency screws it up, you can take them to court. But if you offshore to Thailand, you have virtually no chance of being able to effectively litigate on a cross-jurisdictional basis – i.e. you will never recover any money, regardless of the conduct of the agency.
What I am saying with the “100 days” is that you should learn to feel this as the “mass” of the project that you are working on, so in the next section when we look at project estimation – if those estimates come back as 50, or 200, or 500 days, you can get a sense as to whether they are lowballing you (i.e. get the contract signed and hit you up for more money later), or overegging the price (i.e. looking to see if you’re a schmuck).
The process of estimating a software project is applied guesswork.
The problem with building software is that it’s not possible to know what you want to build until you’ve built it. It’s very different to other types of construction. For example, if you want to build a house, it’s very easy to quantify it, even if the house is unique because the parameters are very constrained. Building software is like building castles in the sky using unicorn wishes and rainbows – i.e. you can build anything you can imagine.
From the software supplier’s point of you, you as the customer are standing before them with a vision of what you want built, but they know that picture in your head isn’t where you will eventually land up – because no shade on you or how clear the idea might be to you, it’s just the nature of things that the final product will evolve as it’s built, and it will diverge substantially from your original vision.
But YOU want a fixed price. So the skill on the supplier is being able to look at where you are, where you say you want to get to, and then extrapolate where you’re probably to end up, and price the project accordingly. Then they have to work out how many engineering days it’ll cost to get there, add a bit of profit, and then present you the price.
(Just to tie this back to the last section, for a version 1 MVP, that “price” will likely end up as something like 100 days effort.)
The “work out how many engineering days it’ll cost to get there”, is complete guesswork. But what’s critical to understand is that this guess maps directly to the profit that the agency will make, and before you say, “their profit is their problem”, it’s not their problem; the ability for the supplier to make profit from you project is a joint responsibility, and you don’t want to find yourself in a position where the supplier isn’t making profit when working with you.
Your relationship with your agency will be a genuine partnership. It’s not like a fake relationship like the company that turns up and vacuums your office once a week, but describes themselves as “your office cleanliness partner”. As the software is built, the understanding of how it’s built and why it’s built like that will be lodged within the personnel at the agency. The agency staff become existentially important to your business – you need to maintain contact with those staff members, and practically the only way to do that is through a consistent, long-lived partnership with the agency.
Like any proper relationship, it has to be set-up so it’s not a zero-sum game for them to be in it – i.e. it needs to be a win-win. From your side, you want to spend money and get software. From their side, they have to be able to make a profit from the work that they are doing for you.
The risk in a zero sum game, for them, is that they go and find a customer to replace you. For you, you lose access to the people who understand YOUR product better than anyone else on earth; if they have a decent order pipeline, losing you is a mere blip; but you losing them can be existentially risky
As a sidebar, the relationship you have with your agency should last about four years. In years 1-2, all the software development activity will likely be done by the agency. You then need to wean yourself off of using the agency. Year 3 will see you start to build your inhouse team, with that team taking on a third of the work, leaving the agency to do the balance. Years 4, your team should do two thirds of the work, with the agency “topping up” capacity. Years 5 onwards, you should not be using an agency.
From your perspective, their profit is linked to how good their guess is at how long your project will take. The better the guess, the more of their targeted/forecasted profit they achieve. The worse the guess, they more they have to reach into their pocket to ameliorate the problem, OR they have to come back to you for more money.
The nightmare scenario – and I’ll stress this is a nightmare for both parties – is that the original guess on the pricing is wrong because there are only two ways to resolve this. The agency can absorb the cost of the extra work, reducing their profit, and building you resentment. Or the agency can seek to hit you up for more money.
If you have a startup business, this is always a terrible outcome because startups are always operating with razor-thin cash reserves, and I have seen more often than I can count a startup just not being able to get an otherwise good product over the line because that last 1% of work that was essential to converge on product-market fit needed to be done and there just was no way to capitalise it.
Even if you’re not a startup, the agency coming back to the client to hit them up for more money also builds resentment.
The long and short of it is that you have to enable the agency to make a better guess. And that means having a better specification.
OK, so this bit is really difficult.
Most of the content I put out on my socials is about how to help non-technology founders build the product for their technology business, and the sad reality is that most founders will fail at this process when outsourcing to an agency.
You don’t get to hear about them because of survivorship bias – we see a lot of fetishisation around failure the entrepreneur community, but all of those failure stories end with “BUT THEN I MADE IT”, because if they hadn’t ultimately succeeded after their failure (or failures), they would not build audiences, and you would not be in that audience to hear them to talk about their erstwhile failures.
The sad fact is that most non-technology founders fail and go back to their previous jobs, and don’t build an audience, and thus no one heard about them.
Agencies are designed specifically to support ESTABLISHED businesses by AUGMENTING existing technical teams. They are not set-up to support early-stage or very early-stage businesses that don’t have ANY technical team. It’s by this mechanism that most non-technology founders fail.
Agencies work by receiving a large, fixed specification of the work to be done – i.e. a final design – which they will then build and deliver.
Startups and scaleups work differently to that in that you almost certainly don’t know what you are building until you have built it. Startups are working in 100% experimentation mode and the first MVP is purely the result of an intellectual exercise because until you get it into the hands of actual users, you don’t know if it lands or not. Scaleups are in a slightly better position because they’re just adding things on top of something they do know probably works, so that scale of experimentation is reduced.
In either case, the agency has to take that specification and turn it into an estimate/quotation. For them, this is a blend of art and science, but seeing as their profit is tied to how good their estimation skills are, agencies will tend to get good at estimating over time.
The actual process used is that they literally will go through the specification line by line and estimate how long each sub-feature will take to build, and then tot up the values. There’s nothing else to it that that, and the better the specification is the better the accuracy of the estimate will be, essentially because every nasty surprise that might come out of it has been worked through via the process of writing the specifiation.
But there’s a problem – it’s virtually unheard of that a non-technology person is able to synthesise a good specification for their project. This isn’t any shade, writing a specification is a specialist discipline and we all know that time we try and do any specialist discipline for the first time, the results will start off sketchy and get better with practice.
What you really need is the agency to develop the specification for you, as they will be better at writing specs. However, this is a chicken and egg problem because to write the specification, you already would have commissioned them to do the work. And in order to commission them, you need to see their quotation / proposal, and they can only do the quotation with the specification and… you can see the problem.
It’s critical that you DO NOT commission the FULL PROJECT without a proper specification. One way to do this is to do something called a “scoping exercise”, which is where you pay an agency to build the specification. This is only a few days work for a short project – if you assume 5 days and the pricing above, we have £3,500 domestic, £2k nearshore, and £800 offshore. I should warn you though, it’s almost unheard of to take a specification produced from scoping and take it to a different agency. By commissioning a scoping exercise, you are effectively choosing the agency.
Production of a specification via a scoping exercise will result in a quotation that is much more likely to be highly accurate.
(Also, a major risk here is that the specification may make sense, BUT specifications have NOTHING to do with product-market fit. You could produce a genuinely decent specification and then in a nicely risk controlled manner produce a nice piece of software to go along with it with minimal wastage, only to find that you can’t then find product-market fit and the whole effort is for nowt.)
Although I speak about this in other videos, the safest way to find an agency is to ask for a referral through your network (or by asking others on LinkedIn who have a degree of independence). As such, as a non-technology founder if you have a) a personal recommendation, and b) select a nearshore company, and c) get them to write the specification via a scoping exercise that ideally won’t more cost more than about £2,000 and will result in a final project cost of around £40,000 to £50,000, you are heading in the direction of seeing success through the project. (The caveat of maybe never finding product-market fit notwithstanding.)
This approach works because you’ve controlled plenty of the types of risk that non-technology founders face when outsourcing – you’re not completely in the dark because you have a recommendation, you’re unlikely to choose a domestic software agency because you’re on a fixed budget so you go nearshore, and you have the agency help you produce a specification.
The next thing to steer away from is being aware that you are in experimentation mode and no matter how decent the agency seems to be at this early stage, they are still working on what’s known as the “waterfall” method – which is where everything is designed up front and then worked through in an ordered, structured fashion to delivery – because despite what they may say, the commercial imperatives of how agencies work demand they ALWAYS work in an waterfall method.
What you need to do is break the project up into “tranches” where you can adjust the trajectory of the project from tranche to tranche. You also need to have an additional 20% of the budget in your back pocket to cover off any “oh it turns out this planet we were aiming at is further away and now we need to buy more fuel to get there”.
SIGNOFF