At some point most growing companies look at what they are paying a software firm and think: for that money, I could hire someone. Sometimes that is right. More often the comparison is between the full cost of a partner and a fraction of the cost of an employee, and the decision gets made on the wrong number.
This is the full number. Then the honest cases for and against.
Salary is where the cost starts, not where it ends
A developer’s salary is the line everyone sees. Around it sit costs that do not show up on the offer letter.
Recruiting. Finding a good developer in a middle-market company outside the tech industry is slow. You are competing with companies that pay more, have engineering cultures, and can evaluate candidates technically. Expect a search to take months, and expect to pay a recruiter, or to spend a lot of your own time, to shorten it. Most companies we talk to have made at least one bad technical hire because nobody on the interview panel could tell a strong candidate from a confident one.
Benefits and overhead. Health insurance, payroll taxes, retirement match, equipment, software licenses, cloud accounts, the seat. A reasonable rule of thumb is that an employee’s fully loaded cost runs well above base salary, and for a technical role with real tooling needs it is at the high end.
Ramp. A new developer does not produce on day one. They have to learn your business, your data, your existing systems, and whatever the last person left behind. For a company with no existing engineering team and no documentation, that ramp is measured in months, and during it you are paying full price for partial output.
Management. Somebody has to decide what the developer works on, review whether the work is any good, and own the technical decisions that shape the next five years. If nobody in the company can do that, the developer manages themselves. Some are excellent at it. Most are not, through no fault of their own, because the job of setting technical direction is a different job from writing code.
The tools around the person. A working software team is more than a developer. It needs design, testing, infrastructure, security, project management, and someone who can talk to the business in plain English. One hire does one or two of those. The rest either do not happen or happen badly.
Turnover. Developers move. When the one who built your system leaves, everything they knew leaves with them unless it was written down, and it usually was not. The next hire starts from the ramp again, and often decides the previous work needs rebuilding. We see this pattern more than any other in project rescues.
The single point of failure
This is the cost that does not fit in a spreadsheet, and it is the one that matters most.
A company with one developer has a system that one person understands. If that person is sick, on vacation, or at a competitor, the system is unsupported. Not “slower to fix.” Unsupported. Any change, any outage, any question from an auditor waits until they are back, or until someone new can reverse-engineer what they did.
For a business that runs on that system, this is an operational risk on the same scale as having one person who knows how to run the plant. Owners accept it because it is invisible until the day it is not. A PE sponsor doing diligence will find it in the first hour, and it will be in the price.
The honest case for an in-house team
None of that means you should never hire. An in-house team is the right answer when:
- Software is the product, or close to it. If what you sell is software, or your operation is so software-dependent that the system changes every week, you need people who do nothing else and who are in the building.
- There is enough continuous work for a team, not a person. Three or four people can cover for each other, review each other’s work, and hold the knowledge collectively. One person cannot. If you can only justify one, you are buying the single point of failure.
- Someone can lead them. A CTO, a strong technical director, or a founder who can set direction and judge quality. Without that, hiring developers is hiring people to make decisions nobody is equipped to evaluate.
- You are willing to invest in the environment. Documentation, testing, deployment infrastructure, security. The things a good firm brings by default, and that a lone hire will not build in their spare time.
If you meet all four, build the team. We will say so on the first call. Some of our best long-term relationships are with companies that have their own engineers and use us for the projects that would otherwise sit in the queue for a year.
The honest case for a partner
A partner makes more sense when the work is a project with an end, or when it is continuous but does not need a full team, or when nobody in the company can lead technical people yet.
What you are paying for is a working team on day one: design, engineering, testing, infrastructure, project management, and the accumulated judgment of a group that has done this many times. Our team is in Texas, nothing is offshored, and the knowledge of your system lives with a firm, not with an individual who might resign. Since 2005, 96.5% of the builds we have taken on have succeeded, which is the number to compare against the odds of a first-time technical hire working out.
The fair comparison is not partner fee versus one salary. It is partner fee versus the full cost of a team large enough to not be a single point of failure, plus the leadership to run it, plus the risk of getting the hire wrong. Run that number. Sometimes the partner is still more expensive, and then you should hire.
The middle path: fractional leadership
There is a third option, and for many middle-market companies it is the right first step. A Fractional CTO or CAIO gives you the technical leadership, on a retainer or by the hour, without the full-time cost. That person can decide what to build and what to buy, evaluate a firm’s proposal, vet a technical hire, own vendor relationships, and, when the time comes, build and lead the in-house team properly.
For a company that will eventually need its own engineers, a fractional leader first and hires second is usually the cheaper and safer order. For a company that never will, it is the missing piece that makes working with any partner go better.
A way to decide
Ask three questions. Is there enough software work for three or more people, indefinitely? Is there someone here who can lead them? Can the business absorb a bad first hire and a year of ramp?
Three yeses: hire, and we will help you get started if you want. Fewer than three: a partner for the project, a fractional leader for the direction, and revisit the question in a year with a real system in place. If you want to talk through which one you are, start with a Discovery Call. Deciding whether to hire is a fair use of it, and we have told plenty of people to go hire.