DEV Community: Kunal Vohra

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.

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.

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.

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.

Fractional CTO vs Full-Time CTO: Which One Your Startup Actually Needs

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

The short answer: hire a full-time CTO when technical leadership has become a full-time job, and engage a fractional CTO when it has not. In practice that line sits somewhere around eight engineers and a funded roadmap. Below it, a full-time CTO spends a meaningful part of the week looking for work that justifies the title. Above it, a part-time leader becomes the bottleneck every decision queues behind.

I have been on both sides of this. I have been the full-time technical co-founder six times, and I now work as a fractional CTO for AI-first startups. What follows is the comparison I give founders on calls, including the cases where I tell them not to hire me.

Fractional CTO vs full-time CTO: the real difference

The difference is time and commitment, not seniority. A fractional CTO is a senior technology executive who leads your engineering part-time, usually two or three days a week. A full-time CTO does the same job five days a week, as an employee, almost always with equity.

Everything else follows from that one distinction:

Cost. A full-time startup CTO in the US runs roughly $260,000 a year fully loaded, before equity. Fractional engagements in this market typically run $4,000 to $15,000 a month, with hourly rates between $150 and $350. My own published tiers start at $750 a month, and the full cost and rates guide breaks down where those market numbers come from.
Equity. A full-time CTO expects a meaningful grant, often low single digits post-funding and far more at founding. A fractional CTO usually takes none.
Reversibility. Ending a fractional engagement is thirty days notice. Ending a full-time CTO relationship is a severance conversation, a cap table conversation, and six months of hiring.
Speed to start. A fractional engagement starts in a week or two. A full-time CTO search takes three to six months, and that is before notice periods.
Depth of context. This one favours the full-time hire. Someone in your building every day accumulates context a part-time leader will never fully match.

If you are still working out what the role covers day to day, I wrote a separate piece on what a fractional CTO actually does.

When a fractional CTO is the better choice

A fractional CTO is the better choice when the technical decisions are big but infrequent, and the cost of getting them wrong is high.

That describes most companies before Series A. Concretely, the fit is strong when:

You are pre-product or pre-revenue. The architecture calls you make now are the expensive ones, and they take judgment rather than hours.
You have a small team or an agency building. Three engineers and a contractor do not need a manager. They need someone senior enough to review the design, catch the decision that will cost you a year, and be accountable for the roadmap.
You are non-technical and cannot evaluate engineers. This is the most common reason founders call me, and it is a real problem. You cannot hire your way out of not being able to assess a hire.
Your runway will not absorb a senior salary. Paying $260,000 a year out of a $1.5 million seed to a role that genuinely does not need forty hours is how companies shorten their own runway.
You are bridging a departure. Your CTO left, and the search will take six months you do not have. A fractional leader keeps the engineering organisation running and often hires the replacement.

There is a quieter argument too. A fractional CTO has usually seen more companies more recently than a full-time hire at the same seniority, because pattern recognition is the product. I have watched four teams make the same infrastructure mistake in eighteen months, which is why I spot it on day three rather than in the postmortem.

When you genuinely need a full-time CTO

I will say this plainly, because the internet is full of fractional CTOs who will not: past a certain point, part-time leadership is the wrong answer, and taking a retainer at that point is taking money for a role you cannot fill.

Hire full-time when:

Engineering is bigger than about eight people. Management, performance, career growth, and hiring at that scale are a full-time job on their own, before a single architecture decision.
The technology is the company. Deep infrastructure, novel research, hardware. If the hardest technical work is the product rather than supporting it, it needs someone whose whole week is that problem.
You are in a continuous hiring cycle. Twenty interviews a month is a full-time load.
Investors are making it a condition. Sometimes this is theatre, and sometimes it reflects a real gap. Either way, it is a fact you have to price in.
The role is the succession plan. If the person is meant to grow into a long-term executive who builds the culture of the engineering team, that is a full-time relationship with equity attached.

The honest version of my pitch is that a good fractional engagement is designed to end. If I am doing the job properly, one of two things happens: the company stays at a size where part-time leadership is correct, or it grows past me and I hire my own replacement.

Fractional CTO vs interim CTO vs technical advisor vs co-founder

These four get used interchangeably, and they are not the same thing.

Interim CTO: full-time, but temporary. Usually bridging a departure or covering a defined crisis, measured in months. Full-time hours, no long-term equity story.

Fractional CTO: part-time and ongoing. Two or three days a week, indefinitely, paid in cash. The shape most early-stage companies actually need.

Technical advisor: a few hours a month, typically for decision review rather than ownership. Often paid in a small equity grant, sometimes in cash. Nobody advises your way out of a broken roadmap, so do not buy this when you need the one above. My own technical advisor tier exists for founders who genuinely only need the big calls checked.

Technical co-founder: equity, years of commitment, shared risk, and a seat at the table for every decision including the ones that are not technical. The most expensive and least reversible option, and occasionally the correct one. I wrote the long version in how to find a technical co-founder.

The mistake I see most often is founders reaching for the co-founder option because it feels free. It is the most expensive money you will ever spend, it just does not appear on a bank statement.

The cost comparison, done properly

Comparing a monthly retainer to a monthly salary is the wrong arithmetic, because it leaves out the four costs that actually decide this.

Fully loaded salary, not base. A $200,000 base is roughly $260,000 once payroll taxes, benefits, equipment, and software are in. That is the number to compare against.

Equity, priced honestly. A CTO grant is a permanent claim on the company's exit. Even at a modest percentage, it is usually the largest single line in this comparison, and it is the one founders leave out because it does not hit cash flow.

The cost of the search. Three to six months of executive search, your time, and possibly a recruiter fee at twenty to twenty-five percent of first-year salary. Meanwhile the decisions you needed leadership for are still being deferred.

The cost of getting it wrong. A mis-hired executive is expensive to remove, and at a ten-person company it is a serious event. A fractional engagement that is not working ends in thirty days.

Run those four properly and the comparison usually stops being close at the early stage. It also stops being close in the other direction once you have a real engineering organisation, which is the point.

Five questions that decide it

Answer these honestly and the choice usually makes itself:

How many engineers report into this role today, and in twelve months? Under eight, fractional. Well over, full-time.
Is the hard technical work the product, or in service of it? If the technology is the moat, lean full-time.
Can you afford the salary without shortening runway past your next milestone? If not, the question is settled for now.
Do you need forty hours of decisions, or four hours of the right decisions? Most early-stage founders need the second and buy the first.
What breaks first if nobody senior is in the room? If the answer is one specific thing, a fractional engagement fixes it. If the answer is everything, you need someone here every day.

Frequently asked questions

Is a fractional CTO cheaper than a full-time CTO? Yes, substantially, and the gap is wider than the headline numbers suggest once equity and search costs are included. A full-time CTO runs about $260,000 a year fully loaded before equity; fractional retainers typically run $4,000 to $15,000 a month, and my published tiers start at $750.

Can a fractional CTO manage a full engineering team? Up to a point. Around eight engineers, the management load alone fills a week, and part-time leadership starts to bottleneck the team rather than unblock it. Below that, yes, and it is a large part of the work.

Does a fractional CTO take equity? Usually not, which is the main structural advantage over a co-founder. I do offer a cash and equity split when a founder prefers it, from a small component up to roughly half and half, but the default is cash and no dilution.

How long does a fractional CTO engagement last? The ones that work tend to run six to eighteen months. Long enough to build the systems and the team that make the role unnecessary, which is the intended ending.

Can you convert a fractional CTO into a full-time CTO? Sometimes, and it is the lowest-risk way to hire one, because you have already worked together for months. It is also the honest reason I tell founders to start fractional: you find out what the person is like when something breaks, before the equity conversation.

