Most businesses hit the same wall when they need software built. The work is too big for a single freelancer to carry responsibly, too uncertain to justify a full in-house team, and too important to ignore.
There are really three ways to staff the work, and each fits a different stage of the problem. Knowing which one you actually need saves months of wasted time and a meaningful amount of money.
Option One: Full-Time Engineers
Hiring full-time is the traditional answer, and for some companies it is the right one. The issue is that it is rarely the right first move.
A mid-level full-stack engineer in the US costs roughly $130k to $180k fully loaded once you include salary, benefits, payroll taxes, equipment, and software. A senior engineer pushes past $200k. A two-person team with any senior presence is a $350k to $500k annual commitment before you have shipped anything.
Hiring is also slow. A good engineer takes two to four months to find, another month to start, and two to three months to become productive in your codebase. You are often six months in before the first meaningful release.
Full-time hires make sense when you have a clear ongoing roadmap, predictable workload for at least eighteen months, and leadership in place to manage them. Without those, a full-time engineer will be under-used, under-supported, or both, and will eventually leave.
Option Two: Freelancers
Freelancers are the other extreme: fast to start, cheap per hour, easy to end. For a bounded, well-specified task, a good freelancer is genuinely efficient.
The trouble is most real projects are not bounded or well-specified. A freelancer is one person, with one set of skills, working alongside other clients. That creates three common failure patterns:
- The work gets done, but nothing around it does. No tests, no documentation, no deployment story, no handoff plan
- The freelancer disappears mid-project because a bigger client came along or life happened
- Scope grows beyond one person's expertise, and the freelancer keeps going instead of flagging it
You usually discover these problems three months in, when the project is half-finished and nobody else can pick it up.
Freelancers fit small, isolated pieces of work with clear acceptance criteria and a short timeline. They are a bad fit for anything that looks like building a system.
Option Three: A Fractional Dev Team
A fractional team is a small group of engineers, typically three to six people with a mix of skills, working on your project for a defined portion of their time, on an ongoing basis, with a single point of accountability.
You are renting a team, not a person. That changes the economics and the risk profile:
- Cost is a fraction of a full in-house team because you share the group with a few other clients
- Start time is days or weeks, not months
- If one person is sick or leaves, the work continues
- The team brings its own processes (code review, deployment, on-call, documentation) instead of you building those from scratch
- Skills cover frontend, backend, infrastructure, and data, rather than betting on one generalist
For most businesses building their first serious piece of custom software, this matches reality. The workload is real but not yet full-time for a team of five. The project is important enough to need structure, but not so large that it justifies a standing org chart.
Signals You Need a Team, Not a Person
The clearest way to know you have outgrown freelancers is to look at the shape of the work. You probably need a team if:
- The project touches more than one system: web app, database, third-party API, email pipeline, reporting layer
- Different parts need different skills. Someone great at frontend is usually not great at infrastructure
- The work has handoffs: design to build, build to test, test to deploy, deploy to support
- There is ongoing maintenance after launch: patches, new features, incident response, platform updates
- Downtime or silent failure would cost you real money
One signal pushes the work past what a single contractor can hold. Two or more and you are building production infrastructure, which needs the team behavior that comes with it: code review, shared on-call, written process, cross-coverage.
Red Flags That Fractional Is Wrong for You
Fractional is not the right answer for every situation. Be honest about these:
- You do not know what you want built. A team cannot define your business for you. If requirements are still shifting weekly at a fundamental level, do discovery first.
- You need someone in the room full-time. Regulated industries or roles that require constant pairing with non-technical staff sometimes need an employee.
- You are hoping to avoid managing the work entirely. A fractional team reduces management overhead but does not eliminate it. Someone on your side still has to make product decisions.
- The project is genuinely tiny. A single form, a one-page site, a two-day integration. A freelancer is faster and cheaper.
- You want to own the codebase and operate it in-house starting now. Hire. A fractional team can bridge the gap until the in-house team is ready, but the end state should be clear from day one.
The Honest Middle
The value of a fractional team is not that it is always the cheapest or the fastest. It is that it matches the shape of the work most businesses actually have: bigger than a freelancer, smaller than an in-house team, important enough to need real engineering discipline, uncertain enough that you do not want to commit to permanent headcount yet.
If you are trying to figure out whether your current project is a freelancer job, a hiring decision, or something a fractional team should handle, contact Merkra. We will look at the scope, the timeline, and the risk, and tell you which of the three options fits.