# Fractional CTO FAQ Straight answers about fit, scope, implementation, confidentiality, timing, evidence, and working with a Fractional CTO. - **Canonical URL:** https://vidhata.me/faq - **Author:** Vidhatanand V. (Vid) - **Role:** Fractional CTO and AI Systems Architect ## Is this the right fit? Stage, timing, and the first useful conversation ### When is a Fractional AI CTO the right move? Usually when the product has become technically consequential before a full-time CTO is the right hire. You may already have engineers or a vendor, but no one person owns architecture, AI risk, delivery truth, and the decisions the founder needs to make. I am most useful at 0 to 1 and early 1 to 10, when clear choices still change the shape of the company. ### Do I need a polished brief before we speak? No. Bring the situation as it really is: what is failing, what keeps changing, what decision feels expensive, and why the timing matters. I can help turn that ambiguity into a decision map. Please do not send credentials, private source code, personal data, or confidential attachments through this site. ### Can we start with one focused problem? Yes. A reliability audit, a technical diligence question, a rescue diagnosis, or one production-shaped prototype can be the right starting point. The scope should answer a real decision, not manufacture the appearance of progress. If the evidence says the work should stop or change direction, that is a useful result too. ## How would we work? Ownership, teams, vendors, and the first month ### Do you only advise, or do you build too? I stay implementation-close. Depending on the engagement, that can mean writing the critical path, shaping architecture, reviewing code, building a vertical slice, defining evaluation and release gates, or helping the team recover a system. Strategy is more useful when it is tested against the product, data, model behaviour, and operating reality. ### Can you work with our engineers or current vendor? Yes. I am not there to create disruption for its own sake. I make ownership and tradeoffs visible, find the decisions that are blocking delivery, and work with the people who already understand the system. If a vendor claim or handover needs independent scrutiny, I will be direct about what the evidence does and does not support. ### What would the first month look like? I would begin with the product promise, repository and system evidence, team conversations, and the decisions already in flight. From there I would establish an architecture and risk baseline, a decision register, and a practical operating rhythm. The month should end with one critical intervention shipped, stabilised, or clearly de-risked, not just a deck. ## How do you decide? Architecture, AI reliability, and build versus buy ### How do you decide what AI should own? I separate interpretation from promises. AI is useful for judgement, language, search, perception, and synthesis. Deterministic code should protect consent, permissions, hard eligibility, budgets, state transitions, and fail-safe behaviour. Human judgement stays explicit where quality, harm, or meaning cannot be reduced to a reliable automated check. ### How do you approach build versus buy? I start with the capability the product must own, the cost of dependency, and the evidence needed to change providers later. Commodity infrastructure should often be bought. Differentiating product behaviour, data contracts, evaluation, and control boundaries usually need to remain yours. The answer is an explicit tradeoff, not a default preference for more code. ### Can you rescue agent-generated or inherited code? Yes, when there is enough access to reproduce behaviour and inspect repository state, dependencies, deployment, data flows, and operating evidence. I do not begin by assuming a rewrite. First I separate what is sound from what is fragile, recover the real failure path, and then choose repair, containment, replacement, or a controlled rebuild. ### Do you work with local, private, or on-device AI? Yes. I have worked with local model serving, quantised models, Apple Silicon, capability routing, and cloud escalation paths. Local is valuable when privacy, latency, cost, control, or offline operation justifies it. I would still test the complete workload and operating burden before recommending it as an architectural commitment. ## What are the boundaries? Evidence, confidentiality, and honest commitments ### How do you handle confidentiality? I agree access and disclosure boundaries with you before sensitive material is shared. Public case studies stay anonymised and deliberately avoid private repository names, customer details, credentials, or claims that cannot be defended. Please do not send credentials, private source code, personal data, or confidential attachments through this site. What you submit to the website agent is sent to my Cloudflare-hosted AI service. I retain the protected session for up to 30 days, and contact details for up to 180 days only after you consent and submit them. ### What will you not promise? I will not invent certainty. Technical scope can commit to deliverables, tests, evidence, and decisions, but revenue, adoption, uptime, organisational change, and compliance outcomes depend on conditions no one advisor controls alone. I will tell you what is verified, what is inferred, what remains unknown, and what would change my recommendation. ## Work with Vid Start with the actual technical pressure: [bring the problem](https://vidhata.me/hire).