What if we hire full-time and it is too early? You will feel it within a quarter: a senior person generating work to justify the seniority, usually a rewrite or a platform project nobody asked for. That is the failure mode of hiring this role early, and it is expensive in engineering time as well as salary.

If you are weighing these two right now, book a call and describe what is stuck. I will tell you which one your situation calls for, including when the answer is a full-time hire and not me. The fractional CTO page covers how I work and what the first month looks like, and the cost and rates guide has the numbers with nothing withheld.

Jev and System One Models: What TypeSafe Built, and How It Differs From an LLM

Kunal Vohra — Sun, 20 Sep 2026 12:00:00 +0000

Every AI product I've shipped has the same hidden layer inside it. Not the chat, not the generation, but the dozens of small yes-or-no and which-one-of-these decisions the code has to make around the model: is this message spam, which queue does this ticket go to, is this tool call safe to run, does this answer actually cite the document. I've built that layer with regex, with fine-tuned classifiers, and lately with a cheap LLM and a JSON schema. None of those options felt finished.

On September 15, a company called TypeSafe AI came out of two years of stealth with a $40M seed round and a model called Jev that is built for exactly that layer, and nothing else. Jev cannot generate text. It takes your program state and a set of typed questions, and returns a probability for every answer, in one pass, in well under a second, at a price that rounds to zero.

I have not put it into production yet. What I have done is read the launch post, the API docs, the 500-comment Hacker News thread, the TechCrunch and Register coverage, and four independent benchmark write-ups from the first week. This is my read as someone who builds AI products for a living: what Jev is, how a "System One model" differs from the LLMs you already use, which claims survive contact with the evidence, and where I'd put it in a real architecture.

What Jev actually is

Jev is a hosted model with one endpoint and three question types, and no ability to produce a string. You send it a state (text, a JSON object, or an array: a support ticket, a document, a game board, a database row) plus a map of questions. Each question is one of three primitives. A Noul asks whether a statement is true and returns a probability between 0 and 1. A Choice picks from a list you supply, up to 255 options, and returns the winner plus the full probability distribution. A Score places the state on an ordered rubric of 2 to 10 levels. Every question in a request is answered in parallel against the same state, and the docs say adding more questions barely changes the response time.

The numbers TypeSafe publishes: $0.042 per million input tokens, output free, a 64k-token context window, latency claimed at 70 to 500 milliseconds, text-only input, English-first. There are Python and JavaScript SDKs, and Vercel added it to AI Gateway within a day. It launched as a waitlist and, going by TypeSafe's own posts, is opening to everyone as I write this.

The company is run by Diogo Almeida, who was part of the InstructGPT and RLHF work at OpenAI that became the research behind ChatGPT. That pedigree is the strongest marketing asset they have, and it's also why the launch got 1,953 points on Hacker News, more than Gemini's same-day release.

TypeSafe calls this category a "System One model," after Kahneman's split between fast intuitive thinking and slow deliberate reasoning. The model's name honours William Stanley Jevons, whose paradox says that making a resource cheaper increases total consumption of it. That's the bet in one line: make a decision cost less than the log line that records it, and software will make a hundred times more decisions.

How a System One model differs from an LLM

The difference is mechanical, and it explains almost everything else. An LLM generates one token at a time, and each token requires a full pass through the model. A one-word answer to a classification question still costs a prefill pass over your input plus at least a few decode steps, and a reasoning-mode model burns thousands of hidden tokens before you see the first visible one. That's why TypeSafe's comparison table shows frontier models taking 3 to 329 seconds on its workflows.

Jev skips the decode loop entirely. It reads the input once and emits a fixed-size probability vector for each question. No sequential generation, no tokens to sample, nothing to parse. Prefill is compute-bound and batches well; decode is memory-bound and serial. Removing decode is the same reason a fine-tuned BERT classifier has always been orders of magnitude cheaper than a generative model on the same task, and it's why "output tokens: free" is coherent pricing rather than a gimmick. The output is a handful of floats.

The second difference is training. LLMs are optimised with RLHF (reward what human raters prefer) or, for reasoning models, RLVR (reward what can be verified). TypeSafe says Jev is trained with something it calls Reinforcement Learning for Calibrated Decisions, or RLCD, which rewards probabilities that are honest: if the model says 0.8, the answer should be right about 80% of the time. Their argument is that human preference and machine trustworthiness are different targets, and that RLHF actively rewards confident-sounding wrong answers.

Here is what I want to be straight about. TypeSafe has published no paper, no parameter count, no architecture, no reward function, and no calibration figure. Almeida told Latent Space that public benchmarks are "extremely gameable" and won't be published. TechCrunch reports that outside observers suspect Jev sits on top of an open-weight LLM. Within 48 hours, six functional clones appeared on GitHub built from ordinary parts (ModernBERT plus PPO, Qwen 3.5 plus an NLI head), and the best of them match hosted Jev on flat classification benchmarks. So the interface is genuinely useful, but the model underneath is a black box, and the moat, if there is one, is the synthetic training data, not the architecture.

What "cannot hallucinate" really means

Jev cannot produce an output that is outside your schema. That is the whole claim, and TypeSafe's own launch post admits the 0% hallucination number is "not empirical" but definitional. When a user on Hacker News pushed, Almeida conceded that type safety is not factual correctness and that Jev "can still emit a completely wrong valid value."

That's the same guarantee a softmax classifier has always had, and it's also a guarantee you can already get from Anthropic, OpenAI and Google, all of which now use constrained decoding to force valid JSON. Schema compliance is table stakes in 2026. A benchmark of 21 models this April found near-perfect schema validity but only 83% value accuracy on text: the failure mode has moved from broken JSON to well-formed JSON with the wrong answer in it.

TypeSafe's own evals make the same point in numbers. On the four workflows the company published, Jev agrees with the reference labels 67.8% of the time. GPT-5.6 Sol scores 74.1% and Opus 5 scores 73.1%. Jev is not the most accurate model on TypeSafe's own benchmark; it's the one that gets to 68% for $0.0004 and 0.4 seconds per case instead of $0.08 and 23 seconds. Roughly one decision in three disagrees with a frontier judge. That's a useful tool, not an oracle.

The 444x claim, with the arithmetic

TypeSafe's homepage says 193.6x faster and 444.6x cheaper. Those numbers are real in one specific comparison: against GPT-6 Astra and Claude Fable 5.1 in reasoning mode, running through TypeSafe's own wrapper, on workflows TypeSafe's team wrote. The launch post itself says these are "on the higher end of real world gains."

Nobody I know runs a 500-token classification through a flagship reasoning model. They run it through the cheap tier. So here's the same call priced from list prices, per million calls:

Jev: about $21
GPT-5 nano: about $29
Gemini 2.5 Flash-Lite: about $54
Claude Haiku 4.5: about $550
Sonnet 5 or GPT-5.6 Terra: about $1,100
Fable 5.1 or GPT-6 Astra: about $5,500

Against the flagships, Jev is roughly 260x cheaper. Against GPT-5 nano, it's 1.4x cheaper. And with prompt caching, cached input on Haiku 4.5 costs $0.10 per million and on GPT-5.6 Luna $0.02, both below Jev's headline price. Jev bills the full state every call. That's why one CTO quoted in TechCrunch found Jev 10 to 20 times more expensive than his Gemini setup, even while praising the confidence scores.

Latency follows the same pattern. Independent measurements in the first week put Jev at a p50 of roughly 0.4 to 1.0 seconds from outside the West Coast. A short non-reasoning call on Haiku or Gemini Flash lands at 0.5 to 1.5 seconds. That's a 2x to 10x edge, not 200x. The one place the raw speed is unarguable is real-time loops: in Ably Labs' Pong demo, Jev made 47 decisions in 12 seconds while Gemini, Haiku and GPT managed two or three each. If your product needs an intelligent decision every 200 milliseconds, there is no LLM substitute.

