DEV Community: Kunal Vohra

Self-Hosting an LLM vs Using an API in 2026: When Open-Weight Models Actually Save a Startup Money (Break-Even Math)

Kunal Vohra — Mon, 19 Oct 2026 12:00:00 +0000

Self-hosting an LLM is cheaper than using an API only when your traffic is high and steady. For most startups in 2026, it isn't. Two rented H100 GPUs cost about $5,560 a month whether anyone uses them or not. On my arithmetic, that only beats a mid-tier closed API above roughly 214,000 requests a month, and only beats the same open model bought per token from a host above roughly 594,000. Below those numbers, you are paying for idle GPUs.

I'm Kunal Vohra. I've been the technical co-founder six times, and I run ColadAI, a multi-LLM platform, so the question of which model runs where, and who pays for it, is one I deal with every month. My recent posts on running AirLLM on a 16GB Mac mini were about what open models can do on hardware you already own. This one is about what they cost when real users show up.

Self-hosting an LLM vs an API: the short answer

Use an API until you can prove three things: your volume is high, it is steady around the clock, and you have someone to run the GPUs. If you can't prove all three, the API is cheaper, faster to ship, and easier to change.

The comparison most founders make is wrong. They put "our own GPU" next to OpenAI or Claude prices and see a saving. The real competitor to self-hosting is not a closed model at all. It is the same open-weight model, sold per token by a hosting company, with no GPUs for you to run. Once that option is on the table, the case for running your own hardware gets much narrower.

What an API costs per request in 2026

API prices span about a hundredfold, from $0.10 to $10 per million input tokens, and hosted open models sit at the cheap end of that range. All prices below are per million tokens, input then output, as of October 2026. The closed-model prices come from my comparison of the major AI APIs; the hosted open-model prices are Together AI's serverless rates.

Closed models:

Frontier tier: GPT-6 Astra at $10 / $50, Claude Opus 5.5 at $4 / $20.
Mid tier: GPT-6.1 Sol and Claude Sonnet 5.5, both $2 / $10.
Fast tier: Gemini 3.8 Flash at $0.75 / $3.75 (rising to $1.50 / $7.50 on January 1, 2027).
Small tier: GPT-6 Luna and Claude Haiku 5.5, both $0.10 / $0.50.

Open-weight models, hosted per token:

DeepSeek V4 Pro: $1.32 / $3.96.
Llama 3.3 70B: $1.04 / $1.04.
Gemma 4 31B: $0.39 / $0.97.
gpt-oss-120B: $0.15 / $0.60.
DeepSeek V4 Flash: $0.14 / $0.28.

