Choosing an engagement
Fractional CTO vs tech agency
A fractional CTO fits when consequential technology decisions need an owner but the role does not need a full-time appointment. A tech agency fits when the scope is clear enough to hand to an outside team and someone on your side can direct the work and judge what comes back.
The fractional CTO owns agreed decisions. The agency owns delivery of the scope in its agreement.
Some companies use both, with the fractional CTO writing or reviewing the brief, recommending acceptance, and deciding on architecture, while your product owner keeps priorities and budget.
Choose by what is missing: judgment, build capacity, or someone who can tell whether the build is right.
When a fractional CTO fits
A fractional chief technology officer (CTO) fits when the gap is judgment. Architecture, stack choices, build or buy decisions, technology investment, hiring standards, or the risks behind a roadmap commitment are waiting for an owner.
This question often appears before signing or renewing with an outside team. The proposal may look plausible, but nobody on your side can judge the architecture, scope, assumptions, or release evidence. A fractional CTO can own agreed technology decisions without a full-time appointment.
Name the limit clearly. A fractional leader does not come with an unlimited delivery team. If priorities are clear and work is waiting for builders, a leader alone will not move the queue. Delivery still needs people, scope, access, and acceptance.
You may not need a fractional CTO if a technical leader is already in place and can direct and accept outside work. In that case, the missing piece may be implementation capacity, not leadership.
When a tech agency fits
A tech agency fits when the scope is clear and stable enough to write down. The user workflow, expected behavior, systems involved, and acceptance examples are known well enough for an outside team to quote and build against.
Someone on your side still needs to direct the work and accept it. That person might be an internal engineering lead, a product owner with technical support, or a fractional CTO. Outside delivery can be strong, but an outside team cannot accept its own work on your behalf.
An agency can be the right call for a defined end state, a bounded integration, an internal tool, or a product increment that sits next to your core team. Some agencies include strong senior technical leadership, and that can be enough when the scope is clear. UCS describes its own delivery as product engineering and dedicated teams, not as an agency offer.
An agency builds what its agreement says. If the scope is wrong or keeps changing, that appears as scope change and rework unless someone owns the decisions behind the change.
This setup works best when your company can answer normal delivery questions without reopening strategy every week. What should happen for the user? Which systems are in scope? What examples prove that the behavior is accepted? If those answers keep moving, put leadership around the scope before treating delivery capacity as the main gap.
Compare the two by responsibility
Compare what each one is responsible for, not the labels.
Gap it closes
Fractional CTO: Technology decisions lack an owner.
Tech agency: A clear scope needs people to build it.
What you buy
Fractional CTO: An agreed decision remit and availability.
Tech agency: Delivery of the scope in the agreement.
Decision rights
Fractional CTO: Owns agreed technology decisions.
Tech agency: Makes implementation choices within the agreed scope.
Writes production code
Fractional CTO: Not the core remit.
Tech agency: Yes, within the scope.
Your side provides
Fractional CTO: People who carry work between reviews.
Tech agency: A written scope, a priority owner, and someone who can accept the work.
When scope changes
Fractional CTO: The remit is revisited with the founder.
Tech agency: A change is agreed under the agency’s contract.
How you judge it
Fractional CTO: Decisions made on time and followed through.
Tech agency: Accepted releases against agreed evidence.
What stays with you
Fractional CTO: A decision record and context a future leader can inherit.
Tech agency: Code, documentation, and access as the agreement sets out.
Wrong call when
Fractional CTO: Priorities are clear and work is waiting for builders.
Tech agency: Nobody on your side can define or accept the work.
Providers vary. Compare the decision rights, deliverables, and control terms written into each agreement.
When a fractional CTO oversees an agency
Oversight starts before the agency starts. The fractional CTO writes or reviews the brief: outcome, system boundaries, acceptance examples, constraints, and the decisions that still need an owner. Proposal comparison is useful only when each proposal describes the work at the same level of detail.
While the agency builds, the fractional CTO sets or approves architecture and standards, reviews technical risk, and decides on scope changes that touch architecture, security, or lasting cost. The agency decides implementation detail within the agreed scope and standards. Your product owner keeps priorities, budget, commercial commitments, and final release acceptance.
The brief should also say what is out of scope. An omitted integration, unsupported browser, deferred migration, or unapproved data source can change the real work. Naming the boundary early helps the agency estimate honestly and gives the fractional CTO a clear basis for later scope-change decisions.
At each release, accept on evidence, not only a demo. Review tests, integration behavior, known limitations, and who accepted the release. The fractional CTO can recommend acceptance against that evidence, but your company should know who has final approval.
If a release misses the evidence, separate the technical finding from the commercial decision. The fractional CTO can explain the risk and recommend whether to accept, reject, or accept with a recorded limitation. Your product owner or founder decides whether the business tradeoff is acceptable.
Keep repositories, cloud accounts, credentials, and decision records in accounts your company controls, with access granted to the agency as the work requires. Code and IP ownership are set in the contract, and qualified advice may be needed for those terms. See UCS delivery practices for how code and IP responsibility is handled. An operational role alone does not establish contractual ownership or control of repositories or cloud accounts.
Plan for agency exit from the start. The receiving team, whether in-house, a new partner, or managed support, should be able to release a change and roll it back, find why key decisions were made, run the tests, and name who handles incidents. Documentation helps, but operating readiness needs practice.
Your product owner or founder: priorities, budget, commercial commitments, and final release acceptance.
Fractional CTO: architecture, standards, technical risk, acceptance recommendation, and scope changes with technical impact.
Agency: implementation within the agreed scope and standards, estimates, and early risk escalation.
When the fractional CTO is unavailable: agree who can approve a reversible change and which choices must wait.
A decision checklist
Use these questions with the founder, product owner, and anyone who currently manages outside teams.
Is work waiting on a decision or on a build?
List what stalled recently. A decision without an owner points to leadership. A clear, accepted scope with no builders points to delivery.
Can you write the scope and acceptance examples today?
If yes, an agency can quote against it. If not, someone has to own those decisions first. Do not ask a delivery partner to solve a decision gap that your side has not named.
If the scope can’t be written because the requirements only appear inside the work, compare an FDE with a systems integrator.
Who on your side can judge the agency’s work?
Name the person who reviews architecture, reads test evidence, and accepts releases. If nobody can do that, close the judgment gap before signing or renewing. The answer may be an internal leader, technical adviser, or fractional CTO.
Who controls the code, accounts, and access?
Check repositories, cloud accounts, credentials, and IP terms before work starts, not at exit. Access should fit the work being done. Control questions are easier to settle before delivery pressure arrives.
What happens if the agency relationship ends?
Name who would take over and what they would need to operate the system. Ask for handover checks in the agreement. The receiving team should practice the work it will inherit.
Who pays your technical adviser?
Ask whether your technical adviser is paid by the firm doing the build, and how that is disclosed and managed. The answer does not automatically make the advice wrong. It tells you what review, records, and separate acceptance may be needed.
Missing judgment, scope unclear: start with a fractional CTO, then bring in delivery once the first decisions are made.
Scope clear, someone can accept the work, missing builders: hire a delivery partner.
Both missing, or an agency is already building with nobody to judge it: use a fractional CTO to direct and review the agency’s work, with final acceptance and control terms agreed from the start.
Neither missing: do not buy either.
When another engagement fits better
Forward Deployed Engineer: when the build depends on close access to your users and systems rather than a handed-over spec. Explore FDE as a service or compare a fractional CTO with an FDE if the choice is leadership versus embedded delivery.
Dedicated team: when the need is a continuing roadmap with a team that keeps product context, not one scoped project. A dedicated team can provide sustained capacity with responsibilities agreed separately.
Staff augmentation: when you own the plan and only need more people under your management. Use the guide to compare FDE with staff augmentation if the delivery responsibility is unclear.
Full-time leader: when decisions and people management need someone inside every day. Compare fractional CTO and full-time leadership before treating a fractional remit as enough.
Managed support: when a working system needs ongoing care after the build. Scope managed support separately from project delivery.
Neither: if your team can already decide and build on its own, outside help may add little. Revisit the question when the bottleneck changes.
Bring the gap
Bring the decisions that are waiting, any agency proposal or current agreement in outline, who accepts releases today, and who controls repositories and accounts. Sanitized examples are enough for the first conversation.
Do not send credentials, confidential contracts, code dumps, or customer records. Describe the boundary without sharing restricted material.
You can also email hello@ucs.tech with a short description of the gap.
Questions before we start
Can a fractional CTO oversee a development agency?
Yes, within an agreed remit. The fractional CTO can write or review the brief, set architecture and standards, review technical risk, and recommend whether a release meets the agreed evidence. Your product owner keeps priorities, budget, and final acceptance.
Do we need a fractional CTO if our agency has a technical lead?
An agency’s technical lead directs the agency’s work. You still need someone on your side who owns technology decisions for the business and can judge what the agency delivers. That can be an internal leader or a fractional CTO, and sometimes a strong product owner is enough for a small, clear scope.
Which should come first, the fractional CTO or the agency?
Start with the gap blocking work now. If the scope is unclear, a fractional CTO can make the first decisions and shape the brief before an agency quotes. If the scope is clear and someone can accept the work, an agency can start first.
Who should control the code and accounts when an agency builds our product?
Set code and IP ownership in the contract before work starts. Keep repositories, cloud accounts, and credentials in accounts your company controls, and give the agency the access the work requires.
What should be in place when an agency engagement ends?
The team taking over should be able to release a change and roll it back, run the tests, find why key decisions were made, and name who handles incidents. Plan these checks from the start and practice them before responsibilities change. Documentation alone does not demonstrate operating readiness.
Can UCS provide both fractional leadership and delivery?
Yes. Fractional X can connect to UCS delivery, with capacity, responsibilities, and commercial terms agreed separately. The leadership remit does not include an unlimited delivery team or ongoing support by default.