The honest version of the headline: Jev is single-digit multiples cheaper and faster than the models you'd actually use for classification, and hundreds of times cheaper than the ones you wouldn't.

Calibration is the real claim, and the evidence is mixed

Speed and price are nice. The thing that would change how I architect systems is a probability I can threshold on. If the model says 0.95 and it's right 95% of the time, I can automate the 0.95 cases and route the rest to a human or a bigger model. That's the difference between a demo and an automation. Every LLM I've asked for a confidence number gives me one that is prompted, not trained, and usually overconfident.

Four independent tests looked at exactly this, and they don't agree. A 60-item test of agent tool-call risk found 91.7% accuracy with every wrong answer carrying confidence below 1.0, which is the behaviour you want. A much larger study of 4,621 items found Jev accurate and well calibrated on public benchmarks (expected calibration error around 0.02) but overconfident on out-of-distribution synthetic support tickets, with error 4.4 times the noise floor and a priority score that was right only 44.7% of the time while carrying 0.74 average probability. A second audit concluded the probabilities are not calibrated at any difficulty level, but they are monotone: higher probability really does mean higher hit rate. Both larger studies land on the same advice: treat Jev's output as a ranking score, not a probability, and fit your own threshold on a few hundred labelled examples per question.

Two more things the docs are candid about. The confidence field is not a separately learned uncertainty estimate; it's a linear rescale of the top probability, so it can't tell you anything the distribution doesn't. And TypeSafe's own "jaggedness" page lists the known weaknesses: Jev does not count reliably, reads dates as text rather than ordered quantities, gets worse as irrelevant context grows, and can be steered by instructions injected into the state. That last one matters if you're using it as a guardrail; I've written before about why prompt injection is the SQL injection of this era, and a decision model reading untrusted input inherits the problem.

Where I'd use it, and where I wouldn't

The pattern that every vendor guide and community project has converged on in a week is simple: LLMs for anything that produces a string, a decision model at the branch points where code needs a number. That's the pattern I'd adopt whether the model in the branch slot is Jev, one of its open clones, or a fine-tuned encoder.

Four branch points earn a decision model:

Intake routing. Which agent, which queue, which model tier handles this request. High volume, enumerable answers, and every millisecond is in the user's path.
Pre-execution gating. Is this tool call safe, does this message contain an injection, does this content violate policy. Guardrails run on every call, so cost and latency are the binding constraint, and this is where Vercel reported 5x to 18x speedups after swapping ChatGPT for Jev in safety classification.
Post-generation verification. Does the LLM's answer actually cite the source, does it match the rubric, is it on topic. A second opinion for a fraction of a cent.
Batch scoring over data. Deduplication, entity matching, tagging every row in a large table. One cookbook example asks 13 questions of a 54,000-character document in a single call at about a tenth of the cost of 13 sequential LLM calls.

Where I wouldn't use it: anything whose output is text (summaries, replies, SQL, code, extracting a name or address), anything with images, anything with arithmetic or date logic, multi-step reasoning, and any decision with more than 255 options unless you decompose it. And before any of that, the rule Zyte's engineers wrote in their test applies: if a regular expression, a status code or a CSS class can answer the question, don't ask a model at all.

One more choice to make. If you have thousands of labelled examples and a stable label set, a fine-tuned encoder still beats Jev on accuracy, latency and marginal cost, and you can calibrate its softmax on a held-out set yourself. Jev's real competition isn't the encoder; it's the small LLM with an enum schema that most teams use today when they have no labels and the categories keep changing. That's the head-to-head worth running on your own traffic.

What this means if you're building an AI product

The durable thing about this launch isn't the model. It's the interface it normalises. "Unstructured state in, typed probabilities out" as a hosted primitive is the decision-tier version of what the embeddings API was in 2022: a known technique whose packaging and price make it a default building block. Open clones matched hosted embeddings on flat tasks within months; here they matched Jev on flat classification within days. TypeSafe's defensible ground is narrow and specific: calibration under distribution shift and judgment on decisions that need a bit of reasoning, which are precisely the two things it has neither published nor had independently confirmed.

For a founder, three practical consequences:

Budget decision calls as free and model the escalation rate instead. At a hundredth of a cent per decision, the cost that matters is what happens to the 20% of cases the model isn't sure about.
Build a labelled eval set per question, a few hundred examples, before trusting any threshold. Simon Willison's note on this is the one I'd pin up: for a model that returns only a number, evals matter more than they do for regular LLM projects, not less.
Wrap the call behind an interface. The model is closed, has no SLA, and Almeida has said current versions won't be supported long-term. Open clones already match it on the easy cases, so keep your lock-in exposure to the hard ones.

If you want to try it, the pilot I'd run is unglamorous: take one enum classifier already in production on a cheap LLM, shadow-run Jev on the same traffic for a week, and measure agreement with your current classifier, agreement with human labels, calibration on the human-labelled slice, and p95 latency from your own region. Then automate the low-risk path first and keep deterministic code wherever it already decides correctly.

This is the kind of decision I make with founders every week as a fractional CTO: not "is this new model exciting" but "where in our architecture does it earn its place, and what breaks if the vendor changes the price." If you're designing that layer for an AI product right now, get in touch and I'll give you an honest read on whether a decision model belongs in it.

Frequently asked questions

What is Jev in one sentence? Jev is a hosted AI model from TypeSafe AI that takes program state and typed questions and returns calibrated probabilities for each answer, in one parallel pass, without generating any text.

What is a System One model? TypeSafe's name for a class of models built for fast, structured decisions rather than text generation, after Kahneman's "System 1" intuitive thinking. Simon Willison and others prefer the plainer term "decision model." No other lab uses the category name yet.

How is Jev different from structured outputs or JSON mode? Structured output modes on Claude, GPT and Gemini guarantee valid JSON but give you no trained confidence signal. Jev's pitch is a probability distribution trained to be calibrated. Independent tests so far find the probabilities monotone but overconfident out of distribution, so you still need your own thresholds.

Is Jev really 444x cheaper than an LLM? Only against flagship reasoning models on TypeSafe's own workflows. Against the cheap tiers you'd actually use for classification, the gap is about 1.4x to 10x, and with prompt caching some LLMs are cheaper per cached token.

Can Jev hallucinate? It cannot return anything outside your schema. It can, and does, return a well-formed wrong answer: on TypeSafe's own evals it disagrees with a frontier judge on about one decision in three.

What should I use Jev for? Routing, guardrails, verification and batch scoring: high-volume decisions with an enumerable answer set where latency matters. Not for anything that needs generated text, images, arithmetic, or an explanation of its reasoning.

Does it replace my LLM? No. The pattern is an LLM for generation and a decision model at branch points. LangChain's own guide says plainly that Jev is not a drop-in replacement for an LLM.

Sources: the TypeSafe launch post and docs, TypeSafe's workflow evals, the Hacker News launch thread, TechCrunch, Simon Willison, LangChain's harness guide, Zyte's scraping test, and the independent calibration studies by scienthoon and SamuelSacco. Prices are list prices as of September 20, 2026.

iPhone 18 Pro, iPhone Duo, and the AI Problem Apple Still Hasn't Solved

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

Yesterday Apple pushed Siri AI into public beta. This morning it cut trade-in values on every iPhone it accepts. Between those two events sits the September 9 keynote, the first one John Ternus has run as CEO, where Apple announced the iPhone 18 Pro, the iPhone 18 Pro Max, and the foldable it calls iPhone Duo.

