The Decision You Are Actually Making
It is a Friday afternoon. Checkout has been failing for two hours, the person who wrote that module answers on WhatsApp when he feels like it, and nobody on your payroll can log into the production server. You are not debating org charts anymore. You are discovering, in real time, who is accountable for your software and who controls it.
That is the real question behind "first technical hire, agency, or fractional CTO." Not which one is cheaper. Not which one is faster. Three things decide it:
- Ownership: who legally owns the code, the accounts, and the data when the relationship ends.
- Accountability: who is on the hook when something breaks at 2am, and what happens if they are unavailable.
- Judgment: who is qualified to say no to a bad architecture decision before it costs you a rebuild.
Most founders pick a staffing model and hope the other three sort themselves out. They rarely do.
What Each Option Actually Costs
Start with the number that anchors everything else. The U.S. Bureau of Labor Statistics reports that the median annual wage for software developers was $135,980 in May 2025, with the bottom ten percent under $82,460 and the top ten percent above $214,670. That is a national median across every employer and every seniority level, not a quote for the person you want. South Florida, a specific stack, or a senior hire will move you off that median in either direction.
Then add the part founders forget. BLS Employer Costs for Employee Compensation found that in March 2026, benefits accounted for 30.1 percent of total employer compensation costs for private industry workers, averaging $14.01 per hour worked against $32.60 in wages. That figure covers the whole private economy rather than software specifically, so treat it as a directional reminder rather than a formula: salary is not the cost. Payroll taxes, insurance, paid leave, equipment, tooling, and recruiting time are.
Agencies and fractional executives invert the math. You pay a higher effective rate for a lower total commitment and no hiring risk. The trade is that you are renting capacity, not accumulating it. Every month you pay an agency, their team gets better at your system and your team learns nothing. That is fine for a bounded build. It is a slow bleed if it becomes your permanent operating model.
Hidden Risk One: You May Not Own What You Paid For
This is the one that surprises operators, and it is the most expensive to fix late.
Under U.S. copyright law, a work created by an employee within the scope of their employment is generally a work made for hire, and the employer is the author and initial copyright owner. Work commissioned from someone who is not your employee is different. The U.S. Copyright Office explains in Circular 30, Works Made for Hire, that a specially ordered or commissioned work qualifies only if it falls within one of nine enumerated categories, the parties expressly agree in writing that it is a work made for hire, and all parties sign. Software is not one of the nine listed categories.
The practical consequence: a contract that simply calls your custom application a "work for hire" may not, on its own, move ownership from an outside developer or agency to you. The standard remedy is a separate, signed assignment of copyright, drafted so that it also operates if the work-for-hire label fails. Ask a licensed attorney to review your specific agreement, because facts and jurisdictions matter here and a blog post is not legal advice.
While you are at it, ownership of code is only half of it. Check who holds the domain registrar account, the cloud account, the repository organization, the app store listings, the payment gateway keys, and the DNS. If your agency's Google account is the root of your infrastructure, you do not own your infrastructure.
Hidden Risk Two: Your Vendor Is Now Part of Your Security Perimeter
Handing development to an outside party does not hand off the exposure. The FTC's Start with Security: A Guide for Business, distilled from the agency's data security enforcement actions, devotes an entire lesson to service providers, and the summary is blunt: put your security expectations in the contract, and then verify that they are actually being met. The guide cites cases where companies contracted work out, never checked, and consumer data ended up exposed.
Two concrete asks before you sign anything, whether the counterparty is one contractor or a fifty-person shop:
- Named security requirements in the agreement. Encryption in transit and at rest, unique credentials per person, multifactor authentication on the repository and cloud console, and no production data in development or training environments.
- A verification cadence. Quarterly access reviews, an offboarding step that revokes keys the same day, and a written path for anyone to report a vulnerability to you.
If you want shared vocabulary instead of a shouting match about "best practices," NIST's Secure Software Development Framework (SP 800-218) was designed in part so that acquirers can communicate secure development expectations to suppliers. Note that a revision, SSDF version 1.2, was released as a draft in December 2025, so check the current status before you cite a version number in a contract.
Hidden Risk Three: Nobody Owns Governance
If any part of your product touches AI, a fourth question joins the list: who decides what the system is allowed to do, and who checks whether it is doing it?
NIST's voluntary AI Risk Management Framework organizes AI risk work into four functions: govern, map, measure, and manage, with govern as the cross-cutting one. That structure exposes the staffing gap immediately. An agency can build. A developer can ship. Neither of them can own governance, because governance is a leadership function that outlives the engagement. Someone accountable inside your company has to decide what data the model sees, what the acceptable failure modes are, and who reviews outputs before customers do.
This is the strongest argument for fractional leadership on top of whoever is building. If you want that split mapped to your actual stack, our AI consulting practice and the operators in the Tech Lab Miami community spend most of their time on exactly this boundary.
The Classification Question Nobody Asks Until Later
"Fractional CTO" is a market term, not a legal category. What matters to the IRS is the substance of the relationship. The agency's guidance on independent contractor versus employee status weighs three categories of evidence: behavioral control, financial control, and the type of relationship, including written contracts, benefits, permanency, and whether the work is a key aspect of your regular business.
Read that list again and picture a "fractional" executive you set hours for, direct daily, and keep on indefinitely with no defined scope. That arrangement starts to look like something other than what the invoice says. Structure the engagement deliberately, in writing, and get an accountant to confirm it before it becomes a payroll tax conversation.
How to Choose, By Situation
Skip the generic pros and cons list. Match the model to the state you are actually in.
You have a defined build with a hard end date
An agency is usually the right call. You need burst capacity, several skill sets at once, and a delivery process you do not have to invent. Insist on a signed IP assignment, your accounts, your repository, and a documented handover before the final payment clears. Structure it so the project can end cleanly, because the projects that cannot end cleanly are the ones that never end.
Software is your product, and it changes weekly
Hire. A permanent system with permanent revenue attached needs someone whose incentives are permanent too. Accept that recruiting takes months and that your first hire's biggest contribution may be judgment rather than throughput.
You have a system running but no technical leadership
This is the most common shape and the best fit for fractional. You do not need forty hours a week of a senior executive. You need architecture decisions, vendor oversight, a security baseline, and someone who can tell you which of the three quotes on your desk is nonsense. Pair a fractional lead with either an agency or one hire, and you have covered judgment and execution at the same time.
Your real problem is manual process, not missing software
Be honest about this one before you spend six figures on a build. A lot of "we need to hire a developer" is actually a workflow problem in disguise. Mapping the process first and applying business automation to the parts that repeat is often cheaper, faster, and reversible. Only then do you know what genuinely needs to be built.
The Combination Most Operators End Up With
The three options are not mutually exclusive, and treating them as a permanent choice is the mistake. A common sequence looks like this: fractional leadership sets the architecture and the vendor standards, an agency executes the first build under that supervision, and the first full-time hire arrives to own and extend the result once there is something worth owning. The fractional lead then steps down as the internal capability steps up.
The sequence works because it separates judgment from labor. What breaks companies is buying labor and assuming judgment came free with it.
Before You Sign Anything
Whichever model you choose, put these in writing:
- A signed IP assignment covering code, designs, and documentation, reviewed by counsel and not relying on a work-for-hire label alone.
- Accounts in your company's name. Registrar, cloud, repository, analytics, payment processor. You add collaborators; you do not borrow theirs.
- Named security obligations and a stated right to verify them.
- A handover definition. What "done" means: running environment, deployment steps, credentials transferred, dependencies listed, and a person on your side who has performed a deploy successfully.
- An exit clause that survives a bad breakup, including a notice period and a data export in a usable format.
Run a thirty-day checkpoint against those five items rather than waiting for the end of the engagement. Anything unresolved at day thirty tends to be unresolvable at day two hundred.
Conclusion
Choose based on which risk you can least afford to carry. If the risk is losing control of your own product, fix ownership before you fix headcount. If the risk is shipping nothing for six months, buy execution and supervise it. If the risk is making expensive architecture decisions with no one qualified to challenge them, buy judgment first and capacity second.
The staffing model is reversible. The contract you signed, the accounts you do not control, and the code you may not own are considerably less so.
FAQs
What is a fractional CTO?
A senior technology leader engaged part-time, typically for architecture decisions, vendor and team oversight, security and governance baselines, and translating business goals into technical plans. They are usually accountable for direction rather than day-to-day delivery, which means you still need someone building.
How do I decide which option is best for my startup?
Ask which of three things you are missing: judgment, capacity, or continuity. Missing judgment points to fractional leadership. Missing capacity on a bounded project points to an agency. Missing continuity on a system that is now core to revenue points to hiring. Budget determines the pace, not the answer.
Do I automatically own software an agency builds for me?
Not necessarily. Ownership of commissioned work depends on what your contract says and how it is structured, and the "work made for hire" label has narrow statutory limits described in the Copyright Office's Circular 30. A signed assignment of rights is the usual mechanism. Have an attorney review your agreement.
How do I evaluate a developer or agency when I am not technical?
Judge process, not vocabulary. Ask how they handle code review, testing, deployments, rollbacks, access control, and vulnerability reports. Ask for a named point of accountability. Ask what happens to your system if their lead engineer leaves. Vague answers to operational questions are the signal. If you want to build enough literacy to run those conversations yourself, start with our learning resources and the sessions we run at Tech Lab Miami events.
When should I convert from an agency to an in-house hire?
When change becomes continuous rather than project-based, when your response time to production issues starts costing real revenue, or when the accumulated agency spend is approaching the fully loaded cost of a permanent employee with none of the retained knowledge. If your software is a durable operational asset rather than a one-time build, look at what a purpose-built platform plus internal ownership costs over three years, not three months.
Visuals
