# Is a Fractional CTO Right for Your Startup?

A browser-only decision aid that shows what a Fractional CTO would inspect first for common founder technical pressures.

- **Canonical URL:** https://vidhata.me/ask-the-audit
- **Author:** Vidhatanand V. (Vid)
- **Role:** Fractional CTO and AI Systems Architect

## Reliability pressure

**Starting point:** The system needs a recoverable operating model.

**Signal:** Failures, retries, state, cost, and approvals are difficult to trace or control.

**Decision at stake:** Whether to stabilise the workflow, redesign its state model, or narrow the product promise.

### What I would inspect first

1. The real execution path, including queues, checkpoints, retries, cancellation, and artefacts
2. Model calls, tool permissions, context assembly, latency, and cost by stage
3. Evaluation, failure states, human approvals, and what happens after an interruption

## Rescue pressure

**Starting point:** The first job is diagnosis, not a rewrite.

**Signal:** A demo, inherited repository, or agent-generated build cannot survive production conditions.

**Decision at stake:** What should be preserved, repaired, contained, replaced, or rebuilt.

### What I would inspect first

1. A reproducible failure and the product promise it breaks
2. Repository shape, dependencies, data flows, deployment, and hidden manual steps
3. The smallest critical path that can prove the system is recoverable

## Architecture pressure

**Starting point:** The product needs a decision boundary before more code.

**Signal:** Build, buy, model, data, and platform choices are fused together or keep changing.

**Decision at stake:** Which capabilities the product must own and which dependencies can remain replaceable.

### What I would inspect first

1. The product capability that creates durable value for the company
2. Provider contracts, data rights, switching cost, security boundaries, and budgets
3. A vertical slice that tests the hardest integration before platform investment

## Trust pressure

**Starting point:** The model needs deterministic promises around it.

**Signal:** The product is making consequential judgements without clear consent, safety, or evidence boundaries.

**Decision at stake:** Where AI may interpret, where code must enforce, and where a person must decide.

### What I would inspect first

1. The harm created by a false positive, false negative, or plausible wrong answer
2. Consent, eligibility, confidence, provenance, escalation, and fail-safe rules
3. Golden cases, negative tests, operator visibility, and human acceptance gates

## Diligence pressure

**Starting point:** A consequential claim needs an independent technical read.

**Signal:** A founder, investor, or buyer must act before every uncertainty can be removed.

**Decision at stake:** What is solid, what is assumed, what is missing, and what each gap means for the commitment.

### What I would inspect first

1. Architecture and codebase claims against the available operating evidence
2. AI and data dependencies, rights, security exposure, and concentration risk
3. Team, vendor, delivery, and repair-versus-rebuild implications

## Private AI pressure

**Starting point:** Local AI is an operating choice, not a badge.

**Signal:** Privacy, latency, cost, connectivity, or control may justify moving inference closer to the user.

**Decision at stake:** Which workloads should run locally, which should escalate, and what the machine can sustain.

### What I would inspect first

1. Workload quality, memory, throughput, latency, energy, and concurrency
2. Model tiers, capability routing, quantisation, and cloud escalation
3. Update, observability, failure, and support responsibilities after deployment

## Work with Vid

Start with the actual technical pressure: [bring the problem](https://vidhata.me/hire).