What a Fractional CTO Does: Audits, Architecture and Metrics

Organizations that go looking for a fractional CTO usually already run software in production. Typical examples are a customer portal, an integration between accounting and a payment processor, a line of business app a vendor built, or a cloud account nobody fully understands. What they don't have is one person accountable for architecture, vendor risk, reliability and delivery. This piece covers what that person does, how the first audit should run, what metrics should come out of it, and how to scope and price the engagement.

What does a fractional CTO own, and what stays with the delivery team?

A fractional CTO is a CTO working on a part time or contract basis rather than as a full time executive. Typical retainers cover 5 to 20 hours a week, and in that time the CTO defines a 12 to 24 month roadmap, the architecture, vendor choices and direction on AI and cloud.

In concrete terms, the job covers these responsibilities:

• Architecture authority. Approving or rejecting significant design changes and writing each decision down (context, options considered, consequences) so the reasoning outlives whoever made it.
• Vendor and contract risk. Data ownership, export rights, exit terms, SLA definitions and credits, who is responsible for security, and how pricing behaves at 3 to 10 times current volume.
• Reliability targets. Setting service level objectives for the systems money depends on, and making sure alerting, on call and incident review actually exist.
• Security posture. Identity and SSO, access reviews, secrets management, patch cadence, backups and restore testing.
• Roadmap and budget. Sequencing work by risk reduction and return, not by whoever is loudest.
• Team shape. When to hire, when to contract, and what each role owns.

A fractional CTO typically does not write production code, run daily standups, or handle deployments and incident response. Those belong to the development team or agency. I think that boundary is right as a default and wrong as a hard rule. When an organization has no engineering lead at all, the fractional CTO should at least run the postmortem and own the corrective actions.

Fractional CTO, part time CTO and technical program management

One useful distinction: a fractional CTO is tailored to specific tasks, while a part time CTO manages the full spectrum of CTO duties for a limited number of hours.

Technical program management is a separate discipline, and most guides blur the two. My working definition: a TPM turns an agreed plan into a dependency graph and a schedule. The TPM coordinates the teams and vendors doing the work, keeps the risk register current, and holds the release criteria. Strategy decides what gets built. Program management makes sure it ships.

How does a fractional CTO audit a codebase and infrastructure?

I'd scope the first engagement as a fixed 2 to 4 week audit, with read only access and a written deliverable. The audit runs in four passes.

1. Access and inventory

Get read only access to repositories, cloud accounts, CI, monitoring, the DNS registrar and the payment processor dashboards. The inventory is often the first finding in its own right. Look for root credentials shared over email, domains registered to a former employee's personal address, production databases reachable from the public internet, and subscriptions nobody can explain.

2. Codebase

• Reproducible builds. Can an engineer who has never seen the code build, test and deploy it from a clean machine using only the documentation?
• Test coverage where it counts. Look at coverage on payment, payout, billing and records paths, not the overall percentage.
• Dependency health. Check for unsupported runtimes, abandoned libraries and known vulnerabilities, and how long each has been open.
• Knowledge concentration. Look at commit history by author for the critical modules. One name on the payout logic is a business risk, not just a staffing detail.
• Data integrity. Check whether migrations are under version control, and whether constraints are enforced in the database or only in application code.

3. Infrastructure and operations

Check staging parity with production, backups with a tested restore, and recovery point and recovery time objectives that someone has actually written down. Check that logs, metrics and traces exist and that alerts reach a human. For the database, rank queries by total time, not mean time:

SELECT query,
       calls,
       round(total_exec_time) AS total_ms,
       round(mean_exec_time, 1) AS mean_ms
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;

A cheap query that runs on every page load often costs more than the slow monthly report everyone complains about. Then line up cloud spend by environment and service: idle resources, oversized database instances and forgotten test environments tend to show up quickly.

4. Delivery process

Trace how a change reaches production: branch, review, CI, deploy, rollback. Measure how long that takes and how often it breaks something.

The deliverable should be a risk register ranked by likelihood times impact, a keep, fix or replace call for each system, and a 90 day roadmap. The client keeps all of it, whoever does the work afterward.

Which metrics should a fractional CTO report?

A short list, reported the same way every month, beats a dashboard nobody reads.

Money paths deserve their own targets. The commission payout systems I ran on direct sales platforms at Plondo Network held 99.9% uptime, and I'd set a target like that per system rather than across the whole estate.

In my experience, latency work and cost work are often the same work, because the same waste drives both. I led a production outage investigation and the performance work after it: p90 page time fell 47%, and hosting costs dropped by $1,400 to $2,100 a month. That's why I push to report both on the same page.

Which architecture and delivery decisions need a single owner?

These are the decisions that go wrong when nobody owns them:

• Buy versus build. Build only where the capability sets you apart or where vendor pricing scales badly with your volume. Everything else should be bought and integrated.
• Monolith versus services. Most organizations with a small team should run a well structured monolith with clear module boundaries. Splitting into services adds network failure modes, distributed tracing needs and deployment coordination, and it pays off only once teams actually block each other.
• Serverless. It fits spiky load and thin operations staff. The costs are cold starts, tighter coupling to one provider, harder local testing and higher unit cost at steady high volume. I rebuilt a back office as a serverless, white label, multitenant platform in 30 days, and the speed came from accepting those trade-offs on purpose.
• Tenant isolation. Row level security in a shared schema, a schema per tenant, or a database per tenant. Each choice moves cost, blast radius and the migration burden in different directions.
• AI features. For anything that touches records or policy, require answers grounded in cited sources. I built a citation first assistant for city government that only answers from cited public records, because an answer you can't verify is a liability.

When these decisions get made ad hoc, the symptoms are predictable. One framework lists five signals: decisions feel urgent but unclear, the same fixes keep coming back, vendor dependency grows, no one owns the full picture, and costs rise without clear returns.

What does it cost, and how should you scope it?

GoFractional's national data puts the average at $217 an hour, with the middle 50% of rates between $170 and $250, which works out to $10,200 to $15,000 a month at 15 hours a week. WTT Solutions cites a wider range of $3,000 to $20,000 a month and $150 to $500 an hour.

Those guides benchmark against a full time executive: 15 hours a week comes to about $156,000 a year, roughly 62% of a $250,000 loaded full time cost. That comparison assumes you would otherwise make that hire. Most organizations in Ouachita and Lincoln Parish would not, and I know of no source that tracks fractional rates for Northeast Louisiana. Treat these as national reference points. The better comparison is the cost of one bad vendor contract, a stalled migration, or an outage during peak volume.

Nonprofits with operating budgets under $1 million should look at the TechSoup and Tech Impact Virtual CTO Program before paying anyone. Earlier stage businesses can get free consulting through the Louisiana SBDC network of 10 centers, which includes the ULM center in Monroe. In Ruston, the Ruston-Lincoln Chamber of Commerce lists the Technology Business Development Center at Louisiana Tech among its business resources. None of these replaces an accountable technical owner, but they help settle the business plan first.

A fractional engagement should also end. Once engineering is daily core work, hire, and have the fractional CTO write the role, run the technical interviews and hand over the decision log.

Where to start

1. Build a one page inventory: every system, monthly cost, admin holders, supporting vendor and where its data lives.
2. Write down the SLOs you believe your money paths meet, then check them against real monitoring data.
3. Run the query above, or its equivalent for your database, and look at the top 5 entries.
4. Commission a fixed scope audit with the risk register, per system calls and 90 day roadmap spelled out as deliverables you keep.
5. Decide on a retainer, a TPM engagement or a full time hire only after you've read the audit.

If you want to talk through an audit or an ongoing engagement, email hello@josephleporati.com.