I build AI products for a living and I have carried an iPhone since the 3G. So I watched this one with two questions in mind. First, is the hardware worth the money? Second, after two years of promises, does Apple finally have an AI story that is its own? The answer to the first is mostly yes. The answer to the second is still no, and the reasons are more structural than a single delayed feature.

This is the long version: the phones, the foldable's trade-offs, the trade-in math, and a section on why the richest hardware company on earth keeps showing up to the AI fight with someone else's model.

iPhone 18 Pro: the best iterative update Apple has made in years

Nobody is going to call the iPhone 18 Pro a redesign, and some reviewers have already used the word "boring." I think that undersells it. The changes are inside, and they are the kind that matter for the next three years of owning the thing.

The headline is the A20 Pro, the first Apple chip on a 2-nanometer process. Apple claims the six-core CPU is up to 20 percent faster than the A19 Pro and the seven-core GPU up to 40 percent faster. The number I care about is the Neural Engine: a dual 16-core design with roughly twice the AI compute of last year, plus 50 percent more memory bandwidth. RAM stays at 12GB. That combination tells you what the chip was built for. It is an on-device inference machine first, and a gaming chip second.

The other quiet change is connectivity. Most iPhone 18 Pro models use Apple's own C2 modem, which finally adds mmWave 5G in the US and, by Apple's claim, uses about 15 percent less power than the C1X. The exception is the US Pro Max, which still ships with a Qualcomm Snapdragon X80. Alongside it sits the N1 chip for Wi-Fi 7, Bluetooth 6, and Thread. Apple now designs the CPU, GPU, Neural Engine, modem, and wireless radio in its flagship phone. Keep that in mind for the AI section, because it is the part that makes Apple's software position so strange.

The camera is where the money went. The 48MP main sensor is larger, and for the first time it has a mechanical variable aperture, six laser-cut blades stepping between f/1.48 and f/4.0. Apple says it gathers around 50 percent more light in low-light conditions. The telephoto stays at 48MP with 4x optical and a 12MP 8x crop, and the front camera moves to 18MP. Pro controls now expose aperture, shutter speed, and white balance directly, which photographers have asked for since the first Pro model.

The rest of the spec sheet, quickly:

6.3-inch and 6.9-inch ProMotion OLED panels, 3,000 nits outdoors, a smaller Dynamic Island that can show three Live Activities.
Up to 36 hours of video playback on the Pro and 45 on the Pro Max, with 50 percent charge in about 15 minutes on a 60W adapter. The best battery figures require the eSIM-only configuration.
Weight went up: 211 grams for the Pro and 249 for the Pro Max.
Colors are Black, Silver, Burgundy, and Glacier. Storage starts at 256GB and now goes to 2TB even on the smaller model.
$1,199 for the Pro and $1,299 for the Pro Max. Pre-orders opened September 12 and the phones land in stores this Friday, September 18.

My take: if you are on an iPhone 15 Pro or older, this is a clear upgrade. If you have a 17 Pro, the only reasons to move are the variable aperture and the Neural Engine, and the second one only matters if Apple ships software that uses it. More on that below.

iPhone Duo: Apple's first foldable, and what it gives up

Ternus called the Duo "the most transformational change to iPhone since the original." That is keynote language, but the product underneath it is more careful than the quote suggests.

The Duo is a book-style foldable. Closed, it has a 5.4-inch outer display that Apple says gives you about 90 percent of the screen area of an iPhone 18 Pro. Open, you get a 7.6-inch inner display, roughly 80 percent larger than the 18 Pro's. Both panels are Super Retina XDR with ProMotion, Always-On, 3,000 nits, and a nano-texture finish, and they share the same aspect ratio so apps scale proportionally instead of reflowing. The inner panel uses a micro-lens texture made with maskless laser lithography, which is Apple's answer to the crease. Reviewers who have handled it say the crease is reduced, not gone.

The frame is Grade 5 titanium. The hinge has more than 100 precision components and a 3D-printed cover made from recycled titanium. The whole thing is IP68 to six meters, which is unusual for a foldable. Unfolded it is 5.2mm thick, which Apple is calling the thinnest iPhone ever. Folded it is 11.3mm, and it weighs 254 grams.

That weight is the first trade-off. Samsung's Galaxy Z Fold 8 is 201 grams and 4.5mm unfolded, and the Fold 8 Ultra is 215 grams and 4.1mm. The Duo is thicker and heavier than nearly every Android foldable on sale, and $100 more than the base Fold 8 at $1,999 for 256GB. Apple spent that mass on durability and on two batteries, one per half. The payoff is up to 31 hours of video on the inner display, 44 on the outer, and 24 when you split time between them. Charging is 50 percent in about 20 minutes wired.

The other trade-offs are the ones that will surprise people who expect a Pro phone that folds:

No Face ID. Touch ID is built into the side button, and you can unlock with an Apple Watch. The inner FaceTime camera sits under the display.
No telephoto. You get the 48MP Fusion main and the 48MP ultra wide from the 18 Pro, with a 2x optical-quality crop. No 4x, no 8x, no variable aperture.
No Action button , and eSIM only worldwide.
Same A20 Pro as the 18 Pro, with a custom vapor chamber that Apple says sustains 35 percent more performance than the 17 Pro.

Software is where Apple has clearly done real work. The Duo ships on iOS 27.1 with the first true Split View on an iPhone, a dock and Lock Screen pushed to the sides when open, a vertical Dynamic Island, a redesigned StandBy that works unplugged on either screen, and Apple Pencil support coming later over USB-C. Camera features like Duo Preview, which shows your subject the shot on the outer screen while you frame it with the inner one, are the kind of thing only a two-screen phone can do.

Pre-orders open October 16 and it ships October 23 in Star White and Night Sky, with storage up to 2TB. Counterpoint thinks it could take up to a quarter of the foldable market by year end, which sounds dramatic until you remember foldables are under 2 percent of smartphone shipments. Apple is entering a small category late, at the top of its price range, with a heavier device that has fewer cameras. That is either a mistake or exactly the iPad playbook: arrive late, make the software feel finished, and let the market catch up. I lean toward the second, but not with my own $2,000, not in the first generation.

Macworld's line is the right one: buy the Duo because you want the folding experience, not because it is the best iPhone. The best iPhone is the 18 Pro Max.

Why is Apple still so weak in AI?

This is the section I actually wanted to write.

Rewind to June 2024. Apple stood on stage at WWDC and announced Apple Intelligence and a new Siri that understood personal context, could see your screen, and could take actions inside apps. It ran ads for it. It sold iPhone 16s on the back of it. That Siri did not ship in 2024. It did not ship in 2025. Apple pushed it beyond iOS 26.4 in February of this year because of, in the reports at the time, bugs it could not close.

What did ship yesterday, September 14, is called Siri AI, and it does most of what the 2024 demo promised: personal context across Messages, Mail, and Photos, on-screen awareness, actions inside third-party apps like WhatsApp and Outlook, a standalone Siri app with synced conversation history. It is a beta. It is English only until October. It is not available in the EU on iPhone, iPad, or Watch, and China is waiting on regulators. And the models behind it are, in Apple's own careful phrasing, custom-built in collaboration with Google's Gemini, under a deal reported in January at around $1 billion a year.

Read that again. The company that designs its own CPU, GPU, Neural Engine, modem, and radio, and that just put twice the AI compute into the A20 Pro, could not close the gap on the model itself. It bought the capability from the company it competes with in search, maps, and phones. When the WWDC keynote in June showed this off, the stock fell about 2 percent on the day, and KeyBanc's Brandon Nispel called the updates "lacking" with "no clear signs of monetization." I do not think the market was wrong.

