If you have shopped for senior technology help at a $5M to $25M business, you have probably noticed the market splits cleanly into two camps. On one side, fractional CTO and CIO firms that promise executive judgment and board-room presence. On the other, development firms that promise to ship code. Each camp talks confidently about what they do well. Neither camp talks much about what happens between those two halves.
The space between them is where most of your technology failures live.
You hire the strategy firm and you get a roadmap. You hire the development firm and you get a build. What you usually do not get is the connective tissue: an executive whose decisions actually land in production, and a delivery team whose work is being directed by someone with the judgment to know whether the brief was right in the first place. Without that connective tissue, the strategy work becomes a slide deck and the development work becomes a system that solves the wrong problem on time and under budget.
Here is what each side actually does, where the gap shows up, and what it takes to close it.
What does a pure fractional firm actually do?
A traditional fractional CTO or CIO firm provides part-time executive presence. The deliverables are mostly judgment work: reviewing platform decisions, sitting in board and leadership meetings, evaluating vendors, weighing in on architecture, helping with executive hiring, building a roadmap the business can fund and execute against. The model works because experienced technology executives are expensive to hire full-time, and most growing businesses do not yet have the decision volume to justify the full hire. Buying that judgment by the month is a real value proposition.
The catch is that almost none of these firms can build anything. They are advisory practices. The roadmap they produce gets handed off to whoever the business is using for development, which is usually a separate vendor or an internal team that did not sit in the strategy conversation. The executive who built the roadmap goes back to their other clients. The roadmap goes into the queue. Six months later, someone notices that what got built does not match what was scoped, and nobody is sure where the divergence happened.
This is not a knock on the model. Pure-advisory fractional firms are useful when the business already has a competent execution layer that can run on its own. The trouble is that most growing businesses do not. The execution layer is the gap.
What does a pure development firm actually do?
A traditional development shop provides engineers, project managers, and a process for turning briefs into working software. The deliverables are mostly execution: tickets, sprints, releases, bug fixes, ongoing maintenance. The model works because building software is hard and most growing businesses do not have the volume to staff a full internal engineering team yet. Buying that capacity by the month, with a vendor that can flex up and down, is a real value proposition.
The catch is that almost none of these firms will lead. They will execute against the brief you give them. They will not push back on the brief. They will not tell you that the platform you picked is going to lock you into a five-year integration tax. They will not tell you that the feature your competitor just announced is the wrong feature for your market. They will not flag that your architecture choice is going to hit a scaling cliff in eighteen months. The reasons are structural, not malicious: their job is to ship what you asked for, their incentives are aligned to billable hours rather than business outcomes, and their senior people are the engineers, not the executives.
This is not a knock on the model either. Pure-execution development shops are useful when the business already has a competent decision-making layer that knows what to ask for. The trouble is that most growing businesses do not. The decision layer is the gap.
Where does the gap show up?
The gap is not abstract. It shows up as specific failure patterns that owners of growing businesses see again and again.
The roadmap that never lands. The strategy firm produces a thoughtful roadmap. The development team is in a different conversation entirely, working from a backlog that has drifted away from the roadmap. Quarterly reviews start with "where are we against the plan" and the answer is unclear, because the plan and the work have not been in the same room since the kickoff.
The vendor pick that does not survive contact. A platform gets selected with input from the fractional executive. The development team that has to integrate it discovers, weeks in, that the platform does not actually support the workflow that was assumed. The decision gets revisited under pressure. The strategy firm says the development team should have flagged it. The development team says they were not in the selection conversation. The business eats the cost.
The technical debt that goes unmanaged. Strategy firms tend to address technical debt at the level of strategy: do a modernization plan, set a budget, hire a vendor. Development firms tend to address it at the level of tickets: prioritize debt items in the backlog when there is room. Neither one owns the debt as a continuous portfolio. It accumulates in the seam between the two of them.
The senior engineering hire that was not made well. When the business is ready to bring engineering leadership in-house, the strategy firm helps with the search and the development firm steps back. The handoff is awkward, the new hire is starting from zero on institutional context, and the development firm's contract is ending at the same moment the new leader is trying to figure out what they inherited. The transition almost always takes longer and costs more than it should.
The feature that was built well, and built wrong. This is the single most expensive pattern. The development team executes a clean, on-time, on-budget delivery of a feature the business did not need or that solves the wrong customer problem. Nobody with the authority to redirect the work was in the room while it was being built. The feature ships. Adoption is flat. Six months later it gets quietly turned off.
Each of these failures is recoverable in isolation. A business that experiences several of them in the same year is in a worse position than a business that just hired a senior internal CTO and learned to live with the cost.
Why do the two halves not just stitch together?
The obvious question is why a business cannot just hire both: a fractional CTO firm and a development shop, and let them coordinate. Sometimes that works. Often it does not. The reasons are practical.
The two firms have different P&Ls and different incentives. The strategy firm gets paid for the retainer and the next renewal. The development firm gets paid for billable hours. When something goes wrong, each one has structural reasons to point at the other rather than absorb the cost. The business is the one holding the bag.
The two firms have different cadences. The strategy firm shows up monthly. The development firm shows up daily in standups. The friction between those cadences means decisions either get made too slowly, waiting for the strategy firm to weigh in, or too fast, with the development team making the call without executive input.
The two firms have different relationships with the internal team. The strategy firm is an advisor; their counterparts are owners and senior leaders. The development firm is a vendor; their counterparts are product managers or operations leads. Information that needs to travel between those two layers travels slowly, and sometimes not at all.
And the two firms have different definitions of done. Strategy is done when the recommendation is made. Development is done when the ticket is closed. Neither firm's definition of done is "the business outcome the work was supposed to produce." That last definition is the only one that matters, and it is the one that falls in the gap.
What does it look like when both sides are under one roof?
Pulling executive judgment and delivery capacity into one accountable relationship changes the math. The fractional executive is in the same firm as the engineers building against the roadmap. The strategy work and the execution work share a P&L. A platform decision made on Tuesday has the implementation team in the room. A scaling concern flagged by an engineer reaches the executive within days, not quarters. The handoffs that used to happen between two vendors now happen between two seats at the same table.
The model is harder to build than either pure-advisory or pure-execution. It requires a firm that has both senior executive talent and a real engineering bench, with the operational discipline to run them as one practice rather than two. Most firms do not. Of the ones that claim to, many are advisory firms with a few subcontractors, or development shops with a senior consultant fronting the work. The test is whether executive judgment and delivery work are actually under one accountable relationship, with one P&L, and whether the executive who builds your roadmap is going to be in the room when the engineers ship against it.
When that test holds up, the failure patterns above mostly disappear. The roadmap lands because the team building it is the team executing it. Vendor decisions survive contact because the integration work is being scoped by the same leadership that picked the vendor. Technical debt gets managed continuously because there is no organizational seam where it can fall through. Senior engineering hires happen with full institutional context because the firm carrying that context is still in the room. Features get built well and built right because someone with executive judgment is reviewing the brief before the engineers start.
How do you tell which kind of partner you are actually talking to?
The marketing language across all three models looks similar. Most firms talk about strategy, execution, leadership, partnership, and outcomes. The differences show up in specific questions you can ask early in a conversation.
Ask who, specifically, would be in the leadership conversations and what their full-time role is at the firm. A pure-advisory firm will name a senior executive. A pure-development firm will name an account manager or a sales engineer. A combined firm will name an executive who also has accountability for the engineering team.
Ask whether the people building the work and the people advising on the work share a P&L. Pure-advisory firms will refer you to a development partner. Pure-development firms will say their senior PM "operates strategically." A combined firm will be able to point to a single ownership structure and a single bench.
Ask what happens when the strategy and the execution disagree. A pure-advisory firm will say they will work with your developers. A pure-development firm will say they execute the brief. A combined firm will describe a process for resolving disagreement inside one organization, with one accountable person.
Ask for an example of a recent project where the firm pushed back on what the client originally asked for. Pure-development firms tend to struggle with this question. Pure-advisory firms have plenty of examples but cannot point to what got built afterward. A combined firm should be able to describe both: what changed in the brief, and what got shipped as a result.
These are not gotcha questions. They are scope questions, and the answers tell you which model you are actually buying. If your business is in the window where executive technology judgment and delivery capacity are both becoming critical, the model that lives between the two camps is the one most likely to deliver what you actually need.