To compare these with a GPU, you need a cost per request. Take a retrieval-heavy chat turn: 8,000 tokens in (instructions, retrieved documents, the user's message) and 1,000 tokens out. That request costs about $0.026 on a mid-tier closed model, about $0.0094 on hosted Llama 3.3 70B, and about $0.0013 on a small closed model. Batch processing and prompt caching cut the closed prices further, often by half or more, if you design for them.

What a GPU really costs

A rented H100 costs a median of $3.81 an hour in October 2026, which is about $2,780 a month if it runs all the time. GPU prices have gone up, not down: the median H100 rose about 28 percent over the past year. Where you rent matters a lot. On-demand prices I found ran from about $4 an hour at a GPU cloud like Lambda to about $11 an hour on Google Cloud, with spot capacity as low as about $2.50.

One GPU is rarely enough. A 70B model in 8-bit precision takes about 70GB of an H100's 80GB, which leaves little room for the memory each conversation needs, and a single GPU is a single point of failure. So the realistic minimum for serving a 70B-class model to paying users is two GPUs: about $5,560 a month at the median, before anything else.

What does that buy? Published benchmarks put Llama 3.3 70B at roughly 900 to 1,850 output tokens a second per H100 on this kind of workload, depending on how fast each user's answer has to stream. I use 1,000 tokens a second per GPU in the math. At that rate, two GPUs could serve about 5.3 million of the requests above every month. Capacity isn't the problem. Utilisation is.

The break-even math, step by step

The break-even point is your fixed monthly GPU cost divided by what one request would cost on the API. Here it is with the numbers above:

Fixed cost: 2 GPUs × $3.81 an hour × 730 hours = about $5,563 a month.
Against a mid-tier closed API: $5,563 ÷ $0.026 per request = about 214,000 requests a month.
Against hosted Llama 3.3 70B: $5,563 ÷ $0.0094 per request = about 594,000 requests a month.
Against a small closed API: $5,563 ÷ $0.0013 per request = about 4.3 million requests a month, close to what two GPUs can serve at all.

The line I'd want every founder to remember: two rented GPUs cost the same $5,560 a month at zero users as at half a million requests, so self-hosting only wins once you are busy enough to keep them working. 214,000 requests a month is about 7,000 a day, every day. Plenty of AI startups get there. Very few get there in their first year, and fewer still get there with traffic that is steady at 3 a.m.

You can redo this with your own numbers in five minutes: your tokens per request, your provider's price, your GPU quote. Change the request size and the break-even moves; a short request with little context pushes it much further out, because the API bill per request drops while the GPU bill doesn't.

What the break-even math leaves out

The GPU bill is the smallest part of self-hosting at startup scale. The arithmetic above flatters it in four ways.

The engineer. Someone has to set up and tune the serving stack (vLLM or similar), handle model updates, watch memory and latency, and get paged when it falls over. That is a meaningful slice of a senior engineer's time, and at startup salaries it can exceed the GPU bill on its own.

Idle hours. Traffic has a daily shape. If your users are in one region, your GPUs sit mostly idle for a third of the day, and you pay for them anyway. APIs only charge for what you use.

Quality. A self-hosted 70B open model is not a mid-tier closed model. For some tasks it is close enough; for others it isn't, and the cheaper option only counts if it does the job. Measure cost per successful task, not cost per token.

Speed of change. New models arrive every few months. On an API, switching is a config change. On your own hardware, it is a deployment, a benchmark, and sometimes a different GPU.

The benchmark figure I used is also an optimistic ceiling: the page it came from was unclear on precision, and real workloads rarely hit benchmark throughput. If the true number is lower, the GPU line stays where it is and capacity drops, which makes the picture for self-hosting worse, not better.

When self-hosting an open-weight model is right anyway

The strongest reasons to self-host are about control, not cost. Each is real, and each has a price worth naming.

Data that can't leave your infrastructure. Healthcare, defence, some fintech and some government buyers need the model inside their walls or yours. The closed providers' zero-retention and data-residency options close part of this gap, so check them first; my startup security checklist and the DPDP Act explainer cover where the obligations actually sit.

A customer contract that requires it. Some enterprise buyers ask for a private deployment in their own cloud account. That is a strong reason, and usually a separate deployment per customer.

Fine-tuned weights you own. Fine-tune an open model and the artefact is yours; no vendor can retire it. That only matters once fine-tuning is the right call, which is later than most founders think. I covered the order of operations in RAG vs fine-tuning for startups.

Using DeepSeek's models safely. DeepSeek's own API stores data in China. Its MIT-licensed weights, run on your servers or a US host, avoid that.

Offline and on-device products. If the product has to work without a network, there is no API option. My AirLLM setup guide shows how far a 16GB Mac can be pushed, and why that is a development and demo setup rather than production serving.

Real scale. Once you are well past the break-even with steady traffic, the savings are real and compound every month. That is a good problem, and a reason to plan the move, not to make it on day one.

The middle path most startups miss: hosted open models

A hosted open-model API gives you most of the benefits of open weights without running a GPU. You pick an open model, pay per token like any API, and keep the option to move it onto your own hardware later without changing the model your product depends on.

That path solves the lock-in worry (Gemini Flash doubling its price on January 1, 2027 is the live example of why people have it), lets you test whether an open model is good enough for your task before committing to hardware, and keeps your costs at zero when nobody is using the product. Most hosts also sell dedicated endpoints, a reserved GPU billed by the hour, which is the natural next step once volume is steady.

Check the licence before you build on it. Qwen, gpt-oss, Gemma 4 and Mistral ship under Apache 2.0, and DeepSeek's recent models under MIT: you can use them commercially without strings. Llama's community licence restricts very large products (above 700 million monthly users), and some others, such as Kimi and MiniMax, restrict commercial hosting or require a separate agreement. The models that fit on a single rented GPU (Qwen at around 27B parameters, Gemma 4 31B, gpt-oss-120B) are where self-hosting is realistic for a startup. The 500B+ models need a multi-GPU node and a team to run it.

How I'd make the call for an AI startup

Here is the sequence I'd follow:

Ship on an API. A closed model or a hosted open model, behind a thin layer in your code that makes the provider swappable.
Log cost per request from day one. Tokens in, tokens out, model, outcome. My AI MVP cost guide explains the per-user arithmetic.
Test an open model on your own eval set through a hosted API. If it isn't good enough, the self-hosting question is closed.
Run the break-even with your real request size, your real traffic shape, and a GPU quote. Add the engineer.
Move to a dedicated endpoint or your own GPUs only when you are clearly past the break-even, or when data or a contract requires it.

The decision is less about GPUs than about who owns it. A non-technical founder can't easily judge a self-hosting proposal from an engineer who wants to build one, and that is the kind of call a senior technical lead should make with numbers in hand. That rarely needs a full-time CTO at $180,000 to $260,000 a year. A technical advisor retainer ($750 a month for 15+ hours, held through December 2026) can check the model and infrastructure plan; a fractional CTO ($2,500 a month for 50+ hours on the same terms) can own the AI roadmap, the vendors and the build. The fractional CTO cost guide shows market rates beside mine. If you are still at the build stage, my team and I build MVPs for AI startups, and the MVP cost calculator gives you a first range.

Frequently asked questions

Is it cheaper to self-host an LLM than to use an API? Only at high, steady volume. With two rented H100s at the October 2026 median of $3.81 an hour, self-hosting a 70B model breaks even with a mid-tier closed API at roughly 214,000 requests a month (8,000 tokens in, 1,000 out each), and with the same open model hosted per token at roughly 594,000. Below that, the API is cheaper, before you count the engineer's time.

How much does it cost to run an LLM on your own GPU? A rented H100 costs a median of $3.81 an hour, about $2,780 a month running continuously, with on-demand prices from about $4 to $11 an hour depending on the provider. A 70B-class model realistically needs two GPUs, so about $5,560 a month, plus the engineering time to run it.

What is the cheapest way to use an open-source LLM? A hosted open-model API, paid per token. gpt-oss-120B runs about $0.15 / $0.60 per million tokens and DeepSeek V4 Flash about $0.14 / $0.28 on Together AI as of October 2026, with no GPUs to rent and no cost when idle.

When should a startup self-host an open-weight model? When traffic is clearly past the break-even and steady around the clock, when data or a customer contract requires the model inside your infrastructure, or when you have fine-tuned weights to serve. Even then, a dedicated endpoint from a host is often the step before your own hardware.

Can I run a production LLM on a Mac? For development, demos and personal use, yes; small models run well on Apple Silicon. For serving paying users, no. My AirLLM tests on a 16GB Mac mini measured an 8B model at 19.6 seconds per token, which is fine for an experiment and nowhere near production.

Are open-weight models free to use commercially? Many are: Qwen, gpt-oss, Gemma 4 and Mistral use Apache 2.0, and DeepSeek's recent models use MIT. Llama's licence restricts very large products, and some others require a separate agreement for commercial hosting. Read the licence for the exact version you deploy.

If you're weighing this for your own product, book a 30-minute call. Bring your request size and rough traffic, and I'll run the break-even with you and tell you whether self-hosting is worth a conversation yet. Or get in touch if you'd rather write first.

RAG vs Fine-Tuning for Startups in 2026: Which One Your AI Product Actually Needs (and Why It's Usually Neither, Yet)

Kunal Vohra — Mon, 19 Oct 2026 12:00:00 +0000

RAG vs fine-tuning is the wrong first question for most AI startups. Retrieval-augmented generation (RAG) gives a model the right facts at the moment it answers; fine-tuning changes how the model behaves by training it on your examples. They solve different problems, and before either one, a well-written prompt with the right context pasted in solves more than founders expect. Use RAG when the model needs knowledge it doesn't have. Fine-tune when it has the knowledge but keeps answering in the wrong shape, and only once you have the data to prove it.

I'm Kunal Vohra. I've been the technical co-founder six times, and I run ColadAI, a multi-LLM platform, so I make model and architecture calls like this every week and pay the bill for the ones I get wrong. This is how I walk founders through the decision on a first call, in the order I'd make it.

RAG vs fine-tuning: the short answer

RAG changes what the model knows when it answers; fine-tuning changes how it answers. If your problem is "the model doesn't know our documents, our product catalogue, or last week's data", that is a knowledge problem and retrieval is the tool. If your problem is "the model knows enough but won't follow our format, tone, or classification rules no matter how we prompt it", that is a behaviour problem and fine-tuning is a candidate.

The line I'd put on a sticky note: a fine-tune teaches a model how to answer; retrieval tells it what to answer with. Most of the expensive mistakes I see come from using one to do the other's job. Founders fine-tune a model on their help-centre articles hoping it will "learn" them, then find it confidently invents details, because fine-tuning is poor at storing facts reliably and impossible to update without training again. Or they build an elaborate retrieval pipeline to fix what is really a formatting problem a few good examples in the prompt would have solved.

There is also a third option that sits in front of both, and it wins more often than either.

Start with prompting: prompt engineering vs RAG vs fine-tuning

Prompting comes first because it is the cheapest to try, the fastest to change, and the only one of the three that doesn't add new infrastructure. A clear system prompt, a handful of worked examples, and the relevant context placed directly in the request will get most AI MVPs to a working first version. If it doesn't, the way it fails tells you which of the other two you need.

Two things have made the prompting option much stronger over the last couple of years. Context windows are large enough that a small knowledge base (a pricing sheet, a policy document, a few dozen FAQs) can often go straight into the prompt with no retrieval at all. And most major providers now discount repeated prompt prefixes through prompt caching, so sending the same long instructions on every call costs far less than the list price suggests, as long as someone designs for it.

So the honest order is:

Prompt plus pasted context. Try it with your real data and twenty to fifty real test cases. Measure.
Add retrieval when the knowledge no longer fits, changes too often to hand-paste, or differs per customer.
Consider fine-tuning when the eval numbers show a behaviour gap that better prompts and better context can't close, and you have hundreds of good examples to train on.

Skipping straight to step three is how an MVP ends up with a training pipeline and no users. I made the same point in my AI MVP cost breakdown: prompting plus retrieval gets most v1 products where they need to be.

When to use RAG

Use retrieval when the model needs facts it was never trained on, facts that change, or facts that differ by customer. That covers most of what B2B AI products actually do: answering questions over a company's documents, support assistants grounded in a help centre, search over contracts or tickets, and anything that has to cite its source.

RAG earns its place for four reasons:

Freshness. Update a document and the next answer uses it. No retraining, no redeploy.

Citations. Because the model answers from retrieved passages, you can show the user where the answer came from. Enterprise buyers ask for this, and it is the easiest way to make hallucinations visible.

Per-customer data. Each tenant's documents stay in their own slice of the index, and the model only ever sees what the current user is allowed to see. With fine-tuning, there is no clean way to keep one customer's knowledge out of another customer's model.

Swappable models. Your knowledge lives in your index, not inside a vendor's weights. When a better or cheaper model arrives (and in this market one arrives every few months), you can switch without rebuilding your knowledge layer. I covered why that matters in my comparison of the major AI APIs.

Do you need RAG on day one? Often not. If your whole knowledge base fits comfortably in a prompt, start there and add retrieval when it stops fitting. A full pipeline with chunking strategies, rerankers and a tuned vector store is work you can defer until usage tells you where answers are going wrong.

When to fine-tune an LLM

Fine-tune when you need consistent behaviour at scale and the prompt has stopped being able to deliver it. The cases where I'd seriously consider it:

A strict output format or style the model keeps drifting from. A specific report structure, a house tone, a domain-specific way of writing that a few prompt examples don't hold across thousands of calls.

Narrow, high-volume classification or extraction. Routing tickets, tagging documents, pulling fields out of forms. If you have thousands of labelled examples and a stable label set, a small fine-tuned model can beat a large prompted one on cost and latency. My piece on decision models and fine-tuned encoders goes into that trade-off in more depth.

Moving a task to a smaller, cheaper model. Once a large model is doing a task well, its outputs (checked by humans) can become training data that teaches a smaller model to do the same narrow job for a fraction of the inference cost. This is one of the better reasons to fine-tune, and it only works once you already have a working product.

Shorter prompts at very high volume. If every request carries a long block of instructions and examples, baking that behaviour into the model can cut input tokens. Prompt caching has narrowed this advantage, so do the arithmetic before assuming it applies to you.

What fine-tuning is not for: teaching the model your documents, keeping it current, or fixing a product whose real problem is that nobody has defined what a good answer looks like. If you can't write down twenty examples of a correct answer, you don't have a training set; you have a spec problem.

RAG cost vs fine-tuning cost

RAG cost is mostly ongoing and grows with usage; fine-tuning cost is front-loaded and grows with every change. Neither is free, and the bill that surprises founders is usually the one they didn't model.

What RAG costs. An embedding step for your documents (small, and repeated only when documents change), a vector store or a vector extension on your existing database, the engineering to chunk, index and filter properly, and the extra input tokens on every request. That last line is the one that grows. Here is the napkin version with the mid-tier price from my AI API guide: 3,000 tokens of retrieved context on every request, at $2 per million input tokens, adds $0.006 a request, or about $0.12 per user per month at twenty sessions. Small per user, but it scales with every user and every session, and agents that retrieve several times per action multiply it.

What fine-tuning costs. Preparing and cleaning a training set (the real cost, and almost always underestimated), the training run itself, evaluation against the base model, and then the ongoing tax: on some providers a fine-tuned model is priced differently from its base model, it is tied to that base model's version, and when the provider retires that version you train again. Every time your product's behaviour needs to change, so does the training data.

The hidden cost on both sides is change. Products change shape fast before product-market fit. Changing a prompt takes minutes. Re-indexing documents takes hours. Rebuilding a training set and re-running a fine-tune takes days to weeks, and the old one goes stale the moment your product moves. That is the main reason I tell founders not to fine-tune before they have real usage data: you'd be paying to freeze a product that hasn't finished deciding what it is.

If you want a first number for the build itself, the MVP cost calculator has an AI-first product type and an LLM integration option, and shows a range rather than a false-precision figure.

Can you combine RAG and fine-tuning?

Yes, and mature AI products often do: a fine-tuned model for behaviour, retrieval for knowledge. A support assistant might use a model tuned to your house tone and escalation rules, fed with retrieved help-centre passages for the facts. The two don't compete; they sit at different layers.

The point is sequence, not purity. You earn the combination by shipping prompting first, adding retrieval when knowledge becomes the bottleneck, and adding fine-tuning when evals show a behaviour gap that's worth the maintenance. Teams that start with both usually spend their first quarter maintaining infrastructure instead of learning from users.

Mistakes that make AI products expensive to change

The costliest RAG and fine-tuning mistakes aren't technical; they are decisions made too early with no way to measure them. These are the ones I check for first:

No eval set. Without twenty to fifty golden cases and a script that scores them, you can't tell whether retrieval helped, whether a fine-tune beat the base model, or whether last week's prompt change broke something. Build the eval set before choosing between RAG and fine-tuning; it is the thing that makes the choice.

Retrieval with no tenant isolation. If one customer's documents can ever be retrieved into another customer's answer, you have a data breach waiting for a query. Filter on the server, not in the prompt. My startup security checklist has the AI section I start from, including treating retrieved documents as untrusted input, since a poisoned document is a prompt-injection route.

Sending sensitive data into training without checking terms. Training data leaves your hands in a way that retrieval data doesn't. Check retention and usage terms, and whether customer contracts allow it, before any customer data goes near a fine-tune.

Locking knowledge into weights. A fine-tune that "contains" your product knowledge has to be retrained every time that knowledge changes, and it ties you to one vendor's model version. Keep facts in an index you control.

Building the pipeline before the product. Rerankers, hybrid search and custom embeddings are real improvements. They are month-six improvements. In month one, they are a way to avoid talking to users.

Investors notice these. In technical due diligence, "how do you know quality didn't drop last month?" and "what happens if your provider retires that model?" are standard questions; my guide to AI startup technical due diligence lists what they look for.

Who should make the RAG vs fine-tuning call?

Someone senior who owns the model and architecture decisions, has shipped AI products before, and will still be around when the decision has consequences. For a non-technical founder, that rarely needs to be a full-time CTO at $180,000 to $260,000 a year plus equity. The call itself is made in the first weeks of a build; what matters is that someone experienced makes it with an eval set in hand.

If you have a team or a builder and want the architecture checked, a technical advisor retainer ($750 a month for 15+ hours, held through December 2026) covers reviewing the approach, the eval plan and the model choice. If you need someone to own the AI roadmap, the vendor relationships and the build, that is a fractional CTO engagement ($2,500 a month for 50+ hours on the same terms); the fractional CTO cost guide shows market rates beside mine. If you're still at the build stage, my team and I build MVPs for AI startups with the eval harness and cost logging in from the first week. And if you're weighing a dedicated AI leadership role instead, I've written about when a fractional AI officer makes sense.

Frequently asked questions

What is the difference between RAG and fine-tuning? RAG retrieves relevant documents at the moment of the request and gives them to the model as context, so it changes what the model knows when it answers. Fine-tuning trains the model on your examples, so it changes how the model behaves. RAG is the tool for knowledge; fine-tuning is the tool for format, style and narrow repeatable tasks.

Is RAG better than fine-tuning? For most startups, RAG is the better first step whenever the model needs your data: it stays current, supports citations, keeps each customer's data separate and lets you switch models. Fine-tuning is better for consistent behaviour at high volume once you have real examples to train on. Many mature products use both, at different layers.

When should a startup fine-tune an LLM? When your eval set shows a behaviour gap that better prompts and better context can't close, you have hundreds of good examples, and the task is stable enough that the training set won't be stale next month. Moving a proven task from a large model to a smaller, cheaper one is one of the strongest reasons.

Can fine-tuning teach a model my company's documents? Not reliably. Fine-tuning is poor at storing facts precisely, can't be updated without retraining, and gives you no citation trail. Put your documents in a retrieval index and let the model read them when it answers.

How much does RAG add to inference cost? Mostly the extra input tokens on each request. At $2 per million input tokens, 3,000 tokens of retrieved context adds $0.006 a request, or about $0.12 per user per month at twenty sessions. Agents that retrieve several times per action multiply that; prompt caching and tighter retrieval pull it down.

Do I need RAG for my MVP? Only if your knowledge base doesn't fit comfortably in the prompt, changes often, or differs per customer. Many AI MVPs start with context pasted straight into the prompt and add retrieval once real usage shows where it is needed.

If you're making this call for your own product, book a 30-minute call. Bring your use case and a few examples of a good answer, and I'll tell you whether you need prompting, retrieval, fine-tuning, or some order of the three. Or get in touch if you'd rather write first.

Gemini vs Claude vs Grok vs ChatGPT (and DeepSeek) APIs for Business: A Step-by-Step Setup Guide for 2026

Kunal Vohra — Fri, 09 Oct 2026 12:00:00 +0000

Gemini vs Claude vs Grok vs ChatGPT for business comes down to three questions, not one benchmark: what each model costs per task at your volume, what happens to your data after the request, and how easily you can switch when the leaderboard changes next quarter. For most businesses the right setup is direct API access from each provider's developer console (Google AI Studio, the Claude Console, the xAI console, the OpenAI Platform, and optionally DeepSeek), a paid organisation account with spend limits, scoped keys in a secrets manager, data retention confirmed in writing, and a thin layer in your own code that lets you route each task to whichever model does it best.

I run ColadAI, a multi-LLM platform, and as a fractional CTO for AI-first startups I set this up for founders who are about to wire AI into a real product. This guide is the version I would walk you through on a call: the honest comparison first, then the step-by-step setup for each provider, with working code. Prices and model names below are from each provider's own documentation as of October 2026; they change often, so check the linked pages before you commit a budget.

Why use the API directly instead of ChatGPT, Gemini or Claude apps?

Use the API directly when AI is going into your product, your workflows, or your customers' data. The consumer and team chat apps are built for people typing; the APIs are built for software. The difference matters for a business in four ways.

You pay per use, not per seat. API billing is per token (roughly, per word processed). A workflow that runs ten thousand times a month costs what it costs, with no per-user licences.

Your data terms are different. All four US providers state that paid API traffic is not used to train their models by default, and each offers shorter or zero retention for eligible customers. The free tiers are a different story, which I cover below.

You choose the model per task. The apps pick for you. The API lets you send a simple classification to a model that costs $0.10 per million input tokens and a hard contract review to one that costs fifty times more.

You can switch providers. If your code talks to an API through your own layer, moving from one provider to another is a configuration change, not a rewrite.

One naming note: "ChatGPT" is OpenAI's chat app. The business API behind it is the OpenAI API, managed from the OpenAI Platform. When founders say "ChatGPT API", that is what they mean.

Gemini vs Claude vs Grok vs ChatGPT vs DeepSeek: the comparison that matters for business

Here is how the five compare on the things a business actually decides on: price tiers, data handling, and where each fits. All prices are USD per million tokens, input then output, at standard rates.

OpenAI (the ChatGPT API). Three current flagship models: GPT-6 Astra ($10 / $50) for the hardest work, GPT-6.1 Sol ($2 / $10) as the balanced default, and GPT-6 Luna ($0.10 / $0.50) for high-volume tasks. All three list a 1.05M-token context window and built-in tools (web search, file search, computer use). The Batch API runs at half price. API data is not used for training unless you opt in; abuse-monitoring logs are kept for up to 30 days, with zero or modified retention for approved customers. OpenAI has the broadest published data-residency list of the five (US, Europe and the UAE for storage and processing; several more regions, including India and the UK, for storage only), mostly subject to approval.

Anthropic (Claude). Claude Opus 5.5 ($4 / $20) for complex reasoning and agents, Claude Sonnet 5.5 ($2 / $10) as the workhorse, and Claude Haiku 5.5 ($0.10 / $0.50 for prompts up to 100k tokens) for speed and volume. There is also a premium tier (Claude Fable 5.1, $10 / $50). Batch is half price, and cached prompt reads on Opus 5.5 and Sonnet 5.5 cost 5 percent of the normal input price, which matters if you send the same long instructions or documents repeatedly. Anthropic states that retained data is never used for training without your permission, and that conversation content is not retained by default (some premium models require 30-day retention). Zero data retention is available through sales, and a data-residency option exists on the Messages API. Claude is also sold through AWS Bedrock and Google Vertex AI, which helps if your cloud contract already lives there.

Google (Gemini). Gemini 3.1 Pro (in preview, $2 / $12 up to 200k tokens) for the hardest work, Gemini 3.8 Flash as the main fast model ($0.75 / $3.75 through December 31, 2026, rising to $1.50 / $7.50 from January 1, 2027), and the Flash-Lite models ($0.25 to $0.30 input) for the cheapest volume work. Batch is half price. Gemini has the most generous free tier, which is excellent for prototyping, but Google's pricing page is explicit: free-tier data is used to improve Google's products, paid-tier data is not. Treat the free tier as a sandbox for non-sensitive data only.

xAI (Grok). Grok 4.7 ($2 / $6, cached input $0.50) with a 500k-token context window and configurable reasoning; older Grok 4.3 and 4.20 models run $1.25 / $2.50 with a 20 percent batch discount. Requests over 200k tokens bill at double. xAI states it never trains on API inputs or outputs without explicit permission, keeps requests for 30 days for abuse auditing, and offers self-serve zero data retention for team admins (which switches off Batch, Files and the stateful Responses features). A US-only regional endpoint is available for Grok 4.7 and 4.6 at 10 percent more per token. The API is OpenAI-compatible, so the OpenAI SDK works with a changed base URL.

DeepSeek. The cheapest by a wide margin: deepseek-flash at $0.30 / $1.20 and deepseek-v4-pro at $1.32 / $3.96 during peak hours, both half that off-peak, with a 1M-token context and near-free cache hits. It speaks both the OpenAI and Anthropic API formats. The catch is data: DeepSeek's privacy policy says it collects, processes and stores personal data in the People's Republic of China and lists model training among its uses (API data processed for your end users is addressed separately, with you as the controller). For most businesses that means: fine for public or synthetic data and cost experiments, not for customer data, unless you run the open-weight versions DeepSeek has published on your own infrastructure.

Worth knowing beyond these five. If EU data residency is a hard requirement, look at Mistral, a European provider with its own API platform, and check its data processing terms directly. If your company is already committed to AWS, Google Cloud or Azure, you can reach several of these models through those clouds (Claude on Bedrock and Vertex, Gemini on Vertex, OpenAI models on Azure) under the contract and compliance setup you already have.

The line I want every founder to remember: at list prices, a million output tokens costs $0.50 on Claude Haiku 5.5 or GPT-6 Luna and $50 on GPT-6 Astra or Claude Fable 5.1, a hundredfold spread inside the same two vendors. Model choice per task is the biggest cost lever you have, far bigger than the choice of vendor.

Which AI API should your business use?

Pick the provider per job, not per company. In practice, most of the AI-first products I see end up on two providers: one main model for quality-sensitive work and a cheap fast model for volume, with a third wired in as a fallback.

Customer-facing chat, support and agents over your own documents: a mid-tier model (Claude Sonnet 5.5, GPT-6.1 Sol, Gemini 3.8 Flash or Grok 4.7) with prompt caching switched on. Run your own evaluation; differences between these on your actual data matter more than any public leaderboard.
Classification, extraction, tagging, routing: the small models (Claude Haiku 5.5, GPT-6 Luna, Gemini Flash-Lite, deepseek-flash for non-sensitive data). This is where most of the volume, and most of the savings, live.
Hard reasoning, code generation, long contract or due-diligence review: the top tier (Claude Opus 5.5, GPT-6 Astra, Gemini 3.1 Pro), used sparingly.
Very long documents in one request: OpenAI's 1.05M-token window, Grok 4.7's 500k, DeepSeek's 1M, or Claude and Gemini with long-context pricing. Check long-context surcharges before you design around them.
Regulated data (health, finance, children's data, DPDP or GDPR obligations): whichever provider will sign the agreement you need (a DPA, a BAA for HIPAA, zero retention, a residency commitment). That decision is legal and contractual first and technical second. My startup security checklist covers the rest of the stack, and for India specifically, the DPDP Act explainer.

Step 1: Decide what data will go into the model

Before you create a single account, write down which data will go into prompts. This one page decides which providers you are allowed to use, which tier, and which contract terms you need.

Sort it into three buckets: public or synthetic (marketing copy, public docs), internal (your own business data, code, plans), and regulated or customer personal data (health records, payment details, children's data, anything under GDPR, HIPAA or India's DPDP Act). Public data can go anywhere, including free tiers. Internal data needs a paid API tier with no training. Regulated data needs a signed agreement and, usually, zero or minimal retention and a residency commitment. If you skip this step, the decision gets made by whichever engineer creates the first key.

Step 2: Create a business organisation in each console

Create each account as an organisation owned by the company, not as a personal login that leaves when the engineer does. Use a shared admin email or SSO where the provider supports it, add at least two admins, and invite engineers as members rather than sharing a login.

The consoles:

OpenAI: platform.openai.com (API keys at platform.openai.com/api-keys).
Anthropic: the Claude Console at platform.claude.com.
Google Gemini: Google AI Studio at aistudio.google.com/apikey, which creates a Google Cloud project behind the scenes. Use a company Google Cloud project, not a personal one.
xAI: console.x.ai.
DeepSeek: platform.deepseek.com.

Step 3: Set up billing, credit limits and usage tiers

Fund each account with prepaid credits or a capped card, and set a monthly spend limit and alerts on day one. A bug that loops an API call overnight is the most common way a startup gets a surprise AI bill, and spend caps are the cheapest insurance you will ever buy.

xAI requires credits before the first call. Gemini only stops using your data for product improvement once billing is enabled on the project, so turn billing on before any real data goes in. Every provider also has rate limits that rise with your spend history; if you are launching to a large audience, check your tier a week before, not on launch day.

Step 4: Create scoped API keys and store them properly

Create one key per environment and per application (for example, "support-bot-production" and "support-bot-staging"), never one shared key for everything. Store keys in a secrets manager (AWS Secrets Manager, Google Secret Manager, Doppler, or your platform's encrypted environment variables), and never put a key in frontend code, a mobile app bundle, or a Git repository. Every request from a browser or app should go through your own backend, which holds the key.

Name each key so you can tell from the console what breaks if you revoke it, and rotate keys when anyone with access leaves. Each SDK reads its key from a standard environment variable: OPENAI_API_KEY, ANTHROPIC_API_KEY, GEMINI_API_KEY, XAI_API_KEY, and for DeepSeek, whatever name you choose.

Step 5: Make your first API call to each provider

Here is the smallest working call for each, in Python. Install the SDKs first:

pip install openai anthropic google-genai

OpenAI (Responses API):

from openai import OpenAI

client = OpenAI() # reads OPENAI_API_KEY

response = client.responses.create(
    model="gpt-6.1-sol",
    input="Summarise this support ticket in one sentence: ...",
)
print(response.output_text)

Anthropic (Claude Messages API):

import anthropic

client = anthropic.Anthropic() # reads ANTHROPIC_API_KEY

message = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1000,
    messages=[{"role": "user", "content": "Summarise this support ticket in one sentence: ..."}],
)
for block in message.content:
    if block.type == "text":
        print(block.text)

Swap in the Sonnet 5.5 or Haiku 5.5 model ID from Anthropic's models page for cheaper, faster calls.

Google Gemini:

from google import genai

client = genai.Client() # reads GEMINI_API_KEY

interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input="Summarise this support ticket in one sentence: ...",
)
print(interaction.output_text)

xAI Grok (using the OpenAI SDK):

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.getenv("XAI_API_KEY"),
    base_url="https://api.x.ai/v1",
)

response = client.responses.create(
    model="grok-4.7",
    input="Summarise this support ticket in one sentence: ...",
)
print(response.output_text)

DeepSeek (OpenAI-compatible):

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.getenv("DEEPSEEK_API_KEY"),
    base_url="https://api.deepseek.com",
)

response = client.chat.completions.create(
    model="deepseek-flash",
    messages=[{"role": "user", "content": "Summarise this public FAQ in one sentence: ..."}],
)
print(response.choices[0].message.content)