So why? Here is my read, from someone who has built machine-learning teams inside startups and watched large companies try to do the same.

1. Apple optimized for the wrong constraint. Apple's AI strategy was built around privacy and on-device execution before it was built around capability. Those are good values, and Private Cloud Compute is genuinely clever engineering. But frontier models in 2024 and 2025 were won by whoever could train the largest models on the most compute, and Apple deliberately did not build that infrastructure. Google, OpenAI, Anthropic, and Meta each spent more on training compute in a year than Apple spent on its entire AI effort. You cannot distill a great small model from a mediocre large one, and Apple did not have a great large one.

2. It lost the people who could have fixed that. Ruoming Pang, who ran the Apple Foundation Models team, left for Meta in the summer of 2025. Roughly a dozen researchers and executives followed over the next six months, including several more from the foundation models group. John Giannandrea, the SVP who ran AI strategy since 2018, was moved aside in favor of Craig Federighi and retired this spring. Apple hired Amar Subramanya from Microsoft to rebuild, but you do not rebuild a frontier lab in nine months. A talent war is fought with mission and compute as much as money, and Apple was short on both.

3. The hardware and the software are on different clocks. The A20 Pro's Neural Engine is a real advantage. Nobody else ships that much on-device inference in a phone at Apple's volume. But silicon is a three-year pipeline and software is a three-month one, and Apple's model team could not keep up with its own chip team. That is why every iPhone since the 16 has been sold on AI features that arrived a year or two later, or not at all. Nispel's other complaint, that even the advanced features require an iPhone 17 or newer, is the same problem from the customer's side.

4. Apple's culture punishes shipping unfinished things. Google and OpenAI ship models that are wrong 10 percent of the time and fix them in public. Apple's entire brand is that the thing works when you take it out of the box. That instinct is right for phones and wrong for the current state of AI, where a product that is 80 percent right and improving weekly beats one that is 95 percent right and two years late. The 2024 Siri demo was Apple trying to do the Google thing. The two-year gap was Apple remembering it is Apple.

5. The keynote told on itself. The slide that stuck with me from September 9 was "2.5 billion requests per day." That is a Siri usage number. It is a distribution number, not a capability number. Apple has the largest installed base of any AI assistant on earth and it is leading with reach because it cannot lead with quality yet.

None of this means Apple loses. Apple has done this before. It bought its way into maps, into chips, into the modem. The pattern is arrive late, lease the capability, integrate so tightly the late start stops mattering, then internalize. The Gemini deal is the leasing step. The A20 Pro and the Duo's Split View and Live Rewind are the integration step. The question is whether Apple can do the last step with a model team that is a fraction of the size it was eighteen months ago, while paying a competitor a billion dollars a year for the privilege of catching up.

My prediction: Apple's on-device models will be excellent within two years, because that is a hardware-adjacent problem and Apple is good at those. Its cloud models will stay rented. And Siri will get most of the way to what was demoed in 2024, in 2027.

What to do with your old iPhone before Friday

Now the part that costs you money if you skip it.

This morning, September 15, Apple cut trade-in values on every iPhone in its program. The iPhone 16 Pro dropped from $630 to $510, a 19 percent cut. The 16 Pro Max fell $110 to $610, a month after Apple had raised it. The iPhone 17 Pro and 17 Pro Max appeared on the list for the first time at $785 and $885. This is not a one-off. Across the iPhone 15, 16, and 17 launches, about three quarters of models tracked lost value between announcement day and release day, and Apple's own program is usually the floor, not the ceiling.

The floor is the problem. Apple's number is convenient and it is store credit against a new phone. The independent buyback market is a different market, and the site I send people to is cashmycell.com. Full disclosure first: CashMyCell is a startup I have worked with closely, so I know the team and how the product is built, and you should weigh my recommendation with that in mind. It is also why I am comfortable putting my name next to it.

CashMyCell is a price comparison marketplace, not a buyer itself. It pulls live offers from multiple vetted buyback companies, shows them side by side, and lets you pick. When I checked while writing this, it listed an iPhone 16 Pro at up to $870 from third-party buyers, against Apple's $510 as of today. That is not a subtle gap. The site's own claim is that the same phone can differ by more than $100 between buyers, and the numbers above suggest that is conservative. Payment is real money over PayPal, Venmo, Zelle, or bank transfer, the buyer sends a free insured shipping kit, and payout is typically within 24 to 48 hours of the device passing inspection. Every buyer on the platform is vetted on background, BBB rating, and customer reviews before it is listed, which is the part I have seen up close and the reason I trust the offers on it. It also has a depreciation calculator that shows what your specific model has lost since launch, which is a useful reality check before you decide whether to sell at all.

The rule I follow, and the same rule CashMyCell gives on its own site: sell before the next generation ships, not after. The value cliff is between announcement and release. We are inside that window right now. The 18 Pro arrives Friday. The Duo pre-orders open October 16. If you are upgrading to either, get your quotes this week, lock the best one, and ship the old phone the day the new one arrives.

Three practical notes from doing this a dozen times:

Compare before you accept Apple's offer. Apple is a fine fallback and the safest option if you do not want to deal with shipping. It is rarely the best number.
Condition grading is where buyers make their margin. Be honest in the quote and photograph the phone before it ships. A locked quote from a vetted buyer with a real returns policy is worth more than a slightly higher one from someone you cannot find on the BBB.
Wipe it yourself. Sign out of iCloud, turn off Find My, erase all content and settings. Do not rely on the buyer's data-wiping process, even a good one.

The short version

The iPhone 18 Pro is an iterative update with a genuinely new chip, camera, and modem. If you are on a 15 Pro or older, buy it. $1,199 and $1,299, in stores September 18.
The iPhone Duo is a durable, heavy, well-built first foldable that gives up Face ID, the telephoto, and the Action button, and costs $1,999. Buy it for the form factor or wait for the second one. Ships October 23.
Apple's AI is finally usable and still not Apple's. Siri AI is a beta, English-only, EU-excluded, and built with Google's models, two years after it was promised. The hardware is ahead of the software and the model team is smaller than it was. Expect on-device to get good and cloud to stay rented.
Your old phone lost value this morning and loses more on Friday. Compare offers on cashmycell.com before you take Apple's number. I have worked closely with that team and I would bet on it.

I will revisit the Duo once I have used one for a month, and I will revisit Siri AI when it leaves beta. If Apple's own models close the gap before then, I will say so, and I will be glad to.

MVP Development Cost in 2026: Real Numbers From Someone Who Builds Them

Kunal Vohra — Fri, 11 Sep 2026 12:00:00 +0000

In 2026, a real MVP costs anywhere from $5,000 to $150,000 or more. The range is that wide because "MVP" means different things to different builders, and because most of the price is decided by two things founders rarely see up front: who controls the scope, and who owns the technical decisions.

I'm Kunal Vohra. I've been the technical co-founder six times, and my team and I build MVPs for startups priced per screen, so I see these numbers from the inside. Here is the honest breakdown.

How much does MVP development cost by builder type?

The market in 2026 sorts into five lanes, and the price differences are mostly about overhead and incentives, not quality.

Offshore agencies: $15,000 to $50,000. Established agencies in India, Eastern Europe, and Latin America quote fixed-scope builds in this band for a typical two-sided app. The quote looks complete; the change requests are where the real bill lives.

US and Western European agencies: $50,000 to $150,000+. Same software, different payroll. You're paying for proximity, polish, and project managers. For a funded startup that needs a warranty-grade vendor, sometimes worth it. For a pre-seed founder, usually not.

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 problem is that non-technical founders cannot tell which one they hired until it's late.

No-code and AI-assisted builds: $500 to $10,000. Real option in 2026, and I say that as someone who builds 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 anything the platform didn't anticipate.

Per-screen pricing, which is how I do it. Every screen of your product is counted and quoted during a scoping week, and the total is the screen count times the rate. As of late 2026 I'm holding my rate at $30 a screen (standard is $80) across mobile, web, desktop, and Linux. A typical 25-to-40-screen MVP therefore lands at a number a founder can compute themselves before anything is built. No day rates, no surprise change-request invoices; a new screen is simply one more unit at the same price.

The five factors that actually move MVP cost

Scope discipline, not features. The most expensive sentence in software is "while we're at it." Every builder charges for scope creep; the honest ones make the unit of scope visible up front. That's the entire argument for per-screen pricing: the unit is something a founder can see and count.

Who owns the architecture. An MVP built without senior technical ownership is cheap until the first rewrite. This is where MVP cost and fractional CTO economics meet: architecture mistakes at week 3 become five-figure bills at month 6.

Backend complexity you can't see. Screens are countable; the machinery behind them varies. Payments, real-time features, AI pipelines, and third-party integrations are where identical-looking apps diverge in effort. A scoping week exists to surface exactly this before the quote, not after.

Design maturity. Arriving with finished designs saves real money. Arriving with a napkin sketch is fine too, but then design is part of the build and belongs in the quote. Beware quotes that don't say which assumption they made.

Timeline compression. A 9-to-11-week build is the honest pace for a real MVP. Halving that doubles the team, and doubling the team more than doubles the cost. Anyone promising a full product in three weeks is either redefining "product" or borrowing from your post-launch stability.

The hidden costs nobody puts in the quote