Notice that three of the five accept the OpenAI SDK with a different base URL, and DeepSeek also accepts the Anthropic format. That compatibility is what makes the architecture in Step 7 cheap to build.

Step 6: Lock down data retention, residency and compliance

Confirm in writing what each provider does with your data, then switch on the controls you are entitled to. The defaults are reasonable for internal data; regulated data needs more.

Training: confirm "no training on API data" applies to your account (it is the stated default for OpenAI, Anthropic, xAI and paid Gemini; it is not the default for Gemini's free tier).
Retention: OpenAI and xAI keep logs up to 30 days for abuse monitoring by default; Anthropic does not retain conversation content by default except for certain premium models. Ask for zero data retention if you are eligible, and note what it switches off (xAI's ZDR disables Batch and Files, for example).
Residency: if your customers or regulators require data to stay in a region, use the provider's residency option (OpenAI's regional storage and processing, Anthropic's residency setting on the Messages API, xAI's US endpoint) or route through your existing cloud region on Bedrock, Vertex or Azure.
Contracts: sign the provider's DPA, and a BAA if you handle US health data. Keep copies; investors' technical due diligence will ask.
Prompt injection and tool access: if the model can call tools or read customer content, treat every model output as untrusted input. I wrote up the attacks in prompt injection explained.

Step 7: Build a provider-agnostic layer so you can switch

Never call a provider's SDK from all over your codebase. Put one small module in between: your code asks it to "summarise this ticket" or "classify this email", and the module decides which provider and model handles it, from configuration. That one decision lets you change models when prices move, fail over when a provider has an outage, and route each task to the cheapest model that passes your tests.

Keep the layer thin: a function per task type, a config file mapping each task to a provider and model, a fallback provider for each, timeouts and retries, and logging of tokens and cost per call. Open-source gateways and routers exist if you would rather not write it, but the principle is the same: your product should never know which vendor answered.

Step 8: Test on your own data and measure cost per task

Public benchmarks tell you which model is good in general; only your own test set tells you which is good for your job. Collect 30 to 50 real examples of the task (with personal data removed or replaced), write down what a good answer looks like, and run every candidate model over the set.

Score quality, then compute cost per successful task , not cost per token. A model that is three times cheaper per token but fails one task in five, forcing a retry or a human review, is often the expensive option. Re-run the set every time a provider ships a new model; with five vendors releasing on their own schedules, that is roughly monthly.

Step 9: Run it in production without surprises

The production checklist I hand to teams:

Switch on prompt caching for repeated system prompts and documents. Cached reads are a fraction of the normal input price on every provider here.
Use batch APIs for anything not real-time (nightly classification, report generation): half price on OpenAI, Anthropic and Gemini.
Set timeouts, retries with backoff, and a fallback model for every call path.
Log usage per feature and per customer , so you can see which feature is burning the budget.
Alert on spend anomalies daily , not when the monthly invoice arrives.
Pin model versions in production and upgrade deliberately after your test set passes; aliases quietly move to new versions.
Rotate keys on a schedule and when people leave.

If your team has not done this before, this is precisely the work a fractional CTO or a technical advisor covers in the first weeks of an AI build, and it is far cheaper to set up correctly than to unwind later. If you are earlier than that and still scoping the product, the MVP cost calculator includes LLM integration as a line item.

Frequently asked questions

Is the ChatGPT API the same as the OpenAI API? Yes. ChatGPT is OpenAI's chat app; the API that businesses build on is the OpenAI API, managed from the OpenAI Platform at platform.openai.com. It is billed per token, separately from any ChatGPT subscription.

Which AI API is cheapest for business use? At list prices, DeepSeek's deepseek-flash is the cheapest of the five, especially off-peak, but its data is stored in China. Among the US providers, the small models (GPT-6 Luna and Claude Haiku 5.5 at $0.10 input and $0.50 output, Gemini Flash-Lite at $0.25 to $0.30 input) are the cheapest. Measure cost per successful task, not per token.

Do OpenAI, Anthropic, Google and xAI train on my API data? By their own documentation, not by default on paid API traffic. The exception to watch is Google's Gemini free tier, where Google states data is used to improve its products. Always confirm the terms for your account and sign a DPA.

Is DeepSeek safe for business? For public or synthetic data and cost experiments, it can be useful. For customer or regulated data, its privacy policy states that data is stored and processed in China, which most businesses (and many regulators) will not accept. Self-hosting an open-weight DeepSeek model on your own infrastructure avoids that, at the cost of running the infrastructure yourself.

Can I use more than one AI provider? Yes, and most serious AI products should. Use a thin provider-agnostic layer in your code, route each task to the model that wins on your test set, and keep a second provider as a fallback for outages.

Should I use the API directly or through AWS Bedrock, Google Vertex AI or Azure? If your company already runs on one of those clouds and needs its compliance, billing and regional controls, going through the cloud is often simpler. If you are a startup choosing fresh, the direct APIs get new models first and are simpler to start with.

If you are about to wire AI into your product and want a second pair of eyes on the provider choice, data terms, and architecture before you commit, book a 30-minute call. I will tell you which models to start with for your use case, what it should cost per month at your volume, and what to lock down before any customer data goes in. You can also reach me through the contact page, or read how a CTO as a service engagement covers this end to end.

What Does a CTO Do in a Startup? The Role at Every Stage, From Someone Who Has Done It Six Times

Kunal Vohra — Fri, 09 Oct 2026 12:00:00 +0000

What does a CTO do in a startup? A startup CTO owns every technical decision the company cannot afford to get wrong: what gets built and what does not, how it is built so it survives growth, who builds it, and how it stays secure. At pre-seed that mostly means writing the code yourself. At Series A it mostly means building the team that writes it. The title stays the same; the job underneath it changes almost completely with every stage.

I have been the CTO or technical co-founder in six ventures across the USA, the UAE and India over more than ten years, and I now do the job as a fractional and interim CTO for AI-first startups. Founders ask me this question in two forms. Technical founders ask "what am I supposed to be doing now that I have the title?" Non-technical founders ask "what would a CTO actually do here, and do I need one yet?" This guide answers both.

What does a CTO do in a startup, in one sentence?

A startup CTO turns the business plan into a technical plan, and then makes sure the technical plan actually ships. Everything else on the list (architecture, hiring, security, vendors, investor questions) is a part of that one job.

The useful way to think about it: the CEO decides where the company is going, and the CTO decides what the company has to build, buy, and become technically to get there, at a cost the runway can survive. A big-company CTO is often an external-facing technology strategist. A startup CTO is an owner. If the product is slow, insecure, late, or built on a decision nobody can reverse, it is the CTO's problem, whatever the org chart says.

The core startup CTO responsibilities

The startup CTO responsibilities fall into six buckets. Which one dominates depends on stage, but a CTO who ignores any of them for long will pay for it later.

1. Technical strategy and architecture. Choosing what to build versus buy, picking the stack, and designing systems that will not need a rewrite at ten times the load. Just as important is what not to build: killing overengineering before it eats the runway is a large part of the job.

2. Shipping the product. Owning delivery: the roadmap from the technical side, release discipline, deployment, and the honest answer when the founder asks "can we have this by March?" Early on, this is literally writing the code.

3. Building the engineering team. Writing the role, interviewing for real signal, onboarding, code review culture, and eventually hiring the managers who hire everyone else. The first five engineers set the standard for the next fifty.

4. Security, data, and compliance. Access control, secrets, backups that have actually been restored, and whatever your market requires (HIPAA, SOC 2, GDPR, India's DPDP Act). My M.Tech is in cybersecurity, so I am biased here, but security is the one bucket that cannot be cheaply retrofitted once users and attackers have a reason to probe you. My startup security checklist is the order I fix things in.

5. Vendors, cost, and AI choices. Cloud bills, model providers, third-party APIs, agencies. In 2026, an AI-first startup's CTO spends real time on which model calls are worth their cost and which AI-generated code can be trusted in production.

6. The technical face of the company. Investor due diligence, enterprise customer security questionnaires, partner integrations, and occasionally a sales call where someone needs to hear "yes, it scales" from the person accountable if it does not. I wrote up what investors actually check in technical due diligence separately.

The startup CTO role by stage

The startup CTO role is not one job; it is three or four jobs that share a title. The most common failure I see is a CTO doing the job from the previous stage, or the next one.

Pre-seed (zero to two engineers): the builder. The CTO writes most of the code, chooses the stack, sets up the cloud accounts, and makes fast decisions that are good enough rather than perfect. The danger is gold-plating: building for a million users when you have twelve. A pre-seed CTO's best skill is knowing which shortcuts are safe.

Seed (two to eight engineers): the player-coach. Still writing code, but now hiring, reviewing, and setting the habits (code review, testing where it matters, a deploy process that does not depend on one person's laptop). This is where architecture decisions start to compound, and where the first security and data decisions get made, usually by default rather than on purpose.

Series A (eight to twenty engineers): the leader. Coding drops to a fraction of the week, often to nothing. The job becomes structure: team leads, a hiring pipeline, a technical roadmap the board can read, platform decisions that let several teams ship without stepping on each other. Many technical founders struggle here, because the work that made them valuable is no longer the work.

Series B and beyond: the executive. Organisation design, budgets, long-range technical strategy, and usually a VP of Engineering running day-to-day delivery underneath. At this point the startup CTO starts to look like the textbook CTO.

The line I give founders, and the one worth quoting: below three engineers a CTO is mostly a builder; past eight, mostly a leader; and the expensive mistakes happen when someone does the wrong one of those jobs for too long.

What a startup CTO does in a typical week

To make this concrete, here is roughly how a seed-stage CTO's week breaks down when the role is working. The proportions shift by company, but the categories hold.

Building and reviewing (often half the week or more). Writing the hard parts, reviewing every meaningful pull request, unblocking engineers.
Planning with the CEO. Translating next quarter's business goals into what gets built, and pushing back when the plan does not fit the team or the runway.
Hiring. Sourcing, interviews, take-home reviews, reference calls. At seed this is a standing slot, not an occasional task.
Operations and incidents. The deploy that broke, the cloud bill that doubled, the customer who found a bug in production.
Security and data hygiene. Small, unglamorous, and the bucket that most often gets skipped until someone asks for a SOC 2 report.

The unofficial part of the job is being the person who picks up the phone when something breaks the night before a demo. In the edtech venture where we ended up building our own Linux OS from zero, our first full run (500,000 assessments in one hour) nearly came undone because of one wrong line in an AWS load balancer configuration, caught at the last moment. No job description lists that. It is still the job. I wrote the full story in the edtech case study.

CTO vs VP of Engineering: who does what

A CTO owns what gets built and why, technically; a VP of Engineering owns how the team delivers it, week to week. In a seed-stage startup they are the same person. They split when the team grows large enough that technical direction and delivery management each become a full-time job, typically somewhere past Series A.

The CTO is responsible for: architecture and technical strategy, build-versus-buy, security posture, technical risk, the long-range platform, and the technical story for investors and enterprise customers.

The VP of Engineering is responsible for: delivery, process, team health, management structure, hiring throughput, and performance.

If your technical co-founder is a brilliant architect who hates managing people, the usual answer at Series A is not to replace them; it is to hire a VP of Engineering underneath them and let each do the job they are good at. If they are a natural manager who has drifted away from technical depth, the split runs the other way.

Technical co-founder vs CTO

A technical co-founder is a CTO who joined before there was a company to join. The responsibilities are the same at pre-seed; the difference is risk, timing, and compensation. A co-founder shares the founding risk and holds a large equity stake (the equity split guide covers what is fair). A hired CTO joins after funding, is paid mostly in salary (roughly $180,000 to $260,000 at seed to Series A in the US) and gets a smaller stake, usually 1 to 4 percent on a four-year vest. The full breakdown is in startup CTO salary and equity.

One more distinction founders miss: the co-founder title does not guarantee the person can do the Series A version of the job. Plenty of excellent technical co-founders are happiest as builders. Talk about that early, before the company forces the conversation.

Does a startup need a CTO at all?

Not always, and not yet. If you have no product, no engineers, and no code, you do not need a CTO; you need the product to exist, which is a build problem. If an agency or a freelancer is building your MVP, you need someone senior to check their work, which is an advisory problem. A CTO becomes necessary when there is a team to lead, an architecture to own, and a roadmap someone has to be accountable for.

Here is how I map stage to the shape of technical leadership:

No product yet: get it built well. A scoped build (MVP development; the MVP cost calculator gives you a range for your own scope) plus a few hours a month of senior review.
Agency or freelancer building, no internal engineers: a technical advisor for decision review. My Technical Advisor tier is $750 a month (15+ hours) at the rate I am holding through December 2026.
Two to eight engineers, funded: a fractional CTO two or three days a week who owns the decisions above. My Fractional CTO tier is $2,500 a month (50+ hours) in the same window; the fractional CTO cost guide puts it next to market rates.
CTO just left, raise is weeks away, or the product is stuck: an interim CTO who steps in near full-time for three to nine months and often hires the permanent replacement.
Eight or more engineers and a funded roadmap: a full-time CTO. A full-time startup CTO in the US costs about $260,000 a year fully loaded, before equity, and is worth it once leadership is a full-time job. The hiring guide walks through the search.

If you are not sure which line you are on, the fractional versus full-time comparison goes deeper on the trade-off, and what a fractional CTO is explains how the part-time version of this role works.

How to tell if your CTO is doing the job well

Judge a startup CTO on outcomes, not activity. Non-technical founders often cannot evaluate the code, but they can evaluate whether the technical side of the company is getting easier or harder to run. Five signals I look at when a founder asks me to assess their technical leadership:

Predictability. Engineering estimates are roughly right, and when they slip, you hear about it early, not on the deadline.
No surprises in production. Outages happen, but they are rare, explained, and followed by a fix to the cause.
Hiring works. Good engineers join and stay, and the CTO can explain why.
Decisions are written down. Major architecture and vendor choices have a short written rationale someone else can read.
You understand the trade-offs. A good CTO can explain any technical decision to a non-technical founder in plain language, including what it costs and what it rules out.

If most of those are failing, the problem is rarely talent. It is usually a CTO doing the wrong stage's job, or a CTO with no one senior to push back on them.

Frequently asked questions

What does a CTO do in a startup day to day? At pre-seed and seed, mostly building: writing and reviewing code, deploying, fixing what breaks, plus hiring and planning with the CEO. From Series A onward, mostly leading: hiring, structuring teams, owning the technical roadmap, security, vendors, and investor and customer technical questions.

What are the main responsibilities of a startup CTO? Technical strategy and architecture, shipping the product, building the engineering team, security and compliance, vendor and cost decisions (including AI models), and representing the technology to investors and enterprise customers.

Does a startup CTO write code? At pre-seed and seed, yes, and a lot of it. With fewer than six engineers, a CTO who does not write code is a manager without enough people to manage. By Series B, a CTO who still writes most of the critical code has usually become the bottleneck.

What is the difference between a CTO and a VP of Engineering? The CTO owns technical direction (what gets built and why, architecture, security, technical risk). The VP of Engineering owns delivery (process, team health, management, hiring throughput). In an early startup one person does both; they split once the team is large enough that each is a full-time job.

When should a startup hire a CTO? Hire a full-time CTO when you have a funded roadmap and roughly eight or more engineers. Before that, a technical co-founder, a fractional CTO, or a technical advisor usually covers the role at a fraction of the cost.

Can a fractional CTO do the job of a startup CTO? For most companies with fewer than eight engineers, yes: a fractional CTO owns the same decisions, just on two or three days a week instead of five. The limit is when the team is large enough that the CTO's availability becomes the bottleneck, which is the point to hire full-time.

If you are trying to work out what your startup needs from technical leadership right now, book a 30-minute call. Tell me your stage, your team, and what feels stuck, and I will tell you straight whether you need a CTO, a fractional CTO, an advisor, or simply a well-scoped build first. You can also reach me through the contact page.

How to Build an MVP Without a Technical Co-Founder (From Someone Who Has Been One Six Times)

Kunal Vohra — Wed, 07 Oct 2026 12:00:00 +0000

You can build an MVP without a technical co-founder, and for most non-technical founders it is the better path. If your product is a well-understood build (a marketplace, a booking flow, a dashboard, a mobile app over an API), you need it built well, not invented. The way to do it: validate demand first, write a scope a builder can price, hire a builder whose price you can check, rent senior technical judgment by the month instead of paying for it in equity, and make sure you own every line of code and every account from day one.

I say that as someone who has been the technical co-founder six times. I am not against co-founders; I have been one, and I still take on a partnership very selectively. But the most common mismatch I see is a founder offering 30 to 50 percent of the company to someone when what they actually needed was an app built. This guide is the path I would walk you through on a call if you came to me without a technical partner.

Can you build an MVP without a technical co-founder?

Yes, when three things are true: the product is a known pattern rather than a technical invention, you can fund development even modestly, and your advantage is distribution or domain knowledge rather than the technology itself. In that situation a co-founder search is the slow, expensive route to the same MVP.

A co-founder search done properly takes three to nine months. The equity you give away is the most expensive money you will ever spend. And the failure mode, a mediocre partnership entered because you were tired of searching, is worse than finding nobody, because the wrong person now owns a large slice of the company and votes on its future.

Here is the arithmetic I ask founders to do coldly. Thirty percent of a company that later raises at a $10 million valuation is a $3 million claim on paper; a typical MVP, even from an expensive agency, costs a small fraction of that. Equity is the most expensive way to pay for a build.

When you really do need a technical co-founder

You need a technical co-founder when the technology is the moat: novel AI systems, hard infrastructure, security-critical products, anything where the person who solves the technical problem is the reason the company can exist. You also need one if you cannot fund development any other way, or if investors in your space effectively require a technical founder on the cap table.

If that is you, skip the rest of this and read how to find a technical co-founder, then the technical co-founder equity split guide before you make anyone an offer. If you want to talk to me about a partnership, the bar I apply is on the technical co-founder page.

For everyone else, here is the build path.

Step 1: Validate before you build anything

The cheapest MVP is the one you never had to build because twenty conversations told you nobody would pay. Building is not validating. Before you spend anything on development, get evidence: a landing page with a waitlist, a concierge version you run by hand, pre-orders, or a letter of intent from a customer who has the problem today.

"Built too much too early" is a recurring cause of death in the startups I have watched fail, including some of my own, which I wrote up in what killed the startups I co-founded. A non-technical founder has one advantage here: you are not tempted to build because building is fun. Use it.

What you want at the end of this step is not certainty. It is one sentence you can defend: "These specific people have this specific problem, and this is the smallest thing that would prove they will pay to solve it."

Step 2: Write an MVP scope a builder can actually price

A good MVP scope for a non-technical founder is written in screens, roles, and flows, not in features. "Users can book appointments" can be a three-screen job or a forty-screen job; nobody can price it, and nobody can be held to the price.

Write it like this:

Roles. Who uses the product? A customer, a provider, an admin? Every extra role adds its own screens and permissions, and it is the single biggest multiplier founders miss.
The core flow, screen by screen. Sign up, the one action that proves the value, the one moment money changes hands. Sketch each screen on paper; a photo of a napkin is fine.
Integrations. Payments, email or SMS, maps, an AI model, a calendar. Each one is real work behind a screen that looks simple.
Platforms. Web only, mobile, or both. Mobile adds store submission and review.
What is explicitly out. The most useful line in any scope document is the list of things you are not building yet.

If you want to see how these choices move the price before you talk to anyone, the MVP cost calculator walks you through exactly this scoping pass (roles, platforms, complexity, integrations, design, deployment) and gives you a range on the page, no email required.

Step 3: Choose who builds your MVP

There are five realistic ways for a non-technical founder to get an MVP built in 2026, and the price differences are mostly about overhead and incentives, not quality. The question that matters is not "who is cheapest" but "whose price and whose work can I check without being technical myself?"

Freelancers ($5,000 to $30,000). The cheapest lane and the highest variance. A great freelancer is the best deal in software; an average one leaves you with a codebase nobody else will touch. The trouble is that a non-technical founder usually cannot tell which one they hired until it is late.

Offshore agencies ($15,000 to $50,000). Fixed-scope quotes that look complete. The change requests are where the real bill lives, so a tight Step 2 scope protects you more here than anywhere.

US and Western European agencies ($50,000 to $150,000+). Same software, different payroll. Sometimes worth it for a funded team that needs a warranty-grade vendor; rarely the right call at pre-seed.

No-code and AI-assisted builds ($500 to $10,000). A real option in 2026, and I build with AI tools daily. Good for validating demand. The costs arrive later: platform lock-in, per-user pricing that scales against you, and a rebuild the moment you need something the platform did not anticipate. If you go this way, treat it as an experiment you expect to replace.

Per-screen pricing with senior ownership. This is how I build MVPs, with my team at Panicle Tech doing the design and engineering: every screen is counted in a scoping week and the total is the screen count times the rate, currently held at $30 a screen (standard $80) across mobile, web, desktop, and Linux. A typical build runs 8 to 12 weeks, and a screen added mid-build costs the same rate as the first one. Details are on the MVP development page.

Whichever you pick, the market numbers above are the same ones in my MVP development cost breakdown, which goes deeper on the hidden costs nobody puts in the quote.

Step 4: Rent technical judgment instead of giving it away in equity

The hardest part of building without a technical co-founder is not the code. It is the decisions: which stack, what to build properly now and what to fake until later, whether the estimate you were given is honest, and whether the person building is cutting a corner you will pay for in six months. A builder writes code; somebody senior has to own the architecture.

You can rent that judgment at a fraction of a co-founder's equity:

A technical advisor for a few hours a month: reviewing the scope, sanity-checking quotes, sitting in on the weekly demo, and telling you when something smells wrong. My Technical Advisor tier is $750 a month at the rate I am holding through December 2026.
A fractional CTO when the build is bigger, there is more than one vendor, or you are about to hire your first engineers. My Fractional CTO retainer is $2,500 a month for 50+ hours. The full market picture, including what others charge, is on the fractional CTO cost page.

The reason this matters: architecture mistakes made in week three become five-figure bills by month six. An MVP built without senior technical ownership is cheap only until the first rewrite.

There is a side benefit nobody mentions. Working with a senior technical person for a few months is the best possible way to find out whether you want them as a co-founder. You choose after you have worked together, not before.

Step 5: Own the code, the accounts, and the IP from day one

This is the step non-technical founders skip, and it is the one that hurts most when a build goes wrong. Before any work starts, make sure of all of these:

The code lives in a repository in your company's account, with the builder invited as a collaborator. Not their account, shared with you later.
Cloud, domain, app store, email, and payment accounts are in your company's name, paid with your company's card. The builder gets access; you hold the keys.
IP is assigned to your company in the contract, from the first commit, not on final payment.
Handover is part of the scope: a readme, how to deploy, where the secrets are kept, and what the next engineer needs to know.
Post-launch support is written down. The first two weeks after launch always surface issues; mine include two weeks of support for exactly that reason. If it is not in your contract, you will pay hourly at the worst possible moment.

Ask every builder one question before you sign: "Who maintains this code after handover, and what will they need from you?" Watch how they answer.

Step 6: Run the build like a founder, not a client

You do not need to read code to manage a build well. You need a rhythm that makes problems visible early:

A working demo every week, on a staging link you can click yourself. Slides and status reports do not count.
Real data early. A screen that only works with "Test User 1" is not done.
One decision log. Every time scope changes, write down what changed and what it costs. This is the document that saves the relationship.
Your first five users on the staging build before launch, not after.

If week four arrives and you still cannot click anything, that is the moment to bring in a second opinion, not week ten.

What to do after the MVP ships

Once the MVP is live and real users are on it, you have three sensible next moves, and the right one depends on traction rather than ambition.

If users are not sticking, go back to Step 1; more engineering will not fix a demand problem. If users are sticking and the roadmap is growing, a fractional CTO or an interim CTO gives you senior leadership while you hire your first engineers. And if the company is funded with a real roadmap and a team past six to eight engineers, that is when a full-time CTO hire starts to make sense, which I cover in how to hire a CTO for your startup.

Notice that "find a technical co-founder" can still appear on that list. It just appears after there is a product, users, and evidence, which is exactly when good technical people are most willing to say yes.

Mistakes non-technical founders make building an MVP

Paying in equity for a build. Equity buys a partner. If you need a product built, pay for the product.

Hiring the cheapest quote with no one senior checking it. The cheap build and the expensive rewrite are often the same invoice, spread over a year.

Letting the builder own the accounts. It is not malicious most of the time. It is still how founders end up unable to deploy their own product.

Scoping in features instead of screens. If the scope cannot be counted, the price cannot be held.

Building the version-two product as the MVP. The admin panel, the analytics dashboard, and the referral system can almost always wait.

Frequently asked questions

Can a non-technical founder build an MVP? Yes. Most well-understood products (marketplaces, booking tools, dashboards, mobile apps over an API) do not need a technical co-founder to reach an MVP. They need a clear scope, a builder whose price you can check, senior technical oversight, and clean ownership of the code and accounts.

How much does it cost to build an MVP without a technical co-founder? In 2026 the market range runs from about $500 to $10,000 for no-code and AI-assisted builds, $5,000 to $30,000 for freelancers, $15,000 to $50,000 for offshore agencies, and $50,000 to $150,000 or more for US and Western European agencies. Per-screen pricing lets you compute the total from your screen count before anything is built; the MVP cost calculator gives a range for your own scope.

Should I give a developer equity to build my MVP? Usually not. Equity is the most expensive way to pay for a build, and it turns a vendor relationship into a partnership you may not want. Offer equity to someone who will own the technology long term, and only after you have worked together.

Do investors care if I do not have a technical co-founder? Some do, especially for deep-tech and AI-native companies where the technology is the moat. For most products, investors care more about traction and whether someone credible owns the technical decisions, which a fractional CTO or technical advisor can cover until you hire.

Can I build an MVP with no-code or AI tools instead? For validating demand, often yes. Plan for the limits: platform lock-in, pricing that grows with your users, and a likely rebuild once you need something the platform does not support.

How long does it take to build an MVP? A real MVP with senior ownership typically takes 8 to 12 weeks. Halving that usually means doubling the team, which more than doubles the cost, so be wary of anyone promising a full product in three weeks.

If you are a non-technical founder with an idea and no technical partner, book a 30-minute call. Tell me what you are building and I will give you a straight read on whether you need a co-founder at all, what the MVP should cost, and whether the right next step is a build, a fractional CTO, or twenty more customer conversations first. You can also reach me through the contact page.

Startup CTO Salary and Equity in 2026: What a CTO Actually Gets Paid, by Stage

Kunal Vohra — Mon, 05 Oct 2026 12:00:00 +0000

A startup CTO salary in 2026, for a full-time CTO hired at seed to Series A in the US, typically lands between $180,000 and $260,000, plus 1 to 4 percent equity vesting over four years with a one-year cliff. Earlier stage and a lower salary push the equity up; later stage and a market salary push it down. A technical co-founder is paid almost entirely in equity, and a fractional CTO is paid in cash with no equity by default.

That is the short answer. The rest of this piece is about where inside those ranges a specific person should land, because the range is wide for a reason and most of the bad offers I have seen come from founders picking a number without knowing which inputs move it.

I have sat on both sides of this table. I have been the technical co-founder six times, I have been hired as a fractional and interim CTO, and I have helped founders write offers for the CTO who would eventually replace me. This is the compensation conversation as I would have it with you on a call.

Startup CTO compensation at a glance

Startup CTO compensation is a trade between cash and ownership, and the exchange rate is set by risk. The earlier someone joins and the less salary they take, the more equity they are owed for carrying the difference. Here is the shape across the four roles people call "CTO", US market, mid-2026:

Technical co-founder, pre-product and pre-funding. Little or no salary; equity measured in tens of percent of the founder pool. This is a partnership, not a hire, and the technical co-founder equity split guide covers it in full.
Full-time CTO hired at seed to Series A. Salary typically $180,000 to $260,000 depending on city and how far below market the person is taking, plus 1 to 4 percent equity, four-year vest, one-year cliff.
Full-time CTO hired at Series B or later. Market salary, equity usually under 1 percent, negotiated against the last round's valuation rather than as a headline percentage.
Fractional CTO. A monthly retainer, typically $4,000 to $15,000 across the market for two to three days a week, with hourly rates between $150 and $350. No equity by default.

The quotable version: a 2 percent grant at a $20 million valuation is a $400,000 claim on paper, more than a year and a half of a fully loaded $260,000 CTO. Equity is never the free part of the offer.

What moves a startup CTO salary inside the range

The salary number is decided by four inputs, and founders usually only look at the first one.

1. Location and market. A CTO in a high-cost US hub sits at the top of the range; a remote hire, or one outside the big hubs, sits lower. This is the input everyone already knows, and it explains less of the spread than people assume.

2. How much below market the person is choosing to take. This is the real lever. A strong candidate who wants more upside will accept $180,000 against a market value well above it, and they will expect the gap to come back as equity. A candidate who needs the full number is telling you they are pricing the role as a job, which is fine, but the equity should then sit at the low end.

3. Runway. A $260,000 fully loaded CTO out of a $1.5 million seed round is a large share of the money you raised to reach your next milestone. I have watched founders hire the right person at the wrong salary and spend the next year shortening their own runway. If your runway cannot carry the salary, that is a signal about timing, not about how hard to negotiate.

4. Hands on the keyboard or not. With fewer than six engineers, a CTO who writes code is doing two jobs. A CTO who manages and does not build, at that team size, is a manager without enough people to manage, and the salary is buying less than it looks like.

One practical note: compare fully loaded cost, not base. A $200,000 base is roughly $260,000 once payroll taxes, benefits, equipment, and software are in, and that is the number your runway actually feels.

How much equity should a CTO get?

How much equity a CTO should get depends almost entirely on when they join relative to the money. Before funding, they are a founder and the numbers are in the tens of percent. After funding, they are an executive hire and the numbers are in low single digits. The mistake is mixing the two: asking a post-funding hire to accept co-founder risk, or offering a post-funding hire co-founder equity.

Rough bands I use as a sanity check:

Joins before any funding, builds the product from nothing. Co-founder territory. At the idea stage, 40 to 50 percent of the founder pool is defensible; with a prototype or revenue already on the table, lower. The full reasoning is in the equity split post.
Joins at or just after a pre-seed or seed round, below-market salary. The top of the hired-CTO band, around 3 to 4 percent, sometimes more if the salary discount is steep and the role is genuinely founding-team in practice.
Joins at seed to Series A, near-market salary. 1 to 2 percent is common.
Joins at Series B or later. Usually under 1 percent, and the conversation shifts from percentages to the dollar value of the grant at the last valuation.

Three adjustments sit on top of those bands. Equity should go up if the technology is the moat (novel AI systems, security-critical infrastructure, anything where the person solving it is the reason the company can exist). It should go up if the person is taking a real salary cut. And it should go down if the role is closer to "lead the team that builds a well-understood product" than to "invent the product".

For comparison, so you can see where the CTO sits in the cap table: a first engineer typically gets 0.5 to 2 percent with a salary, and an advisor typically gets 0.25 to 1 percent vesting over two years.

Startup CTO equity vs salary: how to trade one for the other

The startup CTO equity vs salary trade works best when you make it explicit. Instead of one offer, give the candidate two or three: a higher salary with less equity, and a lower salary with more. Their choice tells you how they are thinking about the company, which is information you want before they join.

The mechanics I recommend:

Anchor the cash at what your runway can carry, not at the candidate's market value. If those two numbers are far apart, the equity has to bridge the gap, or the hire is premature.
Price the gap honestly. If someone is taking $60,000 a year below market, four years of that is a quarter of a million dollars of their money invested in your company. The equity should reflect that they are, in effect, an investor as well as an executive.
Do not let equity substitute for a salary the person cannot live on. A CTO who is financially stressed makes short-term decisions. Below-market is fine; below-livable is a retention problem with a delay on it.
Revisit at the next round. A CTO who took a steep discount at seed should see their cash move toward market once the company can afford it. Agree that in writing at the start so it is a plan rather than a renegotiation.

Vesting, cliffs, and the terms that matter more than the number

Vesting matters more than the percentage, and founders discover this late. The standard is four years with a one-year cliff: nothing vests for twelve months, then monthly after that. It applies to every CTO, including a co-founder, including someone you have known for a decade.

The terms I would always look at alongside the headline grant:

The cliff. It is what makes a generous grant safe to offer. If the hire does not work out in month five, nobody walks away with a slice of the company.
Acceleration on a change of control. Common for senior hires, especially double-trigger (an acquisition plus losing the role). It is a reasonable ask from a CTO and a reasonable thing to grant.
The exercise window. If the person leaves, how long do they have to buy their vested options? A short window can make vested equity worthless to someone who cannot afford the exercise cost on short notice. Get a lawyer to explain your plan's terms before you make the offer.
Refresh grants. A CTO who joined at seed with 2 percent will be diluted by every round. Plan for refreshes as the company grows, or expect the conversation to come to you.

None of this replaces proper legal advice, and I am not a lawyer. But a founder who understands these terms will write a better offer than one who only negotiates the percentage.

Fractional CTO equity: when it makes sense

Fractional CTO equity is the exception rather than the rule. A fractional CTO is paid a monthly retainer for a defined amount of time, and the default is cash with no dilution, which is a large part of why the model works for funded companies with three to eight engineers.

Equity enters when a founder is cash-constrained but wants senior technical leadership committed for longer than a month-to-month invoice implies. In my own engagements I offer this as a cash and equity mix on any retainer, from a small equity component up to roughly half and half, negotiated on stage, runway, and how long we expect to work together, with standard vesting and a cliff, documented before we start.

The rule I give founders: never trade equity for a discount on a fractional retainer unless you expect the person to still be around in four years. Equity is the most expensive currency you have, and a retainer is the cheapest. If the relationship is a six-month bridge, pay cash.

For reference, my own retainers are published: $750 a month for a technical advisor, $2,500 for a fractional CTO, and $4,000 for an embedded CTO, sized from a held rate of $50 an hour (my standard is $100) through December 2026. The full side-by-side against a full-time hire is on the cost and rates guide.

The three compensation mistakes I see most

Co-founder terms for a hired CTO. The company has raised, there is a team, and the founder offers a below-market salary while calling the role "co-founding" to justify it. Experienced engineers recognise this immediately, and the ones who accept it are often the ones who cannot tell the difference.

Hiring the full-time salary too early. A $260,000 CTO for a product that does not exist yet, or a team of two, burns runway on leadership the company cannot use. The person usually starts a rewrite or a platform project to justify the seniority. Below three engineers, a technical advisor or fractional CTO covers it; past eight engineers and a funded roadmap, a full-time hire becomes the right call. The fractional versus full-time comparison walks through that line.

No vesting, or vesting only for the CTO. Every founder vests, including the majority holder. A fair grant without a cliff is worse than an aggressive grant with one.

When the right answer is not a CTO salary at all

Sometimes the honest answer to "what should I pay my CTO" is that you should not be hiring one yet. If there is no product, you need the product built, which is a build problem with a known cost rather than a leadership hire. I build MVPs through MVP development priced per screen, and the MVP cost calculator gives you a range before you talk to anyone.

If there is a product and a small team but leadership is not yet a full-time job, a fractional or interim CTO gives you the seniority without the salary or the equity. Many founders use that period to define the full-time role properly and hire for it, which is covered step by step in how to hire a CTO for your startup.

Frequently asked questions

What is the average startup CTO salary in 2026? For a full-time CTO hired at seed to Series A in the US, salaries typically fall between $180,000 and $260,000, depending on location and how far below market the person is taking in exchange for equity. Fully loaded with taxes and benefits, a $200,000 base costs the company roughly $260,000 a year.

How much equity should a CTO get at a startup? A full-time CTO joining after funding typically gets 1 to 4 percent, vesting over four years with a one-year cliff, with the higher end for earlier stages and below-market salaries. At Series B and later it is usually under 1 percent. A technical co-founder who joins before any funding is in a different band entirely, measured in tens of percent of the founder pool.

Should a startup CTO take more equity or more salary? It depends on how much risk they can carry and how much they believe in the company. The cleanest way to decide is for the founder to offer two packages, one cash-heavy and one equity-heavy, and let the candidate choose. Nobody should take a salary they cannot live on in exchange for equity.

Does a fractional CTO get equity? Not by default; a fractional CTO is paid a monthly retainer in cash. A cash and equity mix is possible when a founder is cash-constrained and expects a long relationship, and it should carry the same vesting and cliff as any other grant.

What vesting schedule is standard for a CTO? Four years with a one-year cliff, then monthly vesting. Senior hires often negotiate double-trigger acceleration on an acquisition. It applies to co-founders as well as hires.

Is technical co-founder equity different from CTO equity? Yes. A technical co-founder joins before the money and shares the founding risk, so they hold a large share of the founder pool. A hired CTO joins after there is a company and is paid mostly in cash, with a small grant to align incentives. The equity split guide covers the co-founder side.

If you are writing a CTO offer right now, or wondering whether you should be, book a 30-minute call and tell me where the company is. I will give you a straight read on the salary, the equity, and whether the right shape is a full-time hire, a fractional CTO, or neither yet. You can also reach me through the contact page.

How to Run AirLLM on a Mac (Apple Silicon): A Step-by-Step Setup Guide From an AI CTO

Kunal Vohra — Mon, 05 Oct 2026 12:00:00 +0000

To run AirLLM on a Mac, install AirLLM 2.11.0 with Apple's MLX in a Python virtual environment, download a Llama model to a drive with plenty of free space, and run it through a short wrapper script that fixes four Apple Silicon bugs. It works on any M-series Mac, including a base 16GB Mac mini. It is also slow, so read the speed section before you download 141GB of weights.

I am a fractional CTO for AI-first startups, and "can we just run the model ourselves?" comes up in almost every engagement. Last week I tested AirLLM on a 16GB M4 Mac mini and published the timings. This post is the setup behind those numbers, so you can reproduce it.

The short version:

Install exact versions: airllm 2.11.0, mlx 0.29.3, transformers 4.46.3, torch 2.8.0, sentencepiece.
Download an ungated Llama 3.1 copy to your fastest drive with the most free space.
Run it through the wrapper script below. It fixes two crashes, one garbled-output bug and one display bug.
Expect about 20 seconds per token for an 8B model and 2.5 to 3 minutes per token for 70B.

What you need before you start

An Apple Silicon Mac on macOS 14 or newer, Python 3.9 or newer, and free disk space of about twice the model's size. Memory matters far less than you would expect. Disk space and disk speed matter far more.

A Mac with an M-series chip. AirLLM's Mac code runs on Apple's MLX framework, which only supports Apple Silicon. My machine was a base M4 Mac mini with 16GB of memory.
macOS 14 (Sonoma) or newer. The MLX version below only ships for macOS 14 and up.
Python 3.9 or newer. I used the Python 3.9 that comes with Apple's Command Line Tools. If python3 --version fails, run xcode-select --install first.
Disk space of about 2x the model. AirLLM keeps the download plus a second copy split into one file per layer. Llama 3.1 8B needs about 16GB twice, so 32GB. Llama 3.1 70B needs about 141GB twice, so plan for 300GB.
Ideally, a fast external SSD. My internal disk had only about 35GB free, so the models lived on a 2TB Crucial X9 over USB, rated at about 1GB/s. That drive's speed sets the model's speed.

Step 1: Install AirLLM and the pinned versions

Create a virtual environment and install these exact versions; they are the ones from my working run.

python3 -m venv ~/airllm-env
source ~/airllm-env/bin/activate
pip install --upgrade pip
pip install "airllm==2.11.0" "mlx==0.29.3" "transformers==4.46.3" "torch==2.8.0" sentencepiece

Why these packages:

mlx and sentencepiece are not declared dependencies of AirLLM 2.11.0, but its Mac code imports both. Without them, it fails at import.
Pin airllm to 2.11.0. AirLLM 3.x and 4.0 came out between June and September 2026 and need Transformers 4.49 or newer. I have not tested them on a Mac. I checked the 4.0.0 Mac code, and the rope_theta bug from fix 3 below is still there, so the fixes likely still apply. Get one working run on 2.11.0 first, then experiment.

Step 2: Download a model to your external SSD

Download only the safetensors weights and the config and tokenizer files, into a folder on the drive with the most free space. Start with TinyLlama so you can test the whole pipeline in minutes.

# Smoke test: about 2GB, single-file model
hf download TinyLlama/TinyLlama-1.1B-Chat-v1.0 \
  --include "*.safetensors" "*.json" "*.model" \
  --local-dir /Volumes/YourSSD/models/tinyllama-1.1b-chat

# The real test: about 16GB
hf download unsloth/Meta-Llama-3.1-8B-Instruct \
  --include "*.safetensors" "*.json" "*.model" \
  --local-dir /Volumes/YourSSD/models/llama-3.1-8b-instruct

A few notes:

Replace /Volumes/YourSSD with your own drive.
I used Unsloth's copy of Llama 3.1, not Meta's. It holds the same weights and does not need an approval, so no Hugging Face login. Meta's licence still applies. To use Meta's gated repo (meta-llama/Llama-3.1-8B-Instruct) instead, accept the licence on its Hugging Face page, wait for approval, and run hf auth login first.
hf comes with the install above. On older setups the same command is huggingface-cli download.
The include filter matters. It skips extra files, such as Meta's original checkpoint, that would double the download.
Budget time. I saw about 26MB/s from Hugging Face. A 70B download takes over an hour on its own.

Step 3: Understand the four Apple Silicon fixes

AirLLM 2.11.0 runs on a Mac, but out of the box it has two crashes, one silent bug that garbles Llama 3 output, and one display problem. The wrapper script in step 4 fixes all four at runtime, so a reinstall never undoes them.

Fix 1: Create the missing index file

AirLLM only loads models that come with a model.safetensors.index.json file. Single-file models like TinyLlama do not have one, so AirLLM fails. The script builds the index from the tensor names in the file.

Fix 2: Create the layer folder first

AirLLM checks free disk space on the layer folder before it creates that folder. If the folder is new, it crashes with "No such file or directory". The script creates the folder first.

Fix 3: Use Llama 3's real rope_theta

This is the important one. AirLLM's Mac code never reads rope_theta (the base for position encoding) from the model config, so it falls back to 10,000. Llama 3.x uses 500,000. Nothing crashes; the model just writes confident nonsense. The script copies the right value from the config.

Fix 4: Stop at the end of the answer

Generation never stops on its own. It always runs to the token limit, so the answer is followed by junk. The script cuts the output at the end-of-answer marker.

Step 4: Save and run the wrapper script

Save this as airllm_mac.py. It applies the four fixes, runs one prompt, and prints the timing. It leaves the installed library untouched.

# airllm_mac.py: run AirLLM 2.11.0 on Apple Silicon with four fixes
import json
import sys
import time
from pathlib import Path

import mlx.core as mx
from safetensors import safe_open

import airllm.airllm_llama_mlx as airllm_mlx
from airllm import AutoModel

MODEL_DIR = Path(sys.argv[1]) # folder you downloaded the model into
LAYER_DIR = Path(sys.argv[2]) # folder for AirLLM's per-layer files
PROMPT = sys.argv[3] if len(sys.argv) > 3 else "What is the capital of France? Answer in one sentence."
MAX_NEW_TOKENS = 20

# Fix 1: single-file models need a generated index file
index_file = MODEL_DIR / "model.safetensors.index.json"
single_file = MODEL_DIR / "model.safetensors"
if not index_file.exists() and single_file.exists():
    with safe_open(str(single_file), framework="pt") as f:
        weight_map = {name: "model.safetensors" for name in f.keys()}
    index_file.write_text(json.dumps({"metadata": {}, "weight_map": weight_map}))

# Fix 2: the layer folder must exist before the free-space check
LAYER_DIR.mkdir(parents=True, exist_ok=True)

# Fix 3: use the model's own rope_theta (500000 for Llama 3.x)
_original_args = airllm_mlx.get_model_args_from_config

def args_with_rope_theta(config):
    args = _original_args(config)
    args.rope_theta = float(getattr(config, "rope_theta", None) or 10000)
    return args

airllm_mlx.get_model_args_from_config = args_with_rope_theta

model = AutoModel.from_pretrained(str(MODEL_DIR), layer_shards_saving_path=str(LAYER_DIR))
tokenizer = model.tokenizer

messages = [{"role": "user", "content": PROMPT}]
text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
input_ids = tokenizer(text, return_tensors="np", add_special_tokens=False)["input_ids"]

start = time.time()
output = model.generate(mx.array(input_ids), max_new_tokens=MAX_NEW_TOKENS)
elapsed = time.time() - start

# Fix 4: cut the output at the end-of-answer marker
for stop in (tokenizer.eos_token, "<|eot_id|>", "<|end_of_text|>"):
    if stop:
        output = output.split(stop)[0]

print(output.strip())
print(f"{MAX_NEW_TOKENS} tokens in {elapsed / 60:.1f} min, {elapsed / MAX_NEW_TOKENS:.1f} s per token")

Run the smoke test first, then the real model:

python airllm_mac.py /Volumes/YourSSD/models/tinyllama-1.1b-chat /Volumes/YourSSD/airllm-layers/tinyllama
python airllm_mac.py /Volumes/YourSSD/models/llama-3.1-8b-instruct /Volumes/YourSSD/airllm-layers/llama-8b

The first run of each model splits it into per-layer files before it generates anything. For the 8B model that took 43 seconds for 35 pieces. Later runs reuse those files and start generating straight away.

If it works, both models answer "The capital of France is Paris."

What speed to expect

About 1 second per token for a 1B model, about 20 seconds per token for 8B, and 2.5 to 3 minutes per token for 70B, on a drive that reads at about 1GB/s. AirLLM reads every layer from disk for every token, so the disk sets the pace, not the chip.

Seconds per token is roughly the model's size divided by your disk's read speed. On my Mac mini, Llama 3.1 8B read about 16GB per token at an effective 0.8GB/s: 19.6 seconds per token.

My measured numbers, with the prompt "What is the capital of France? Answer in one sentence." and 20 new tokens:

TinyLlama 1.1B: about 1 second per token. The model is small enough that macOS kept it in its file cache.
Llama 3.1 8B: 19.6 seconds per token. 6.5 minutes for 20 tokens, with the correct answer.
Llama 3.1 70B: projected at 140 to 180 seconds per token. That is around 30 minutes for one sentence. I did not run it; the 8B numbers make the math clear.

The only lever that moves these numbers much is disk speed. A Thunderbolt or USB4 NVMe drive at about 3GB/s should roughly triple the speed of the USB drive I used. The full breakdown is in my AirLLM test results.

Troubleshooting: common AirLLM errors on a Mac

Almost every failure maps to one of the four fixes, a missing package, or disk space. Find your error message below.

"Found local directory … but didn't find downloaded model", then "HFValidationError: Repo id must be in the form…" Your model folder has no index file, so AirLLM treats the folder path as a Hugging Face repo name. Fix 1 creates the index. Also check that the path points at the folder that holds the .safetensors file.
"model.safetensors.index.json should exist." Same cause, but you passed a Hugging Face repo name instead of a local folder. Download the model yourself (step 2) and pass the folder.
"No such file or directory" while loading. The layer folder does not exist yet. Fix 2 creates it.
Fluent but wrong or garbled output from a Llama 3 model. The rope_theta bug. Make sure fix 3 runs before AutoModel.from_pretrained.
The right answer followed by repeated or unrelated text. Generation ran to the token limit. Fix 4 trims it.
NotEnoughSpaceException. The layer folder's drive has less free space than the model. Free some space or point the layer folder at a bigger drive.
"No module named sentencepiece" or "No module named mlx". Install them into the same virtual environment you run the script from.
pip pulls in AirLLM 3.x or 4.x. You installed without the version pin. Reinstall with "airllm==2.11.0" and "transformers==4.46.3".
An assertion about bitsandbytes when you pass compression="4bit". AirLLM's 4-bit and 8-bit options need bitsandbytes, which needs an NVIDIA GPU. On a Mac you run full-precision layers.
A 401 or 403 error while downloading. You are using Meta's gated repo. Accept the licence, wait for approval and log in, or use the Unsloth copy.
Errors with Qwen, Mistral or other non-Llama models. On a Mac, AirLLM 2.11.0 sends every model through its Llama code, whatever the architecture. Stick to Llama-architecture models.

One gap remains after all four fixes: Llama 3.1's long-context scaling is not implemented in the Mac code. Short prompts are fine; very long ones may degrade.

Should you run AirLLM on a Mac at all?

Only when you need a model that does not fit in memory and you can wait minutes per word. For anything that fits, Ollama or LM Studio is hundreds of times faster. On the same 16GB Mac mini, an 8B model at 4-bit through Ollama runs at roughly 25 to 30 tokens per second, based on published reviews of similar machines.

Good uses: overnight batch jobs with a large model, and checking a large model's quality on your own prompts before you pay for hardware or API capacity.
Bad uses: anything interactive. Chat, coding assistants and agents need tokens per second, not seconds per token.

That decision (local model or API, which model, on what hardware, at what monthly cost) is one I make with founders regularly as a fractional CTO. If your team needs a second opinion on model hosting without a full retainer, a technical advisor engagement or CTO as a service covers it. If your startup is deciding who should own AI decisions at all, read what a fractional AI officer does, and if you are raising, my notes on AI startup technical due diligence cover the hosting questions investors ask.

Frequently asked questions

Does AirLLM work on Apple Silicon? Yes. On a Mac, AirLLM runs each layer on the GPU through Apple's MLX framework. Version 2.11.0 needs four fixes, including one without which Llama 3 models produce garbled output. All four fit in a small wrapper script.

How do I install AirLLM on a Mac? Create a Python virtual environment and pip install airllm 2.11.0, mlx, transformers 4.46.3, torch and sentencepiece. MLX and sentencepiece are not declared dependencies of AirLLM 2.11.0 but are required on a Mac.

Should I use the newest AirLLM version? Not for your first run. AirLLM 3.x and 4.0 were released in 2026 and need newer Transformers. I have not tested them on a Mac, and the 4.0.0 Mac code still has the rope_theta bug. Start with 2.11.0, which is tested here.

Can I run a 70B model on a 16GB Mac with AirLLM? Yes, if you have about 300GB of free disk. Expect around 2.5 to 3 minutes per token on a 1GB/s external SSD, which means roughly half an hour for a one-sentence answer.

Can I use 4-bit compression with AirLLM on a Mac? No. AirLLM's compression depends on bitsandbytes, which needs an NVIDIA GPU. On a Mac it runs full-precision layers, which is part of why it is slow.

Which models work with AirLLM on a Mac? Llama-architecture models in safetensors format, such as Llama 3.1 and TinyLlama. On a Mac, AirLLM 2.11.0 routes every model through its Llama code, so other architectures are likely to fail.

Is AirLLM faster than Ollama on a Mac? No. For any model that fits in memory, Ollama is hundreds of times faster, because it keeps 4-bit weights in memory instead of reading full-precision weights from disk for every token.

If you are weighing self-hosted models against an API for your product, book a 30-minute call and walk me through the workload. I will tell you what I would run, where, and what it should cost. You can also get in touch if you prefer to start by email.

I Tested AirLLM on a 16GB Mac Mini. Here's What "Runs a 70B Model on 4GB" Really Costs

Kunal Vohra — Fri, 02 Oct 2026 12:00:00 +0000

Every few months someone sends me the same link with the same question: "Is it true this runs a 70B model on a 4GB machine?" The link is AirLLM, an open-source Python library that claims to run very large language models on a GPU with as little as 4GB of memory. The question usually comes from a founder trying to decide whether they can stop paying for an LLM API and run a model on their own hardware.

So I tested it properly. One base Mac mini, one external SSD, three model sizes, and a stopwatch on every token.

The short answer: the claim is true, and it is misleading. AirLLM really does run models far bigger than your memory. On my machine, Llama 3.1 8B answered correctly at 19.6 seconds per word , and a 70B model would take two and a half to three minutes per word. Here is how it works, what it took to get running, and when it is actually worth using.

How AirLLM runs a big model on a small machine

AirLLM never holds the whole model in memory; it streams the model from disk one layer at a time, for every single token it generates. That is the entire trick, and it explains both why the claim is true and why it is slow.

A language model is a stack of layers. Llama 3.1 8B has 32 of them; the 70B version has 80. Normally the whole stack sits in memory and each token flows through it in milliseconds. AirLLM splits the model into one file per layer on disk. To produce a token, it loads the first layer, runs it, frees it, loads the next one, and so on to the end. Then it does the whole thing again for the next token.

Peak memory is one layer plus a small cache, so a 70B model really can run in a few gigabytes. The cost is that the full model is read from disk once per token. That gives you the only formula you need to predict AirLLM's speed:

Seconds per token is roughly the model's size divided by your disk's read speed.

A 141GB model on a 1GB/s drive is about 141 seconds per token before anything else happens. The GPU work is quick; the waiting is all disk.

My test setup

I ran everything on a base Apple M4 Mac mini with 16GB of unified memory, with the models stored on a 2TB Crucial X9 external SSD over USB, rated at about 1GB/s. The internal disk had only about 35GB free, which is too little for anything large, and that turned out to be a constraint worth writing about on its own.

The details, so you can reproduce it:

Software: AirLLM 2.11.0, Apple's MLX 0.29.3 (AirLLM uses MLX to run layers on the Mac's GPU), Transformers 4.46.3, PyTorch 2.8.0, and the Python 3.9 that ships with macOS.
Precision: full fp16 layers. AirLLM's 4-bit and 8-bit compression options depend on a library that needs an NVIDIA GPU, so they are not available on a Mac.
Models: TinyLlama 1.1B Chat as a smoke test, Llama 3.1 8B Instruct, and Llama 3.1 70B Instruct for the projection.
The test:"What is the capital of France? Answer in one sentence." with 20 new tokens and greedy decoding, timed end to end.
Disk budget: AirLLM keeps both the downloaded model and its split copy, so every model needs about twice its size in free space. The 8B model used 15GB plus 15GB; the 70B needs roughly 141GB plus 141GB.

Getting it running on Apple Silicon took four fixes

AirLLM works on a Mac, but not out of the box: I hit two crashes, one silent bug that would have garbled the output, and one cosmetic problem. The project's last release was in 2024, and its Mac code path shows it. I fixed all four in a small wrapper script rather than editing the library, so updates would not undo them.

It only accepts models split into several shards. AirLLM looks for a model.safetensors.index.json file. Models shipped as a single file, like TinyLlama, crash with an assertion error. The fix was to download the model myself and generate that index file when it is missing.
The layer folder has to exist before AirLLM checks your free space. Point it at a new folder on an external drive and it crashes with "No such file or directory". Creating the folder first fixes it.
The Mac path hard-codes a setting that Llama 3 changed. AirLLM's Apple Silicon code sets the position-encoding base (rope_theta) to 10,000, which was right for older Llama models. Llama 3.x uses 500,000. Nothing crashes; the model just produces confident nonsense. I patched it to read the value from the model's own config, and the 8B output came back correct.
Generation does not stop when the answer ends. It keeps going until it hits the token limit, so you get the answer followed by junk. Trimming at the end-of-answer marker fixes the display.

One gap remains: Llama 3.1's long-context scaling is not implemented on the Mac path. Short prompts are fine; very long ones may degrade. If you are evaluating open-source AI tooling for a product, this is the pattern to expect from research-grade libraries: the headline works, the edges are yours to maintain.

The results: 1 second per word, then 19.6

Both models answered "The capital of France is Paris." TinyLlama took 1.0 second per token; Llama 3.1 8B took 19.6 seconds per token, close to what the SSD's speed predicts.

TinyLlama 1.1B: about 1 second per token. Twenty tokens took 0.3 minutes. All 22 layers ran in under a second per pass. The model is about 2GB, so after the first pass macOS kept it in its memory cache and the SSD was barely touched. Small models get a free speed boost this way.

Llama 3.1 8B: 19.6 seconds per token. Twenty tokens took 6.5 minutes. The 32 transformer layers took about 16 seconds per pass, roughly two layers per second. The remaining three and a half seconds went mostly to the two vocabulary layers at the start and end of the model, about 1GB each, which are reloaded for every token. At 15GB per token in 19.6 seconds, the effective read speed was about 0.77GB/s, most of the drive's rated 1GB/s.

Splitting the 8B model into per-layer files was quick by comparison: 35 pieces in 43 seconds, once the 15GB download had finished. Here is the actual run, straight from my terminal:

Llama 3.1 70B, projected: two and a half to three minutes per token. I did not run it; the 8B result makes the math clear. Scaling the 8B numbers to a 141GB model at 0.8 to 1GB/s gives 140 to 180 seconds per token, so a one-sentence answer takes around 30 minutes. That excludes the first run's one-off download, which at the 26MB/s I saw from Hugging Face would take more than an hour on its own, plus the time to split the model.

On a 16GB Mac mini, AirLLM turned Llama 3.1 8B into a 19.6 second per word model. The same model loaded fully into memory answers in real time.

AirLLM vs just running a smaller model properly

Any setup that fits the model in memory beats AirLLM by two to three orders of magnitude, so AirLLM only makes sense for models you cannot fit any other way. My numbers above are measured; the comparisons below are estimates from memory bandwidth and published reviews of similar machines.

The same Mac mini with Ollama. An 8B model at 4-bit uses about 5GB and fits comfortably in 16GB. Reviews of 16GB Macs put models like Qwen 3 8B and Qwen 3.5 9B at roughly 25 to 30 tokens per second. That is about 500 times faster than the 19.6 seconds per token I measured through AirLLM. Most of that gap is AirLLM reading full-precision weights from disk instead of 4-bit weights from memory.

An old many-core server with lots of RAM. A 64-core DDR3 server with 128GB of RAM can hold a 4-bit 70B model (about 40GB) entirely in memory and run it with llama.cpp. Old memory and older CPUs make it slow by modern standards, roughly 0.3 to 1 token per second, but that is still a few hundred times faster than AirLLM streaming the same model off a USB drive.

A Mac with more memory. Apple's current line goes to 32GB on the Mac mini M6, 64GB on the Mac mini M5 Pro, and 128GB on the Mac Studio M5 Max. 64GB is the minimum for a 4-bit 70B model to fit in memory, and it is a tight fit once macOS takes its share; 128GB is comfortable. At that point you would not use AirLLM at all.

If you are a founder weighing local models against an API for your product, this is exactly the kind of decision I help with as a fractional CTO: the answer depends on your latency budget, your data constraints, and what the hardware costs per month next to your API bill, not on what a README says.

When AirLLM is actually worth using

Use AirLLM when you need a model much larger than your memory, can wait minutes per word, and can run the work in batches or overnight; skip it whenever the model already fits. Here is how I would decide.

Good fit: offline batch jobs, such as classifying or summarizing a few hundred documents overnight with a 70B model on a machine that otherwise could not run one. Also good for evaluating a big model's quality on your own prompts before paying for hardware or API capacity.
Bad fit: anything interactive. Chat, coding assistants, and agents need tokens per second, not minutes per token.
Buy disk speed first. Because AirLLM is disk-bound, a Thunderbolt or USB4 NVMe drive at about 3GB/s should roughly triple its speed over the USB drive I used. On a fast internal SSD it would be faster still, if you have the space.
Budget twice the model size in free disk. For 70B, that is around 300GB.
Expect to maintain it. The library has not had a release since 2024. On a Mac, plan to patch it as I did, and test output quality, not just whether it runs.

For everyday local use on a 16GB Mac, I would run an 8B to 12B model at 4-bit through Ollama or LM Studio and keep AirLLM for the occasional giant-model experiment. If your team is building AI features and you want a second opinion on model choice, hosting, or cost, a technical advisor engagement or CTO as a service covers exactly this. My notes on AI startup technical due diligence also cover the infrastructure questions investors ask about model hosting.

Frequently asked questions

Can AirLLM really run a 70B model on 4GB of memory? Yes. It loads one layer at a time from disk, so peak memory stays at a few gigabytes. The trade-off is speed: the whole model is read from disk for every token, so a 70B model runs at minutes per token on a typical consumer SSD.

How fast is AirLLM on a Mac? On a base M4 Mac mini with an external USB SSD, I measured 1.0 second per token for TinyLlama 1.1B and 19.6 seconds per token for Llama 3.1 8B. A 70B model projects to two and a half to three minutes per token on the same setup.

Does AirLLM work on Apple Silicon? Yes, through Apple's MLX library, but it needed four fixes in my test, including a patch without which Llama 3.x models produce garbled output. Its compression options do not work on a Mac because they depend on an NVIDIA-only library.

How much disk space does AirLLM need? About twice the model's size, because it keeps the original download and a split copy with one file per layer. A 70B model needs roughly 300GB free.

Is AirLLM better than Ollama? Only for models that do not fit in your memory. For any model that fits, Ollama or llama.cpp is hundreds of times faster, because the weights stay in memory and run at 4-bit precision.

What is the best local model for a 16GB Mac? An 8B to 12B model at 4-bit, such as Qwen 3 8B, Qwen 3.5 9B, or Gemma 4 12B, run through Ollama or LM Studio. Larger models load but leave too little memory for longer conversations.

If you are deciding between running models yourself and paying for an API, book a 30-minute call and walk me through your workload. I will tell you what I would run, where, and what it should cost.

The DPDP Act, Explained by a Security Researcher: Why India Needed It and What It Means for Your Stack

Kunal Vohra — Thu, 01 Oct 2026 12:00:00 +0000

The Digital Personal Data Protection Act, 2023 (the DPDP Act) is India's first dedicated law for personal data. It gives people rights over their data, makes every company that collects it accountable for how it is used and protected, and sets up a Data Protection Board with the power to impose penalties of up to ₹250 crore. The DPDP Rules, notified in November 2025, phase the obligations in over 18 months, with the core duties (security safeguards, breach reporting, notices, retention) applying by May 2027.

Most explainers treat the DPDP Act as a consent law. I read it as a security engineer, because that is what I am: I hold an M.Tech in Cybersecurity from NIT Kurukshetra, my research on attribute-based access control has been cited 30+ times, and I have built products on Indian infrastructure as a six-time technical co-founder. From that angle the Act says something founders miss: India has decided that losing people's data is a bigger failure than collecting it without asking.

I am not a lawyer, and this is not legal advice. It is how the law translates into engineering work. For your specific obligations, talk to a privacy lawyer; for how to build them into your product, that is where I come in.

Why India needed a data protection law

India needed the DPDP Act because it had become one of the largest digital economies in the world while protecting personal data with rules written in 2011 that covered only a narrow slice of data and had no dedicated regulator. The gap between how much data Indian companies held and how little they were accountable for kept widening.

Before the Act, the legal baseline was Section 43A of the IT Act and the 2011 "SPDI" rules. They applied mainly to a short list of "sensitive" data (passwords, financial and health information, biometrics), asked for "reasonable security practices" without saying much about what that meant, and left individuals to pursue compensation through a slow adjudication process. There was no duty to tell people their data had been breached, no general right to have your data deleted, and no regulator whose job was personal data.

Three things made that untenable.

Privacy became a fundamental right. In 2017 a nine-judge bench of the Supreme Court held in Justice K.S. Puttaswamy v. Union of India that privacy is a fundamental right under the Constitution, and noted that the state should put a data protection framework in place. What followed was six years of drafting: the Justice Srikrishna committee report in 2018, the Personal Data Protection Bill of 2019, its withdrawal in 2022, and finally the much shorter DPDP Act, passed in August 2023.

India's digital public infrastructure put everyone's data online at once. Aadhaar, UPI, DigiLocker, and the account aggregator framework moved hundreds of millions of people into digital identity and payments within a few years. That is a remarkable achievement, and it also means that for most Indians, a large share of their life now exists as records in databases they have never seen, run by companies they have never heard of.

Breaches kept happening, and nobody had to tell you. The ransomware attack on AIIMS Delhi in late 2022 took one of the country's largest hospitals back to paper records for days. In 2023, reports surfaced of personal details linked to the CoWIN vaccination platform being served through a Telegram bot. Digital lending apps that took contact-list access and used it to harass borrowers and their families became a problem big enough for the RBI to issue specific guidelines. Under the old regime, in most of these situations, the affected people had no legal right to be told what had happened to their data.

Why the DPDP Act is a security law, not just a privacy law

Read the penalty schedule and the priorities are clear: the largest penalty in the Act, up to ₹250 crore, is for failing to take reasonable security safeguards to prevent a personal data breach. Failing to notify a breach, and failing to meet the obligations around children's data, can each cost up to ₹200 crore. Most other violations are capped at ₹50 crore.

The biggest fine in India's data protection law is not for collecting data without consent. It is for failing to protect it.

That ordering matters for how you prioritise engineering work. A missing consent checkbox is a problem. An unencrypted database behind a shared admin password is a much bigger one, and the Act prices it that way.

As a security researcher, three ideas in the Act matter more to me than the rest.

Data minimisation shrinks the blast radius. The Act ties processing to a specified purpose and expects data to be erased when that purpose is served. Every field you do not collect is a field that cannot leak. This is the cheapest security control there is, and the law now makes it mandatory rather than advisable.
Accountability follows the data, including to your vendors. The data fiduciary (the company that decides why and how data is processed) is responsible even when a processor (your cloud host, your SMS provider, your analytics tool, your model provider) handles the data. You cannot outsource the liability, only the work.
Breaches become visible. Mandatory notification to the Board and to affected people changes the incentive. Companies that could previously absorb a breach quietly now have to disclose it, which makes prevention a business decision rather than an engineering nice-to-have.

What the DPDP Rules actually require from engineering

The DPDP Rules turn the Act's broad duties into concrete technical requirements: specific security safeguards, a breach reporting process with a 72-hour deadline, logs kept for at least a year, erasure with advance notice, and verifiable parental consent for children. Here is how the main rules translate into work on your stack.

Reasonable security safeguards (Rule 6). The rules list the measures expected at minimum: protecting personal data through encryption, obfuscation, masking, or virtual tokens; access controls over the systems that process it; visibility into access through logs and monitoring so that unauthorised access can be detected and investigated; retaining those logs for at least a year; backups and measures for continuity if data is compromised; and contracts that require your processors to take safeguards too. If you have read my startup security checklist, most of this will look familiar, because it is the same baseline, now with legal weight behind it.

Breach intimation (Rule 7). When a personal data breach happens, you must inform each affected person without delay, in plain language, explaining what happened, the likely consequences, what you are doing about it, what they can do to protect themselves, and who to contact. You must also inform the Data Protection Board without delay, followed by a detailed report within 72 hours covering the facts, the cause, the mitigation, and the notifications you have sent. This sits alongside the existing CERT-In directions, which already require cyber incidents to be reported to CERT-In within six hours. In practice that means one incident process with three clocks.

Retention and erasure (Rule 8). Personal data must be erased once the purpose is served or consent is withdrawn, unless the law requires you to keep it. Large e-commerce, gaming, and social media platforms get defined retention periods after a user's last activity, and people must be told at least 48 hours before their data is erased so they can log in and keep their account. Separately, logs of processing must be retained for at least a year. Engineering takeaway: you need to know where every copy of a person's data lives, including backups, analytics, and logs, or you cannot erase it.

Children's data. Anyone under 18 is a child under the Act, and processing their data needs verifiable consent from a parent or guardian, with limited exemptions such as healthcare and education providers acting within their role. Tracking, behavioural monitoring, and targeted advertising directed at children are prohibited. For edtech, gaming, and consumer apps, this is an onboarding and identity problem, not a checkbox.

Consent notices and Consent Managers. Notices must be clear, standalone, and itemised, telling people what data you collect and for what purpose, and consent must be as easy to withdraw as it was to give. Consent Managers, India-based entities registered with the Board, will let people give, manage, and withdraw consent across services from one place. Their registration regime starts in November 2026, a year after the Rules were notified.

Significant Data Fiduciaries. Companies the government notifies as Significant Data Fiduciaries (based on the volume and sensitivity of data, and risk to people and the state) carry more: a Data Protection Officer based in India, an independent data auditor, periodic data protection impact assessments and audits, and due diligence that the algorithms and software they use do not put people's rights at risk. The government can also restrict certain categories of their data from leaving India.

The timeline: what applies when

The Rules were notified in November 2025 and phase in over 18 months.

November 2025: the Data Protection Board provisions took effect, so the enforcement machinery could be set up.
November 2026 (next month, as I write this): the Consent Manager registration regime begins.
May 2027: the core obligations apply, including notices, consent, security safeguards, breach intimation, retention and erasure, children's data, and data principal rights.

MeitY has also consulted on bringing some of these dates forward, particularly for Significant Data Fiduciaries. Treat May 2027 as the latest possible date, not the planning target. Retrofitting encryption, logging, erasure, and a breach process into a live product takes months, and the calendar is shorter than it looks.

Where the DPDP Act is weaker, and the criticisms worth knowing

The Act is a big step forward, but it is not the strongest data protection law in the world, and a fair reading has to include its gaps. These are the criticisms I hear most often from privacy researchers and practitioners; you do not have to agree with all of them to plan around them.

Broad government exemptions. Section 17 lets the central government exempt its own agencies from the Act on grounds such as national security and public order. Critics argue this is too wide; the government's position is that it mirrors exemptions found in other data protection laws.
"Reasonable" is not defined in depth. Rule 6 lists categories of safeguards but not standards. That flexibility helps startups, and it also means there is no clear bar until the Board starts deciding cases.
No compensation for individuals. Penalties go to the government, not to the people whose data was breached. Earlier drafts had a compensation route; the final Act does not.
Board independence. Members of the Data Protection Board are appointed by the central government, which critics say limits its independence when the government itself is the data fiduciary.
No separate category for sensitive data. Unlike GDPR and the earlier Indian drafts, the Act treats health, financial, and biometric data under the same general rules as everything else, apart from children's data and Significant Data Fiduciaries.
The RTI amendment. The Act amended the Right to Information Act in a way transparency advocates say makes it easier to refuse information that involves personal data.

From a security perspective, the practical upshot is simple. Do not build to the weakest reading of the law. Build to the baseline a competent auditor would expect, because that is what the Board will eventually use to judge "reasonable."

What Indian startups should build before May 2027

If you process personal data of people in India, the DPDP Act applies to you, whatever your size, and it also applies to companies outside India that offer goods or services to people in India. The Act lets the government exempt notified startups and classes of companies from some obligations, but no startup should plan its security around an exemption that may never cover it. Here is the order I would work in.

Map your personal data. What you collect, why, where it is stored (including backups, logs, analytics, and third-party tools), and who can access it. Every other obligation depends on this document.
Cut what you do not need. Remove fields, stop logging personal data you never use, and set retention periods. Less data is less risk and less compliance work.
Put the Rule 6 baseline in place. Encryption at rest and in transit, access control with one identity per person and MFA, logging and monitoring retained for at least a year, tested backups, and security clauses in your processor contracts.
Build the rights workflows. Access, correction, erasure (with the 48-hour notice where it applies), consent withdrawal, and a grievance contact, all working end to end rather than handled by email.
Write the breach process now. One runbook covering CERT-In's six hours, the Board's 72 hours, and plain-language notices to affected users, with named owners.
Rewrite your consent notices so they are itemised, specific, and available in the languages your users actually use.
Handle children properly if there is any chance minors use your product: age signals, verifiable parental consent, and no tracking or targeted ads.
Check your AI stack. If you send personal data to an LLM provider, you are using a processor. Know what you send, whether it is retained, and where it is processed, and keep personal data out of prompts and prompt logs unless the feature needs it.

If you are also regulated elsewhere, DPDP stacks on top: RBI rules for payments and lending (covered on my fractional CTO for fintech page), health data expectations (see fractional CTO for healthcare), and GDPR if you serve users in Europe.

Who should own DPDP compliance at a startup

DPDP compliance is split between legal and engineering, and at most startups the engineering half is the larger one. A lawyer can write your notices and review your contracts. Someone technical has to build the data map, the encryption, the logging, the erasure path, and the breach process, and keep them working as the product changes.

That is part of the work I do as a fractional CTO in India, for Indian founders and for foreign founders building products for Indian users: designing these obligations into the architecture from the start, or retrofitting them before they turn into a funding diligence problem. If you only need a periodic review of your design decisions, the technical advisor engagement covers that; if you need someone accountable for the work, that is a fractional CTO engagement.

Frequently asked questions

Why was the DPDP Act introduced? Because India's previous framework, Section 43A of the IT Act and the 2011 SPDI rules, covered only a narrow set of sensitive data, had no dedicated regulator, and did not require companies to tell people about breaches. The Supreme Court's 2017 Puttaswamy judgment recognised privacy as a fundamental right, and the scale of India's digital economy and repeated large breaches made a comprehensive law necessary.

When does the DPDP Act come into force for businesses? The DPDP Rules were notified in November 2025 with an 18-month phase-in. The Data Protection Board provisions applied immediately, the Consent Manager regime starts in November 2026, and the core obligations, including security safeguards and breach notification, apply by May 2027. The government has consulted on bringing some dates forward, so check the latest notifications.

What is the maximum penalty under the DPDP Act? Up to ₹250 crore for failing to take reasonable security safeguards to prevent a personal data breach. Failing to notify a breach and breaching children's data obligations can each cost up to ₹200 crore, and most other violations up to ₹50 crore.

What security measures does the DPDP Act require? Rule 6 of the DPDP Rules expects encryption, obfuscation, masking, or tokenisation of personal data; access controls; logging and monitoring to detect unauthorised access; retention of logs for at least a year; backups and continuity measures; and contracts requiring processors to take safeguards. It does not name specific standards, so build to what a competent auditor would expect.

How fast do you have to report a data breach under DPDP? You must inform affected individuals and the Data Protection Board without delay, and send the Board a detailed report within 72 hours. Separately, CERT-In's directions require cyber incidents to be reported to CERT-In within six hours.

Does the DPDP Act apply to startups and companies outside India? Yes. It applies to any organisation processing digital personal data in India, and to organisations outside India that process personal data in connection with offering goods or services to people in India. The government can exempt notified startups from some obligations, but security safeguards and breach notification are not the place to rely on that.

If you are building for Indian users and want a straight read on how far your product is from DPDP-ready, book a 30-minute call and walk me through your stack. I will tell you what I would fix first.

Startup Security Checklist: What I Fix First as a Fractional CTO (2026)

Kunal Vohra — Thu, 01 Oct 2026 12:00:00 +0000

A startup security checklist does not need to be long to be useful. It needs to be in the right order. Before seed, the risks that actually hurt you are boring: shared logins, secrets in code, cloud accounts with no guardrails, backups nobody has restored, and (if you are building with AI) a model that can reach things it should not. Fix those first, in that order, and you are ahead of most companies your size. Leave SOC 2, pen tests, and security tooling budgets until a customer or an investor gives you a reason.

I hold an M.Tech in Cybersecurity from NIT Kurukshetra, I have published research on access control that has been cited 30+ times, and I have been the technical co-founder or CTO of six startups. The pattern I keep seeing is the same one: founders either ignore security until an enterprise deal forces it, or they buy tools before they have fixed the basics. This checklist is the order I actually work in when I take over the security posture of a startup as its fractional CTO.

Why startup security is mostly about the boring things

Early-stage startups rarely get breached by sophisticated attacks; they get breached through access and configuration mistakes that take minutes to exploit and hours to fix. Attackers automate the search for exposed keys, open storage buckets, and default credentials. They are not targeting you specifically. They are scanning everyone, and small companies with no process are the easiest wins.

The hard part of startup security is not knowing what to do. It is doing it before you feel you need to, while the team is small enough that a fix takes an afternoon instead of a quarter.

The line that nearly took down a launch processing 500,000 assessments in an hour was not in the AI, the custom protocols, or the operating system we built from zero. It was one line of AWS load balancer configuration.

I wrote about that near-miss in the edtech case study. It is the most useful security lesson I can give a founder: the risk is usually in the layer everyone thinks is too simple to review.

Week one: identity and access

The first thing to fix is who can log in to what, because every other control assumes this is right. If three people share one admin account, you cannot audit anything, you cannot offboard anyone, and a single phished password is a full compromise.

One identity per person, everywhere. No shared logins for the cloud console, the domain registrar, the app stores, the payment processor, or the production database. If a tool only allows one account, put it in the password manager and log who uses it.
MFA on everything that matters, starting with email, cloud, code hosting, DNS, and payments. Prefer an authenticator app or hardware key over SMS.
A company password manager, not browser-saved passwords on personal laptops.
Lock away the cloud root account. Root credentials go into the password manager with MFA, and nobody uses them day to day.
Least privilege by default. Engineers get the access their current work needs. Production write access is a short list you can read out loud.
An offboarding checklist that actually runs. When someone leaves, every account is revoked the same day. Contractors and agencies are where this breaks most often.

None of this costs money beyond a password manager seat. All of it is painful to retrofit once you have twenty people and forty tools.

Secrets and credentials: keep them out of the code

API keys, database passwords, and tokens belong in a secrets manager or environment configuration, never in the repository, and never in a chat message. Once a secret has been committed, assume it is compromised, even if the repo is private; the fix is rotation, not deletion.

Turn on secret scanning in your code host and add a pre-commit hook so keys never reach the repo in the first place.
Use separate keys for development, staging, and production. A developer laptop should never hold production credentials.
Scope every key to what it needs. A payment key that can only create charges is a very different incident from one that can issue refunds and read customer data.
Keep a list of every third-party key and who owns it, and rotate them on a schedule and whenever someone with access leaves.

This matters twice as much for AI products, because model provider keys are billed per use. A leaked key is not only a data risk; it is an invoice.

Cloud and infrastructure: guardrails, backups, and logs

Your cloud setup should be defined in code, reviewed like code, backed up in a way you have actually tested, and logged well enough to answer "what happened" after an incident. Most startups have one of these four, and it is rarely the tested backup.

Infrastructure as code (Terraform, Pulumi, CloudFormation, whatever your team knows). Changes go through review, which is exactly what would have caught the load balancer line earlier.
No public storage by default. Buckets, databases, and admin panels should not be reachable from the internet unless there is a written reason.
Backups with a tested restore. A backup you have never restored is a hope, not a backup. Restore to a scratch environment at least once a quarter and time it.
Centralised logs and basic alerting for logins, permission changes, and unusual spend. You do not need a security operations centre. You need to know when something changes.
Patching and dependency updates on a schedule, not when someone remembers.
Separate environments. Production data does not get copied into staging for convenience, especially if it contains personal or health data.

Application security basics every MVP should ship with

Most web application vulnerabilities come from a short, well-known list: broken access control, injection, weak authentication, and outdated dependencies. The OWASP Top 10 is still the right reference, and an MVP that handles those well is ahead of most production software.

Authorisation checks on the server for every request, not only hidden buttons in the UI. The most common serious bug I see in early products is one user being able to read another user's data by changing an ID in a URL.
Parameterised queries and an ORM instead of string-built SQL.
Rate limiting on login, signup, password reset, OTP, and any endpoint that costs you money (which, for AI features, is most of them).
Dependency scanning in CI, with someone responsible for acting on the results.
Security headers, HTTPS everywhere, and secure cookie settings, which are mostly one-time configuration.
Continuous external scanning of what is exposed to the internet. At ColadAI I built SiteGuard for exactly this: automated web and API security checks that run between audits, so a new exposure shows up in days rather than at the next pen test.

If you are scoping an MVP right now, put these in the scope, not in a "phase two" nobody funds. It is part of how I approach MVP development, and it costs far less on day one than after launch.

Security for AI startups: the checklist most founders skip

If your product sends user data to a model or lets a model take actions, you have a new attack surface that the standard checklist does not cover. AI-first startups need a few extra items, and investors doing technical due diligence on AI startups now ask about them directly.

Treat every model input as untrusted. Prompt injection means text in a document, email, web page, or user message can steer the model. The model's own instructions are not a security boundary. I covered the mechanics in Prompt Injection Attacks Explained.
Scope tool access tightly. If an agent can call APIs, query a database, or send email, give it its own credentials with the minimum permissions, and require a human confirmation for anything destructive or financial.
Know where your data goes. For every model provider in the stack, write down what you send, whether it is retained, whether it can be used for training, and which region it is processed in. Enterprise buyers will ask for this in writing.
Keep personal data out of prompts and logs unless the feature genuinely needs it. Prompt logs are one of the most common places sensitive data ends up by accident.
Separate tenants in retrieval. If you use RAG, make sure one customer's documents can never be retrieved into another customer's answer. Filter on the server, not in the prompt.
Put spend limits on model keys. Abuse of an AI endpoint often shows up first as a bill.

I build and run ColadAI, a multi-LLM platform, so these are the same decisions I make on my own products before I recommend them to anyone else. For a wider view of how attackers are using AI, see Can AI Hack Systems?.

Data protection and compliance: HIPAA, DPDP, GDPR, and SOC 2 for startups

Compliance should follow your data and your customers, not a generic roadmap. Start by mapping what personal data you collect, where it is stored, and which vendors touch it. That single document answers half of every security questionnaire you will ever receive.

Health data in the US brings HIPAA, and every vendor that touches protected health information needs a BAA. On one engagement a signed enterprise pilot stalled in security review because PHI was flowing into three vendor systems with no BAA and no audit trail. Redrawing the data boundary, removing PHI from everything that did not need it, and adding immutable access logging took six weeks, and the deal closed. The same work after a failed audit would have cost the deal. That is the kind of work behind the fractional CTO for healthcare page.
Indian users bring the DPDP Act; European users bring GDPR; payments bring PCI DSS (which you mostly avoid by never touching raw card data and using a processor's hosted fields). Fintech has its own layer on top, covered on the fractional CTO for fintech page.
SOC 2 is a sales requirement, not a security milestone. Pursue it when enterprise customers ask for it in real deals. Doing the checklist above first makes the audit far faster, because most SOC 2 controls are the same basics with evidence attached.

Incident readiness: decide before you need it

Every startup should have a one-page incident plan before its first incident, because the worst time to decide who is in charge is during one. It does not need to be elaborate.

Who leads an incident, and who is the backup.
How to revoke access and rotate keys quickly, with the steps written down.
Who needs to be told (customers, regulators, investors) and within what time frame for your markets.
Where logs live and how long they are kept.
A short review afterwards, focused on what to change, not who to blame.

Who should own security at a startup

Before you can justify a full-time security hire, security should be owned by whoever owns the architecture, which at most early-stage startups means the CTO or, if you do not have one, a fractional CTO. A security consultant can audit you once; someone has to own the fixes and keep the standard as the team grows.

Security and infrastructure posture is one of the five areas I own in a fractional CTO engagement, alongside architecture, hiring, vendor oversight, and investor diligence. If you only need a periodic review of architecture and security decisions, the Technical Advisor tier is $750 a month; if you need someone to own the work, the Fractional CTO retainer is $2,500 a month. Full details are on the fractional CTO pricing page, and the CTO as a service page explains how the retainers differ.

Frequently asked questions

What should be on a startup security checklist before launch? At minimum: one account per person with MFA, a password manager, no secrets in the repository, least-privilege cloud access with the root account locked away, tested backups, server-side authorisation on every request, rate limiting, dependency scanning, and a one-page incident plan. AI products should add untrusted-input handling, scoped tool permissions, and a written record of what data goes to which model provider.

When does a startup need SOC 2? When enterprise customers ask for it in active deals, usually around the time you start selling to mid-market or larger companies. Before that, the same money is better spent fixing the basics, which also makes the eventual audit faster.

Do early-stage startups need a penetration test? Not before the basics are in place. A pen test on a product with shared admin logins and keys in the repo mostly confirms what a checklist would have told you for free. Once the basics are done and you have customers asking, a scoped test is worth it.

How is security different for AI startups? AI products add three risks the standard checklist misses: prompt injection through untrusted content, models or agents with more access than they need, and sensitive data flowing to model providers or into prompt logs. Each has a concrete fix, and investors increasingly ask about all three.

Can a fractional CTO handle security, or do I need a security specialist? For most startups before Series A, a fractional CTO with a security background can own the posture, fix the basics, and prepare for questionnaires and audits. A dedicated security hire makes sense once you are regulated at scale or security is a core part of what you sell.

If you want a straight read on where your product stands, book a 30-minute call and walk me through your stack. I will tell you the three things I would fix first, whether or not we end up working together.

How to Hire a CTO for Your Startup (From Someone Who Has Been Hired as One Six Times)

Kunal Vohra — Thu, 24 Sep 2026 12:00:00 +0000

To hire a CTO for your startup, decide first which shape of CTO you actually need (technical co-founder, full-time hire, fractional CTO, or interim CTO), then find candidates through your investors and your engineers rather than job boards, evaluate them on systems they have built and broken rather than on a whiteboard, and pay with a mix of cash and equity that matches the stage. Most founders skip the first step and pay for it for two years.

I have been the technical co-founder six times, I have been hired as a fractional and interim CTO by founders who could not evaluate me, and I have sat on the other side of the table hiring engineers and my own replacements. This is the process I wish someone had handed me the first time. It is written for a non-technical founder, but a technical one will recognise most of it.

Step 1: Decide whether you need a CTO at all

The honest test is whether technical leadership has become a job or is still a set of decisions. If you have no product, no engineers, and no code, you do not need a CTO yet; you need the product to exist, which is a build problem, not a leadership one. If you have an agency shipping an MVP, you need someone senior to check their work, which is an advisory problem. A CTO becomes necessary when there is a team to lead, an architecture to own, and a roadmap someone has to be accountable for.

The rough line I use: below three engineers, a technical advisor or a fractional CTO covers it. Between three and eight, a fractional CTO two or three days a week is usually right. Past eight engineers and a funded roadmap, technical leadership is a full-time job, and hiring it part-time makes the leader the bottleneck every decision queues behind. I have written the fractional versus full-time comparison in more detail, but that line is the short version.

One stat line worth keeping: a full-time startup CTO in the US costs roughly $260,000 a year fully loaded before equity. Hiring one two years early is a half-million-dollar mistake before you count the rewrite they will start to justify the seniority.

Step 2: Choose the shape before you choose the person

"Hire a CTO" hides four different decisions. Pick the shape first, because the search, the evaluation, and the compensation are different for each.

Technical co-founder. Fits when you are pre-product and pre-funding and the company does not exist without them. Costs 10 to 50 percent equity and little or no cash. Ends never, ideally.

Full-time CTO. Fits past Series A, with eight or more engineers, when leadership is a full-time job. Costs about $260k a year plus 1 to 4 percent equity. Ends with an exit, or a hard conversation.

Fractional CTO. Fits a funded company with three to eight engineers that needs senior ownership two or three days a week. Costs $2,500 to $15,000 a month across the market, no equity by default. Ends when you outgrow it and hire full-time.

Interim CTO. Fits when your CTO left, the product is stuck, or a raise is weeks away. Near full-time for three to nine months. Ends with your permanent CTO hired, often by the interim.

If you are pre-product and want a partner, the technical co-founder guide is the one to read, and the equity split post covers what to offer. The rest of this article assumes you are hiring, not partnering.

Step 3: Write the job for the role you have, not the title

Most CTO job descriptions are copied from a company ten times the size. They ask for someone who has scaled to millions of users, managed fifty engineers, and set a multi-year platform strategy, and then they hand that person a team of four and a product that needs to ship by March. The senior candidate reads the description, joins, and spends the first quarter building the org chart the description promised.

Answer three questions before you write anything:

What has to be true in twelve months? Shipped features, a hired team, a security certification, a platform that survives ten times the load. The CTO's job is whichever of those the company cannot get without them.
Hands on the keyboard or not? With fewer than six engineers, a CTO who does not write code is a manager without enough people to manage. Say explicitly whether you expect them to build.
What is the one thing that breaks if nobody senior is in the room? That sentence is the job description. Everything else is a nice-to-have.

Write the description in that order: outcomes, then hands-on expectation, then the one thing. Leave the ten-year-experience laundry list out. The right person will recognise the job; the wrong one will self-select out.

Step 4: Where to actually find a CTO

Job boards are the worst place to find a CTO and the first place most founders look. Senior technical leaders are almost never actively applying; the good ones are pulled, not pushed. In rough order of how often it works:

Your investors. Every fund keeps an informal list of technical leaders between roles or looking for their next thing. Ask for introductions, not for a list. A warm intro from a partner who has backed the person before is the single highest-quality source I know of.

Your engineers' networks. Your best engineer has worked for somebody they still respect. Ask them, specifically: who is the best technical leader you have ever reported to, and are they reachable? Engineers rarely volunteer this and almost always have an answer.

Founders who have exited. Their former CTOs are often available, well-referenced, and looking for something earlier-stage than a big-company role. Founder communities and your investors' portfolios are where these introductions come from.

Fractional first. Engaging a fractional CTO for three to six months is the lowest-risk way to hire a full-time one: you see the person under load before any equity conversation, and many fractional engagements convert. Even when they do not, a good fractional CTO will define the full-time role properly and help you interview for it. That is a large part of what I do in interim engagements.

Executive search. Retained CTO recruiters charge around a third of first-year compensation and are worth it above Series B, when the role is well-defined and the pool is global. Below that, they tend to send you the copied job description's candidates.

Communities and events. Slower, but real. Technical meetups, open-source maintainers in your stack, conference speakers on the exact problem you have. If someone has spent three years talking publicly about the thing your product needs, they are a better lead than a CV.

Step 5: How to evaluate a CTO when you cannot evaluate their code

This is the step non-technical founders lose sleep over, and the good news is that the most predictive signals are not technical. I have written a full CTO interview question bank, but the five tests below are the ones that decide it.

1. "Walk me through a system you built, and what broke." Every real system has broken. A candidate who describes a failure, what it cost, what they changed, and what they would do differently is telling you how they will behave when your system breaks. A candidate who has only stories of success has either not built much or is not going to tell you the truth later.

2. "What would you change in our codebase in the first thirty days?" Give them read access to the repository for a week before the final interview. A senior person will come back with three specific things, ranked, and at least one of them will be "nothing yet, I need to understand why it was done this way." A junior person will come back with a rewrite.

3. Reference calls with engineers who reported to them. Not their peers, not their CEO: the people they managed. Ask one question: would you work for this person again, and why? The pause before the answer is the data.

4. A paid trial project. Two to four weeks, a real problem, real money. This is the only way to see how someone works with your actual team, and any candidate who is offended by the idea has told you something useful. Fractional engagements are essentially this, extended.

5. How they handle "I don't know." Ask something at the edge of their expertise. The best technical leaders say "I don't know, here is how I would find out" within a sentence. The worst ones bluff, and a CTO who bluffs to you will bluff to investors and customers.

Whiteboard algorithm interviews, take-home coding tests, and system-design puzzles tell you almost nothing at this level. The person is going to hire engineers, make architecture calls, and represent you to investors; test for those.

Step 6: What to pay a startup CTO

Compensation is the part founders get most wrong in both directions: too much equity to a hire who joins post-funding, or too little cash to someone they expect to work like a co-founder. Rough shape, US market, mid-2026:

Full-time CTO, seed to Series A: salary typically in the $180,000 to $260,000 range depending on city and how much the person is taking below market, plus 1 to 4 percent equity on a four-year vest with a one-year cliff. Earlier stage and lower salary push the equity up; later stage and market salary push it down.
Full-time CTO, Series B and later: market salary, equity usually under 1 percent, and the equity is negotiated against the last round's valuation rather than a percentage.
Fractional CTO: monthly retainers run $4,000 to $15,000 across the market for two to three days a week. My own tiers are published and lower than that, held through December 2026. No equity by default; a cash and equity mix is possible when a founder prefers it.
Technical co-founder: this is not a hire and should not be paid like one; the equity split post covers it.

Two rules. First, vesting always, including for a co-founder, including for someone you have known for a decade. Second, never trade equity for a discount on a fractional retainer unless you expect the person to still be around in four years; equity is the most expensive currency you have, and a retainer is the cheapest.

Step 7: The offer and the first ninety days

Make the offer in writing with the outcomes from Step 3 attached. The best CTO hires I have seen started with a one-page document that said: here is what we need true in twelve months, here is what you own, here is what you do not own, here is how we will know it is working at ninety days. It prevents the two most common failures: a CTO who builds a platform nobody asked for, and a founder who keeps making technical decisions behind their new CTO's back.

Then get out of the way for the first month, with one exception: the ninety-day check-in you agreed to in the offer. If the outcomes are visibly on track, you hired well. If the CTO has spent ninety days on a reorganisation or a rewrite that was not in the document, you have your answer early, which is the whole point of writing it down.

Red flags, briefly

A CTO candidate who wants a title and a team before there is work for either.
No failure stories, or failure stories in which nothing was their fault.
A rewrite proposed before they have read the code.
Unwillingness to do a paid trial or to give engineer references.
Equity demands calibrated to a co-founder when they are joining after the money.
Fluency in the current framework and silence on what happens when it breaks at 2 a.m.

Frequently asked questions

How much does it cost to hire a CTO? A full-time startup CTO in the US runs about $260,000 a year fully loaded before equity, and a retained search adds roughly a third of that once. A fractional CTO runs $4,000 to $15,000 a month across the market, with no equity and no search fee. The cheaper option is almost always the right one until you have eight or more engineers.

How long does it take to hire a CTO? A full-time search through investors and networks typically takes four to six months from the decision to the start date. A fractional or interim engagement can start within a week or two, which is why many founders use one as the bridge while they search.

Can a non-technical founder hire a CTO? Yes, and the five tests above are designed for exactly that. The mistake is trying to evaluate code; evaluate judgment, failure stories, references from engineers, and behaviour on a paid trial instead. A fractional CTO can also run the technical side of the search for you.

Are CTO recruitment services worth it for a startup? Above Series B, usually. Below it, the fee is high relative to the round and the candidates tend to be optimised for the job description rather than the company. Investor and engineer introductions are cheaper and better at early stage.

Should a startup CTO get equity? A full-time CTO joining after funding, yes, typically 1 to 4 percent vesting over four years. A fractional CTO, not by default. A technical co-founder is a different question entirely and is answered in the equity split post.

What is the difference between hiring a CTO and finding a technical co-founder? A co-founder joins before the money, shares the risk, and earns a large equity stake for it. A CTO is hired after there is a company to run, is paid mostly in cash, and gets a small equity stake to align incentives. Founders who try to hire a CTO on co-founder terms, or find a co-founder on hire terms, usually end up with neither.

If you are in the middle of this decision, book a call and describe where the company is. I will tell you which shape you need, and if the answer is a full-time hire I will help you write the role and interview for it rather than sell you a retainer. If the answer is fractional or interim, the fractional CTO page and the interim CTO page describe how each engagement runs, with the pricing published.

Technical Co-Founder Equity Splits: What's Fair in 2026

Kunal Vohra — Tue, 22 Sep 2026 12:00:00 +0000

If you are pre-product and pre-revenue, and a technical co-founder is going to build the entire product while you handle everything else full time, the defensible range is 40 to 50 percent of the founder pool. The more evidence you bring to the table, in revenue, committed funding, a real domain moat, or a full-time head start measured in years rather than weeks, the further the split can tilt toward you, into the 55/45 to 70/30 zone.

That is the whole answer. Everything below is about how you get to a number inside those ranges, and how to structure it so nobody is quietly furious in month fourteen.

I have been the technical co-founder six times, across three continents, and I have turned the offer down far more often than I have taken it. I have also been on the other side, watching a split I was not part of poison a company that the market was actively trying to keep alive. So this is written from the negotiating table rather than from a template. The longer piece on how to find a technical co-founder covers the search itself; this one is only about the equity.

The short answer, by stage

The single biggest input is what exists on the day the conversation happens. Roughly:

Idea only, nothing built, no revenue, no funding. Near-equal, 40 to 50 percent of the founder pool. You are asking someone to create the entire product from nothing, on the same risk you are taking. There is very little to justify a large gap.
A prototype exists, built by contractors or by you. 35 to 45 percent. A prototype is evidence, and it reduces the unknowns the technical co-founder is absorbing. It rarely survives contact with production, so discount it accordingly.
Real revenue or committed funding. 25 to 40 percent. Money already on the table changes the risk profile genuinely, and a rational technical co-founder will price that in.
Established company hiring a technical leader. This is not a co-founder conversation any more. It is an executive hire, typically low single digits of the company post-funding, and calling it a co-founder role to justify a below-market salary is a tactic engineers recognise immediately.

These are ranges, not a formula. Anyone selling you a calculator that spits out a precise percentage is selling certainty that does not exist.

Why "it was my idea" is not an input

The most common opening position I hear is that the idea is worth the majority of the company. It is not, and pretending otherwise is the fastest way to lose the engineer you were trying to recruit.

Ideas are cheap in the sense that matters here: several other people are having yours right now, and the difference between them and you will be execution. If your idea genuinely is the asset, the question is why you cannot fund its construction. If the answer is that nobody will fund it yet, then the risk being absorbed by the person who builds it is real, and it prices accordingly.

What legitimately shifts the number in your favour is evidence: customers who have paid, a distribution advantage nobody can copy, domain knowledge that took a decade to acquire, funding already committed, or a full-time head start where you have been at this for two years and they are joining on Monday. Those are inputs. "I thought of it" is not.

The four things that actually move the number

When I am the one deciding whether to say yes, I am weighing four things, and they are the same four on both sides of the table.

1. Who is carrying how much risk, in cash terms. Is either of you taking a salary? Whose savings are funding the next twelve months? A founder who has been unpaid for eighteen months has contributed real capital, and it should count. So has a technical co-founder who leaves a senior salary to build for free.

2. Full-time or not. A part-time co-founder is not a co-founder. If one of you is keeping a job while the other goes all in, that gap has to show up in the split or in the vesting, and it is the single most common source of later resentment.

3. What happens if this person leaves in month six. This is a vesting question rather than a percentage question, and I will come back to it, but it belongs in your thinking from the start.

4. Whether the technology is the moat. If the product is a well-understood build, a marketplace, a booking flow, a dashboard over an API, then you need it built well rather than invented, and the equity case for a co-founder is weaker. If the hard part is genuinely hard, novel AI systems, infrastructure, security-critical products, then the person solving it is not a builder you are hiring, they are the reason the company can exist.

Vesting matters more than the split

Here is the thing founders discover late: the structure protects both of you far more than the percentage does.

Four-year vesting with a one-year cliff, for both founders, with no exceptions. Not just the technical co-founder. Both of you, including whoever holds the larger share. This is not a sign of distrust, it is the mechanism that makes trust affordable. It makes "half the company to someone who left in month four" impossible, which is precisely what allows a generous split to be safe to offer in the first place.

Put decision rights in writing. Who decides product, who decides technical architecture, what spending limits exist, and what needs both signatures. Most co-founder disputes I have watched were not about equity, they were about a decision someone thought was theirs.

Agree the exit script before you need it. What happens if one of you wants out, gets an offer they cannot refuse, or simply stops showing up. It is an uncomfortable conversation on day one and a catastrophic one to improvise in year two.

Write it down properly, with a lawyer, before anyone writes code. Handshake splits between friends are the single most expensive form of optimism in startups. The document costs a small fraction of what fixing its absence costs.

A fair split with no vesting is worse than an aggressive split with proper vesting. If you only take one thing from this piece, take that.

Co-founder, first engineer, or advisor

Three very different roles get labelled as co-founder, usually because equity is easier to offer than salary. The market ranges are not close to each other:

Technical co-founder: the double-digit percentages above, vesting over four years, full-time, sharing the risk and the decisions.
First engineer: typically 0.5 to 2 percent, with a salary, joining after the founding risk has been partly absorbed.
Advisor: typically 0.25 to 1 percent, vesting over two years, for a few hours a month of judgment rather than ownership of delivery.

If what you actually need is someone to build the thing, and you call it a co-founder role to avoid paying, you will attract exactly the engineers who cannot tell the difference. That is the opposite of the selection you want.

Three patterns that turn a fair deal into resentment

The silent part-timer. One founder is full-time, the other is keeping a job "for another couple of months" that becomes another year. The equity was agreed on the assumption of parity that never arrived. Fix this with vesting tied to actually starting full-time, and by saying the quiet part out loud early.

The renegotiation after the hard part. The product ships, the company raises, and suddenly the split is revisited because the technical work "is done now". It is never done, and nothing destroys a technical co-founder's commitment faster than discovering their share was contingent on a phase.

The 90/10 that was accepted quietly. An engineer takes a token share because they wanted to work on the problem, tells themselves it is fine, and spends two years watching a company they built be mostly owned by someone else. It does not stay fine. It converts into slow disengagement, and it will cost you far more than the equity would have.

A split that leaves either founder quietly resentful is a liability on the cap table that no amount of traction fixes.

The option most founders never price

Before you give away a third of your company, it is worth doing the arithmetic on the alternative coldly, because most founders never do.

If your product is a well-understood build and your unfair advantage is distribution or domain knowledge, you may not need a co-founder at all. You need the product built well and senior technical judgment available while you build the company. That is a cash cost with a defined end, not a permanent claim on your exit.

That is the trade I offer founders now. I build MVPs priced per screen, so the total is known before anything is built, and I work as a fractional CTO with the pricing published, at a monthly cost that is a rounding error next to a co-founder's equity. The cost and rates guide has the full comparison against a full-time hire.

And sometimes, a few months into an engagement like that, it turns into something more permanent. That is the best possible way to choose a co-founder: after you have already worked together, shipped something, and seen how the other person behaves when it breaks at two in the morning.

Frequently asked questions

What is a fair equity split for a technical co-founder? Pre-product and pre-revenue, with the technical co-founder building everything, 40 to 50 percent of the founder pool is defensible. With a prototype, 35 to 45. With revenue or committed funding, 25 to 40. Below roughly 20 percent for a genuine full-time founding role, expect most experienced engineers to decline.

Should a technical co-founder get 50 percent? Often yes, at the idea stage, and it is less frightening than it sounds once both sides vest over four years with a cliff. The scenario founders fear, handing half the company to someone who leaves, is exactly what vesting prevents.

What if I have already built a prototype? It shifts the number modestly, not dramatically. Be honest with yourself about whether the prototype is an asset or a liability the co-founder will have to rewrite. A contractor-built demo usually does not survive production, and every experienced engineer knows it.

Do co-founders always split equally? No, and equal splits are not automatically correct. They are simply common at the idea stage because the contributions genuinely are comparable. Unequal splits work fine when the reason is a fact both people agree on, and fail when it is a position one person negotiated harder for.

How does vesting work for founders? Standard is four years with a one-year cliff: nothing vests until twelve months, then monthly. It applies to every founder including the majority holder. Add acceleration terms for a change of control if you want, but do not skip the cliff.

What about equity instead of salary for a fractional CTO? That is a different and much smaller conversation, usually a partial swap rather than a founder-sized grant. I do it case by case, from a small equity component up to roughly half and half, depending on stage and how long we expect to work together. It is a way to share risk without restructuring your cap table.

When should I not look for a technical co-founder at all? When the technology serves your advantage rather than being it, when you can fund development modestly, or when the search would take the six to nine months you do not have. I covered the full version of this in how to find a technical co-founder.

If you are in the middle of this decision, tell me what you are building and I will give you the straight read on whether the situation calls for equity, a retainer, or neither yet. I take on technical co-founder partnerships very selectively, and everything on this page is the same bar I apply to myself.