Post-launch support is the big one: the first two weeks after launch always surface issues, and if support isn't in the contract, it's billed hourly at the worst possible moment (mine includes two weeks of post-launch support because that's when founders need the phone answered). Then infrastructure ($100 to $500 a month for a typical early-stage stack), app store and legal basics, and the quiet one: the cost of a codebase your next engineer refuses to inherit. Ask any prospective builder who will maintain the code after handover, and watch how they answer.

When you should NOT pay for MVP development

Building is not validating. If you have no evidence anyone wants the product, spend $0 on development and validate with a landing page, a waitlist, or twenty honest conversations first; I've written about what actually killed the startups I co-founded, and "built too much too early" is a recurring cause of death. And if what you really need is a technical partner who lives the venture with you, that's a technical co-founder conversation, not a development quote.

Frequently asked questions

How much does an MVP cost in 2026? Realistically $5,000 to $150,000+ across the market: freelancers $5k to $30k, offshore agencies $15k to $50k, Western agencies $50k to $150k+. My per-screen model prices a typical 25-to-40-screen MVP at the screen count times the published rate, computed before the build starts.

How long does MVP development take? A real MVP takes 9 to 11 weeks: a scoping week, then design and development with weekly visibility, then handover with post-launch support. Faster is possible by cutting screens, not by cutting corners.

What is per-screen pricing? Every screen of the product is counted during scoping and priced at a flat rate, so total cost equals screens times rate. It makes scope visible and change costs predictable: adding a screen adds exactly one unit of cost.

Is no-code cheaper than custom development? Up front, yes. Over two years, often not: platform fees scale with users, and most funded startups end up paying for the custom rebuild anyway. Use no-code to validate; go custom when the product is the business.

Do I need a CTO to build an MVP? Not a full-time one. You need senior technical ownership of the architecture and vendor decisions, which is exactly what a fractional CTO provides during a build. Without it, you can't evaluate what you're buying.

If you want a number for your specific product, my MVP development page explains the scoping week and the per-screen model, and a 30-minute call gets you an honest read on whether you should even build yet. Get in touch.

What Is a Fractional CTO? The Role, Explained by One

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

A fractional CTO is a senior technology executive who leads your company's engineering part-time, usually 2 to 3 days a week, instead of joining full-time. You get CTO-level judgment on architecture, hiring, security, and technical strategy at a fraction of the roughly $260,000 a year a full-time startup CTO costs in the US.

That's the definition. I'm Kunal Vohra, I work as a fractional CTO for AI-first startups, and I've been the full-time technical co-founder six times before that. So rather than another abstract explainer, let me tell you what this role actually looks like from inside it.

Fractional CTO meaning: "fractional" refers to time, not seniority

The "fractional" in fractional CTO means you're getting a fraction of the person's week, not a fraction of a CTO. The seniority is the whole point. Startups engage someone who has already built and scaled systems, then rent exactly as much of that experience as their stage needs.

The confusion I see most often is founders assuming fractional means junior, or advisory-only, or "a consultant who bills by the hour and disappears." A good fractional CTO owns outcomes. When I take an engagement, the architecture decisions, the security posture, and the engineering hires are my responsibility, exactly as they would be for a full-time CTO. The difference is the calendar, not the accountability.

What does a fractional CTO actually do?

The short answer: the decisions that are expensive to get wrong. In a typical week across my engagements, that means some mix of the following.

Technical strategy and architecture. Choosing what to build versus buy, designing systems that won't need a rewrite at 10x scale, and killing overengineering before it eats the runway. Most early startups don't fail from too little technology; they fail from spending on the wrong technology.

Engineering hiring and team building. Writing the job specs, interviewing for real signal instead of leetcode theatre, and setting up the code review and deployment discipline that makes the first five engineers productive. I've hired for six startups; the patterns repeat.

Security and compliance posture. This one is personal: my M.Tech is in cybersecurity. For AI-first products especially, security design cannot be retrofitted after users have an incentive to probe you. A fractional CTO makes those calls on day one, when they're cheap.

Vendor, AI, and due diligence judgment. Evaluating what AI-generated code can be trusted, which vendors are load-bearing, and answering investors' technical due diligence without the founders sweating through it.

Being the adult in the room on Fridays. When the deploy breaks or the demo is tomorrow, someone senior picks up the phone. That's part of the job, and any fractional CTO who treats it as out-of-scope is doing advisory, not the role.

What a fractional CTO is not

Not a freelance developer: you're paying for judgment and leadership, and code-writing is occasional, not the core. Not a technical advisor: an advisor gives you an hour or two of opinions a month, while a fractional CTO owns outcomes inside your team. And not a technical co-founder: a co-founder takes equity and lives the venture with you, which is a different commitment I've written about separately. The right choice depends on your stage, and sometimes the honest answer is that you need one of the others.

How does a fractional CTO engagement work?

Most engagements run as a monthly retainer sized in days per week. Mine are structured as 2 to 3 days a week for hands-on engagements, or a lighter advisory cadence for teams that mostly need direction. The market typically prices this between $4,000 and $15,000 a month depending on scope and seniority, and most providers won't publish their number. I do: my rates and how they're structured are on my pricing page, because the whole arrangement works better when nobody is guessing.

A well-run engagement has a shape: the first weeks are an audit (codebase, team, security, roadmap), the first quarter establishes the architecture and hiring plan, and after that the cadence settles into strategy, reviews, and the occasional fire. If a fractional CTO can't describe what your first 30 days would look like, keep interviewing.

When do you actually need one?

You likely need a fractional CTO if at least one of these is true: you're a non-technical founder making technical decisions you can't evaluate; your product got built by an agency or by AI tools and nobody owns the architecture; you're heading into a fundraise and technical due diligence is coming; your first engineers need someone senior to hire, structure, and review them; or security and compliance just became real because customers started asking.

You likely do NOT need one if you're pre-product with no users (validate first, then build), or if you already have a strong senior engineer who just needs an occasional sounding board (that's an advisor), or if what you actually need is someone to build the product itself (that's MVP development, a different service with different economics).

Frequently asked questions

What is a fractional CTO in one sentence? A part-time chief technology officer: senior technical leadership 2 to 3 days a week, with full ownership of architecture, security, and engineering decisions, at a fraction of a full-time hire's cost.

How much does a fractional CTO cost? Market hourly rates run $150 to $350, and monthly retainers typically run $4,000 to $15,000. I publish my own pricing openly on my fractional CTO cost and rates page.

Fractional CTO vs interim CTO: what's the difference? An interim CTO is full-time but temporary, usually bridging a departure. A fractional CTO is part-time and ongoing. If your CTO just quit three weeks before a board meeting, you want interim; I've done that bridge and it's a different rhythm.

Can a fractional CTO work with an existing engineering team? Yes, and it's often the best setup: the team keeps building, and the fractional CTO supplies the architecture direction, review discipline, and hiring judgment the team hasn't needed until now.

How long do engagements last? The ones that work tend to run 6 to 18 months: long enough to build the team and systems that eventually make the role unnecessary. A fractional CTO whose plan doesn't include making themselves replaceable is selling dependency.

If this sounds like the gap in your company, my fractional CTO page explains exactly how I work, what the first month looks like, and what it costs. If you are weighing this against a full-time hire, I compared the two in fractional CTO vs full-time CTO. And if you're still deciding between a co-founder, an advisor, or a fractional CTO, reach out and I'll give you the honest read, even if the answer is "not me yet."

AI Startup Technical Due Diligence: What Investors Actually Check

Kunal Vohra — Wed, 09 Sep 2026 12:00:00 +0000

Technical due diligence on an AI startup now covers four things beyond the standard checklist: whether your unit economics survive scale, whether you can prove quality is improving rather than guessing, whether a single model vendor can sink you, and whether your AI features are a security liability nobody has looked at. Get caught flat on any of these mid-diligence and the round slows down or the terms move against you. Fix them before the call and diligence becomes a formality.

I run ColadAI, a production multi-LLM platform, hold an M.Tech in Cybersecurity with published research, and have sat on both sides of this conversation: preparing companies for diligence as a technical co-founder and fractional CTO, and being asked these questions myself. This is what actually gets checked, not the generic due diligence checklist with "AI" pasted on top.

Inference economics: the question that decides if the business works at all

What gets asked: what does it cost to serve one active user, and does that number improve or worsen as usage grows?

This is the single most common gap I see walking into a diligence conversation. A feature that costs $0.40 per user session is a rounding error at 200 users and a fatal number at 50,000. Founders who have not modelled this per feature, before the round, get asked the question live and do not have an answer, which is a worse position than having a bad number with a credible plan to fix it.

What a strong answer looks like: a per-feature cost breakdown, a stated trajectory (falling, flat, or rising, and why), and at least one concrete lever already pulled: routing cheap requests to smaller models, caching, or cutting context that is not earning its place. I have taken a real seed-stage company's cost per active user down roughly 70% with exactly these three levers, inside the scope of a standard retainer, not a special project.

What a weak answer looks like:"we'll optimise that once we have more usage data." Diligence partners have heard this enough times to know it usually means nobody has looked yet.

Eval rigour: proving quality changes, not asserting them

What gets asked: how do you know a prompt or model change made the product better, and can you show the evidence?

If the answer is "we tested it and it felt better," that is not an answer a diligence partner can write down. Investors are increasingly aware that AI products can regress silently: a prompt tweak that fixes one case and quietly breaks three others, shipped because nobody had a way to catch it before customers did.

What a strong answer looks like: a golden dataset, an offline scoring process, and a regression suite that runs before changes reach production. It does not need to be elaborate. It needs to exist and be described specifically, with an example of a change it actually caught.

What a weak answer looks like: confidence with no artefact behind it. This is one of the fastest gaps to close before a raise, and one of the most commonly skipped, because it does not feel urgent until someone asks for it in a data room.

Vendor and model dependency: the single point of failure question

What gets asked: what happens to your product if your primary model provider raises prices, changes rate limits, or deprecates the model you are built on?

A startup with its entire product wired directly to one model provider, with no abstraction layer and no tested fallback, is one pricing change or deprecation notice away from a bad quarter. Diligence increasingly treats this the way infrastructure diligence has always treated a single point of failure: as a real risk to price into the round, not a hypothetical.

What a strong answer looks like: an abstraction layer between the product and any one provider, a documented fallback with a measured quality delta, and a stated position on data rights and retention for every model provider in the stack.

What a weak answer looks like:"we'd deal with it if it happened." That is the answer that turns a vendor incident from a degraded hour into a dead product, and diligence partners who have seen a portfolio company go through exactly that will probe until they get past it.

AI security: prompt injection is no longer a hypothetical question

What gets asked: if your product reads untrusted input and can take an action (call a tool, hit an API, touch a database), what stops a malicious input from making it do something it shouldn't?

Prompt injection is the vulnerability class most AI builders have not priced in, and it is exactly the kind of question a technically literate diligence partner now asks directly, because it has stopped being theoretical. I have published on this, and the pattern I see in unprepared founders is a genuine surprise that the question is being asked at all, which is itself a signal to the investor.

What a strong answer looks like: defined trust boundaries between untrusted input and any tool-calling capability, scoped-down credentials for anything the model can invoke, and a specific answer about what the worst case looks like if the boundary fails.

What a weak answer looks like: treating the model's own instructions as the security boundary. They are not, and a diligence partner with security literacy will know that immediately.

The parts of standard technical diligence that still apply, unchanged

AI-specific risk does not replace the fundamentals, it sits on top of them. Diligence still covers:

Code quality and review discipline , with a specific new wrinkle: teams shipping mostly AI-generated code without a senior review layer accumulate debt faster than teams writing it by hand, and diligence partners are starting to ask about this directly.
Team technical depth relative to the roadmap. Can the people in the room actually build what the deck describes, or is the technical narrative outrunning the team.
Security posture beyond the AI layer : access management, secrets handling, and the same infrastructure hygiene any company gets asked about.
Scalability of the architecture , independent of the AI components, if usage grows 10x.

Skipping straight to AI-specific questions without covering these first is a sign of a diligence process that is not thorough yet, not a sign you are safe.

How to prepare for this before the call, not during it

The mistake I see most often is founders treating diligence prep as a documentation exercise the week before term sheets go out. The actual fix is building the answer into the product months earlier, so the diligence conversation is a description of something real rather than a scramble to produce evidence of it.

Concretely, before you are in a room: have a per-feature cost model, even a rough one, updated monthly. Have an eval process that has actually caught a regression, so you have a real example to describe. Have an explicit answer, in writing, for what happens if your primary model provider has a bad week. And have thought through, specifically, what your product's worst-case prompt injection scenario looks like, even if the fix is still in progress.

None of this needs to be perfect. It needs to be real, current, and something you can describe in one paragraph without hedging.

Frequently asked questions

Do early-stage AI startups actually get this level of technical diligence, or is this only for later rounds? It is showing up earlier than founders expect, including at seed. Investors who have been burned by a portfolio company's inference costs or a security incident are now asking these questions before the check is written, not after.

Can a fractional CTO or AI officer help prepare for this specifically? Yes, and it is one of the most common reasons founders bring me in ahead of a raise. I prepare the technical narrative and fix what will not survive scrutiny before the diligence call, not during it, the same approach I use for enterprise security reviews. If the gap is specifically in the AI layer, the fractional AI officer role covers this directly; if it spans the whole engineering organisation, that is a fractional CTO for AI startups engagement.

What is the single highest-leverage thing to fix before diligence if I can only fix one? Inference economics, in almost every case. It is the fastest to model, the easiest to demonstrate progress on, and the one investors treat as a proxy for whether the founders understand their own business at the unit level.

Is prompt injection really a dealbreaker in diligence, or a minor point? It depends on the diligence partner's technical depth, but the trend is toward it mattering more, not less, especially for any product where the model can take actions rather than just generate text. A founder who has clearly thought about it, even without a finished solution, reads very differently from one who has not considered it at all.

Does this apply if we are not really an "AI startup," we just use AI for one feature? Apply it to that one feature specifically rather than the whole company. A single AI feature with unpriced inference cost, no eval process, and no thought given to injection is still a real, specific risk a diligence partner can find, even in a company that would not describe itself as AI-first.

If you are heading into a raise and want a straight read on whether your technical story survives diligence, book a call and walk me through the product. I would rather tell you what will get asked now than have you find out from an investor first.

Case Study: The EdTech Problem So Hard We Built Our Own OS for It

Kunal Vohra — Sun, 06 Sep 2026 12:00:00 +0000

I can't name this product. It operates in a corner of edtech where being identified too early is a competitive risk, and we're not done growing yet. So this case study is anonymized: no product name, no client names, no exact revenue. Everything else is real.

What I can tell you is why nobody had built it before us, how we built it, what broke along the way, and what it looks like when a product starts working well enough that your competitors stop ignoring you and start calling you.

The problem nobody wanted

Edtech has a handful of famous problems that everyone piles onto: content delivery, engagement, test prep, admin software. Then there are the problems everyone in the industry knows about, complains about, and quietly steps around.

This was one of those. It had stayed unsolved for a simple, unglamorous reason: it didn't fit inside any one engineer's skill set.

Solving it properly needed operating-system-level Linux work and it needed a modern web application. It needed DevOps that could survive real institutional environments, not just a clean cloud deployment. It needed Python for the data and AI side. It needed serious security thinking, because the whole point of the product only holds if it can't be trivially defeated. And in places where the standard protocols didn't do what we needed, it needed new ones designed from scratch.

By the time we shipped, the codebase spanned seven programming languages. That's not something I'm bragging about; in most products, seven languages is a smell. Here it was the honest shape of the problem. Web stacks don't speak to network layers, network layers don't speak to AI pipelines, and the glue between them is where all the hard work lived.

That breadth is exactly why the problem sat untouched. A web team would look at it and see the systems work they couldn't do. A systems person would see the product and AI work they couldn't do. An agency would quote it, sign it, and drown. It needed one team, with one person who could hold the whole picture, willing to go deep in every layer at once.

That's the gap we walked into.

What we built

The short version: an edtech product that sits close to the infrastructure, watches what actually happens rather than what people report, uses AI where patterns are too messy for rules, and reports to the people who need to act on it.

The build drew on the full stack, in the literal sense:

A Linux-based OS, built from zero. Not a hardened distro with our app on top: our own operating system, with the code built and ported across targets including mobile Linux. This is the layer that made most teams walk away, and it's where the defensibility lives.
MERN for the application layer: the dashboards, the workflows, the parts humans touch every day.
Python and AI for the analysis: separating signal from noise in data that has no clean labels and no textbook structure.
Custom protocols where existing ones didn't fit. Designing a protocol sounds glamorous; in practice it's weeks of boring edge cases. But when off-the-shelf doesn't do the job, you either design or you compromise the product.
Security as a design constraint, not a feature. My M.Tech is in cybersecurity, and this is the project where that background stopped being a credential and started being the roadmap. A product like this gets probed by the very people it serves. If it only works against honest users, it doesn't work.
DevOps built for hostile terrain : institutional networks, inconsistent hardware, environments where you don't control the machines you run on.

And then there was the part no job description covers: the hardware. Software people like to stop where the device begins. We couldn't. We sat with the manufacturers themselves, in their facilities, to understand their equipment from the inside, then integrated our SDKs with theirs. More than once, when their side didn't do what the integration needed, we wrote the code for them. That's what it takes to ship software that has to work on hardware you don't make: you go to where the hardware is made.

The hardest part

The hardest part was never one layer. Any competent specialist could have built any single piece of this. The hard part was that every layer constrained every other one, and no decision could be made in isolation.

The protocols were the clearest example. Designing a protocol sounds glamorous from the outside. In practice it was weeks of boring edge cases: what happens on flaky institutional networks, what happens when a machine dies mid-run, what happens when someone actively tries to game the exchange. Every one of those answers rippled into the systems layer, the application layer, and the AI pipeline at once.

And underneath all of it sat the security constraint: this is a product whose own users have an incentive to probe it. Every convenient shortcut we considered, we had to evaluate as an attacker first and an engineer second. That discipline slowed us down for months. It's also why the product held up when it mattered.

What almost broke it

After all the protocol design and the security reviews and the seven languages, the thing that nearly took us down was one line.

A single line in our AWS load balancer configuration was wrong. Not the AI, not the custom protocols, not the systems layer everyone said was too hard: a small, boring line in the infrastructure that everything else stood on. It failed initially, quietly, the kind of mistake that does nothing in a small test and everything in a big one. Under the load of a real run it would have taken the product down in front of the exact audience we had spent years preparing for.

We found it at the last moment. Everyone around us had been wishing us luck for the launch; catching that line was the blessing they were all wishing for, arriving in its actual form. Luck in production looks like someone rereading a config file one more time.

That's the honest lesson of the whole build: breadth got us to the run, discipline got us through the review, and the thing that decides the day is still whoever checks the last boring line.

Where it is now

For years, the organisations we now serve had no choice but to buy this capability from outside vendors, at a hefty price, because nothing purpose-built existed. We started the same way ourselves: running on old software stitched to third-party tech, where a big run meant working in the thousands. That was the ceiling, and everyone in the space had learned to live with it.

Then our own product was ready. The first time we ran it at full confidence, we ran 500,000 assessments in one go. In a single hour.

Not a benchmark in a lab. A real run. From "thousands, carefully" to half a million in sixty minutes is not an optimisation, it's a different category of product, and it's the moment every layer of that seven-language stack paid for itself at once. The systems work, the custom protocols, the DevOps built for hostile terrain: that's what they were for.

Beyond that run, the product is doing better in the industry than we ever projected. We set targets we thought were ambitious, and reality has been embarrassing them.

And there's a second signal I've come to trust more than any dashboard: the competition found my number. Companies in the space keep reaching out with genuinely attractive offers: acquisition interest, partnership structures, roles. I take those calls politely, and I hold my horses. When incumbents try to buy the thing you built in a space they said wasn't worth building in, that's not a distraction. That's the market grading your work.

What this project taught me

Unsolved problems are often staffing problems in disguise. This one didn't need a genius. It needed breadth: someone who had done Linux and web and DevOps and AI and security for real, and could design across all of them at once. If a problem in your industry has stayed open for years, ask whether it's actually hard or whether it just doesn't fit the shape of the teams that looked at it.

Breadth is a moat. Features can be copied in a quarter. A stack that spans seven languages and custom protocols, built to survive adversarial users, cannot. Our defensibility was never one clever idea; it's the accumulated systems work competitors would have to repeat.

Security can't be retrofitted onto a product whose users will attack it. We designed for the hostile case from day one. Every shortcut we refused early is a breach we didn't have later.

Hold your horses when the offers come. The first acquisition interest arrives exactly when the product starts compounding. Selling at the first flattering number means selling right before the curve you worked years to reach.

This is the kind of build I take on as a technical co-founder and the kind of judgment I rent out as a fractional CTO for AI-first startups: the calls about what to build, what to design from scratch, and which problems are more solvable than they look. If your industry has one of these "nobody touches it" problems, I'd like to hear about it.