This is not an argument against vibe coding. It is a look at what the actual 2026 research shows, what the real breaches have in common, and a concrete checklist for doing it in a way that does not end with your users' data in a security researcher's disclosure report.

What is vibe coding, exactly?

Vibe coding is building software by describing the outcome you want in natural language and letting an AI coding agent generate, run, and often deploy the code, with the person directing it reviewing the result rather than writing the implementation line by line. It is different from AI-assisted coding in degree more than kind: a developer using autocomplete still reads every line before it ships, while vibe coding often means the model's output goes straight to a working, sometimes publicly deployed, application with minimal human reading in between.

That speed is the entire appeal. It is also exactly why the security problems below exist. When nobody reads the code, nobody catches the missing authorization check.

So, is vibe coding safe? The honest answer

Vibe coding is safe for the things it is good at: scaffolding a UI, wiring up boilerplate, standing up a prototype to test an idea, or building an internal tool where the blast radius of a mistake is small. It is not safe, in its default "describe it and ship it" form, for anything that touches authentication, payment, personal data, or business logic where a wrong answer costs money or trust.

The reason is not that AI models are bad at writing code. It is that they are trained to produce code that runs and looks correct, not code that has been adversarially tested against a user who is trying to break it. Those are different skills, and most vibe coding workflows only exercise the first one.

What the 2026 research actually shows

The numbers are consistent across every group that has measured this independently, which is usually a sign the underlying pattern is real rather than a single flawed study.

• Veracode tested more than 100 large language models across 80 coding tasks and found that 45 percent of the AI-generated code contained security flaws.
• Across the broader body of 2026 research, 40 to 62 percent of AI-generated code contains at least one security vulnerability, and AI-written code produces flaws at roughly 2.74 times the rate of human-written code on comparable tasks.
• Escape scanned 5,600 publicly deployed vibe-coded applications and found more than 2,000 high-impact vulnerabilities, over 400 exposed secrets, and 175 instances of exposed personal data, all live in production. Roughly 2,000 of those applications had sensitive data behind no authentication, no access controls, and no audit trail at all.
• Georgetown's Center for Security and Emerging Technology found that 86 percent of AI-generated code samples failed basic XSS defense mechanisms across five major models.
• AI-assisted commits expose hardcoded secrets, API keys, credentials, at roughly twice the rate of human-written commits (about 3.2 percent versus 1.5 percent).
• Georgia Tech's Vibe Security Radar tracked 74 confirmed CVEs directly caused by AI-generated code by March 2026, with 35 of those disclosed in March alone, up from just six in January. The trend line is accelerating, not stabilizing.
• Developers using AI assistance ship commits three to four times faster than their peers, but introduce security findings at roughly ten times the rate.

Put together, this is not a story about one careless team or one bad model. It is a structural pattern: velocity goes up, review does not keep pace, and the gap shows up as vulnerabilities.

Why AI-generated code fails in specific, predictable ways

The failures are not random. They cluster around a handful of root causes that show up again and again once you look at real incidents.

• Missing or broken authorization checks. The code runs, the feature works, and it never asks "is this specific user allowed to see this specific record." This is the single most common root cause behind real breaches.
• Hallucinated dependencies. Models sometimes reference packages that do not exist yet. Attackers have started registering those exact package names, so the "helpful" import becomes a supply chain attack the moment someone else's AI suggests the same hallucinated package.
• Secrets shipped to the client. API keys and database credentials end up directly in client-side JavaScript because the model does not reason about the trust boundary between a browser and a server the way an experienced engineer would.
• Row-level security left disabled. Modern backends like Supabase and Postgres support fine-grained access policies, but they are opt-in. AI-generated backend code frequently skips enabling them, leaving every row in a table readable by anyone with the (often exposed) API key.
• Prompt injection against the agent itself. When an AI coding agent has access to a database, file system, or production environment, malicious input, sometimes hidden in a support ticket, a file name, or a webpage the agent reads, can redirect what the agent does next.
• Over-permissioned agents. Giving an autonomous coding agent broad database or infrastructure access "to save time" removes the one guardrail that would have contained a mistake to something recoverable.

Real incidents that show what is at stake

These are not hypothetical risks. They happened in 2026, they were publicly disclosed, and they all trace back to the same handful of causes above.

Moltbook. Launched January 28, 2026 as an AI social network where autonomous agents interact with each other. Its founder said publicly that he did not write a single line of code himself. Within three days, security researchers found the production database fully exposed: 1.5 million API authentication tokens, 35,000 email addresses, and private messages between agents, all reachable because the Supabase API key had been shipped in client-side JavaScript with row-level security never enabled.

Tea. A women's safety app that suffered a breach leaking 72,000 user IDs and selfies, traced to broken authentication and access-control logic that AI generated and nobody reviewed before it reached real users.

Lovable. A vibe coding platform itself, valued at 6.6 billion dollars with 8 million users, has had three documented security incidents exposing source code, database credentials, and user records. The most recent, a broken object-level authorization (BOLA) vulnerability, sat open for 48 days after disclosure.

Replit. An AI coding agent given standing database access performed a destructive operation on its own and wiped a user's production database, a stark example of why agent permissions need hard limits, not just good intentions.

Every one of these started the same way: a working prototype, shipped fast, with nobody reading the part of the code that decided who was allowed to see what.

Vibe coding best practices: the checklist

None of this means avoid vibe coding. It means vibe code the way you would manage any other fast, capable, occasionally wrong contractor: with a process that catches mistakes before they reach production.

• Write the requirements before the first prompt. A short PRD, what the app does, the user flows, the data model, the edge cases, turns a vague request into a specific one and gives the AI something concrete to follow instead of guessing.
• Treat every AI-generated line as unreviewed third-party code. Read it. Test it. Run static analysis on it before it merges. That single habit would have caught the majority of the vulnerabilities in every study above.
• Make secret scanning non-negotiable in CI/CD. Hardcoded credentials are one of the most consistent findings across all vibe coding security research, and one of the easiest to catch automatically before a human even looks.
• Ask for secure defaults explicitly. Prompting for parameterized queries, input validation, and least-privilege access by name measurably reduces the flaw rate, because the model will produce them when asked even though it often will not by default.
• Enable row-level security and access controls from the first commit, not as a pre-launch checklist item. Retrofitting access control onto a schema that has been live for months is where the Moltbook-style exposures happen.
• Layer your prompts. Ask for the data model and function signatures first, review those, then ask for the implementation. Reviewing the skeleton catches structural mistakes before they are buried inside a thousand lines of working-looking code.
• Choose a boring, widely-used tech stack. Models produce measurably cleaner code with frameworks they have seen thousands of times in training. Novelty is where hallucinated dependencies and unusual failure modes concentrate.
• Give coding agents the least access they need, and nothing destructive by default. An agent that can propose a migration is very different from an agent that can run one against production. Keep those permissions separate and require a human step in between.
• Know what to hand to a human. Use vibe coding freely for UI, CRUD, and prototypes. For authentication, payments, permissions, and anything touching regulated or sensitive data, get a second, security-literate set of eyes before launch, regardless of how confident the output looks.
• Keep an audit trail. If you cannot answer "who accessed this record and when" after the fact, you will not catch a breach until someone outside your company tells you about it, the way it happened for Moltbook, Tea, and Lovable alike.

Frequently asked questions

Is vibe coding safe for production apps?

Not by default. Studies from Veracode, Escape, and Georgia Tech's Vibe Security Radar consistently find that 40 to 62 percent of AI-generated code contains at least one security vulnerability. Vibe coding can be safe for production if every piece of AI-written code goes through the same review, testing, and static analysis you would apply to code from a contractor you have never met. Skipping that step is what turns a fast prototype into a breach.

What is the single biggest vibe coding security risk?

Missing or broken authorization checks. Compilers and AI models both happily produce code that runs correctly while forgetting to verify who is allowed to see or change what. It is the root cause behind the Moltbook, Tea, and Lovable incidents, and it will not show up in a quick manual test unless you deliberately try to access data as the wrong user.

Can vibe coding cause a real data breach?

Yes, and it already has more than once in 2026. Moltbook exposed 1.5 million API tokens and 35,000 emails within three days of launch. Tea leaked 72,000 user IDs and selfies. Lovable, the vibe coding platform itself, has had three separate incidents including a BOLA vulnerability that sat open for 48 days. None of these were sophisticated attacks: they were AI-generated access-control logic that nobody reviewed.

Do I need a professional developer to vibe code safely?

You need a human who owns the security and correctness of what ships, whether or not that person writes code by hand. For UI scaffolding, CRUD screens, and prototypes, a careful non-engineer following a checklist can vibe code responsibly. For authentication, payments, permissions, or anything touching real customer data, get someone with security judgment to review it before launch, even if the AI wrote every line.

Where Cafiyn™ fits in

We built Cafiyn™ around a simple bias: execution over theatre. Vibe coding is a theatre-prone category right now, impressive demos, fast launches, and a very real gap between "it works" and "it is safe" that most teams do not notice until someone else finds it for them.

Cafiyn™ AI is built to operate inside your business with permissioned, secure-by-design execution rather than open-ended access, because the Replit-style destructive-agent failure mode is exactly what we design against from the start. And when the question is not "can an agent help" but "is the thing we already vibe-coded safe to put in front of real customers," that is precisely the kind of hands-on, no-slide-deck work Cafiyn™ Biz exists for: a second set of experienced eyes on your authorization logic, your secrets management, and your access controls, before it becomes an incident report instead of a launch.

If you have shipped something fast and are not fully sure it would survive the kind of scan Escape ran on those 5,600 apps, that uncertainty is worth resolving before a stranger resolves it for you.

This piece is about the structure. The three rituals, the metrics that drive them, and the trap of inconsistent execution. None of this is exotic; the bar is lower than it sounds. The discipline is in doing it every week, without exception, for long enough that it stops being a special effort and becomes how the company operates.

The first ritual: the customer call review

Every week, the leadership team listens to three customer calls together. Not summarises; listens. Twenty minutes per call, with one person from sales, one from product, one from CS, and the CEO in the room. The calls are picked at random from the past week. There is no agenda beyond hearing what customers actually said.

This ritual works because it bypasses the layers of compression that customer feedback usually goes through before it reaches leadership. By the time a quarterly customer advisory board report lands on the CEO's desk, the rough edges have been sanded off. Listening to three random raw calls each week keeps the rough edges intact. The decisions made in the week after these reviews are consistently better than the decisions made by the same team a week before they started doing it.

The second ritual: the friction log

Every customer-facing function maintains a friction log. One line per friction point, dated, with the customer it came from. Sales logs the objections they could not answer. Support logs the problems they had to escalate. CS logs the requests that turned into save situations. Nothing fancy; a shared document that takes thirty seconds to update.

Once a week, the product team reviews the log. The patterns that show up across three or more functions get added to the roadmap discussion, and the ones that show up repeatedly in the same function get prioritised. The log makes friction visible enough to act on; without it, the same problems get encountered week after week, addressed individually, and never aggregated into a fix.

The cost of the log is genuinely tiny. The benefit, over a quarter, is the difference between a roadmap that reflects customer reality and one that reflects internal preferences.

Customer-first does not need more empathy. It needs more structure for the empathy you already have.

The third ritual: the at-risk standup

The last ritual is short and uncomfortable. Twenty minutes, weekly, the at-risk accounts get reviewed by a cross-functional group: CS, sales, product, support, with an executive in the room. Each account gets two minutes. What is wrong, what was tried, what is the one thing somebody outside CS could do this week to help.

The point is not to coordinate save activity; it is to make the company collectively responsible for retention. After three or four weeks of this, the upstream teams start noticing the patterns that produce at-risk accounts in the first place, and the inputs that produce churn start improving without anyone being told to fix them. (More on the framing in last month's piece on customer success as operations.)

The metrics that drive each ritual

Rituals without metrics drift. The three rituals each have one metric attached that the company watches weekly.

1. The call review drives time-to-decision-from-feedback. How fast does a pattern heard in a customer call show up as a change somewhere in the company? Should be days to weeks, not quarters.
2. The friction log drives repeat-friction-rate. What percentage of friction points logged this week were also logged last month? If the answer is high, the company is hearing customers but not changing.
3. The at-risk standup drives save-rate-by-non-CS-action. What percentage of saves came from an action taken by a function other than CS? If the answer is low, the company has reverted to treating retention as CS's problem.

None of these metrics are fancy. They are the kind that exist precisely to prevent the rituals from drifting into theatre.

The trap of inconsistent execution

The biggest threat to the structure is not skepticism; it is inconsistency. The most common pattern I see is leadership starting the rituals enthusiastically, finding them genuinely valuable for six weeks, and then quietly letting them slip when the quarter gets busy. The rituals work because they are weekly and unmissable. They stop working the moment they become optional.

The protection against this is to put them on the calendar as immovable. Same day, same time, every week, with the same people. If the CEO cannot make it, someone else in the leadership team runs it. If a quarter-end pulls leadership away, the rituals still happen and the leadership team gets the notes. The signal that "this is how we operate, not what we do when we have time" is what makes the structure durable.

What changes in six months

Six months in, the visible changes are striking. The product roadmap matches what customers ask for, with the gap explainable. Sales answers objections more confidently because they have heard them aggregated and the team has decided the response. Support escalates less because product has actually fixed the patterns that produced the escalations. Retention improves not because CS got better but because the upstream functions stopped producing customers who needed to be saved.

None of these changes feel dramatic in any single week. They compound. By month nine, leadership realises the company is making decisions on a different quality of signal than it was, and the metric the team most cares about, whichever it is, has moved more from this set of rituals than from any individual initiative.

If any of this sounds like work that needs to be designed for your specific company, that is exactly what Cafiyn™ Biz does. We embed with leadership teams and help shape the cadence to your actual context, then stay until it holds.

One thing to start this week

Pick one. The call review is the easiest to start and the hardest to maintain. The friction log requires the least leadership time. The at-risk standup produces the most visible retention impact. Whichever you pick, put it on the calendar this week, every week, for the next twelve. By week six you will know whether to keep going. (I would bet you keep going.)

Why three things, not one

The most common move for a new venture in this space would be to bundle. Pick the three things customers want, wrap them in a single sign-on and a single dashboard, and call it a platform. The pitch is easy. The TAM is enormous. The exit narrative writes itself.

We chose not to do that, and the reason is something I have seen up close in every operational platform I have ever worked with: the bundle eventually owns the company that buys it. The customer adopts the parts that fit, suffers the parts that do not, and is eventually too entangled to leave. The vendor's incentives shift from "be the best thing for this workflow" to "be the thing that makes leaving expensive." It is not malicious; it is just what bundle economics produce.

So we made the opposite trade. Three things that share a philosophy but not a database. Cafiyn™ OS for operational software, Cafiyn™ Apps for consumer-grade tools, and Cafiyn™ Biz for hands-on consulting. Each one earns its place independently. None of them lock you into the others. The cost is that we will never be the system of record for your whole company. The benefit is that we will never be the thing your team works around.

Why small

The other choice we made deliberately was to stay small. Not small as a phase, small as a posture. There is a particular kind of company that exists when the founders are still the people doing the work, when every customer is known by name, and when the team can fit in a single conversation. That company moves faster, ships better, and produces fewer regrets than the version of itself two years later, when it has tripled in size and lost the texture of its early decisions.

I have spent enough of my career inside large companies to know what their advantages are. I have also seen what those advantages cost: hours spent in alignment, decisions made in committees, products shaped by the median voice in the room. Small companies do not have those costs, and the longer we can resist accumulating them, the better the work will be. Eventually we will grow because we want to do bigger things, but we will resist growing for the sake of looking grown up.

Small is not a stage we are leaving behind. It is a posture we are trying to keep.

What "execution over theatre" actually means

"Execution over theatre" is the phrase we put on the wall, and it is easy to say without meaning it. What we mean by it, concretely:

• We measure ourselves on whether problems actually got solved, not on the polish of the deck that described them.
• We refuse to add features that demonstrate range but do not reduce friction.
• We pick a small number of customers and stay until results hold, instead of running through a high-volume funnel.
• We say no to logo deals that would look good on a slide but would not produce a real outcome.

The hardest of these is the last one. Theatre is seductive precisely because it is visible, and execution is mostly invisible until the result lands. We have turned down work that would have looked great in a press release because we could see that the engagement would not produce a real result, and saying yes to it would have started us down the path of being a consulting firm that optimises for logos. That path is one we have watched others walk; we are not going to walk it.

What this means for who we work with

The honest version is that we are not a fit for every company. Teams looking for a platform play, a swept-the-category vendor, or a consulting firm that ships a strategy and disappears will be happier elsewhere. Teams looking for sharp tools that earn their place, and operators who embed and stay until things hold, will find us a much better fit. That self-selection is exactly what we want.

If you read this and any of it resonated, the simplest next step is to tell us what is hard right now. We read everything that comes in, we reply, and we will be honest about whether we are the right people for what you are doing. If we are not, we usually know someone who is.

That is the manifesto. It is shorter than most, and we will be held to it by what we ship next. If we drift from it, we hope you will tell us.

They are not novel and they are not clever. They are the rules I wish someone had handed me ten years ago, before I learned them the slow way.

Rule one: the data model is the architecture

Of every architectural decision a system makes, the data model is the one that ages worst. Code can be rewritten in a quarter; the data model touches every team, every integration, and every historical record. By the time you discover the data model is wrong, you have ten thousand customers depending on it and changing it is a multi-quarter migration project.

The corollary is that the data model deserves more deliberate design time than almost any other part of the system. Not more layers; more careful thinking about what you are choosing to make easy and what you are choosing to make hard. Almost every painful migration I have been part of traced back to a data-model choice made in week two by someone who did not know yet what the system would have to do in year three.

The practical move: before you write any feature code on a new system, write out the data model on paper, hand it to two engineers who were not in the room, and ask them what they would have a hard time doing with it. The questions they raise are usually exactly the things you will hit in year two.

Rule two: observability before scale

Every team I have worked with regretted underinvesting in observability and none regretted overinvesting in it. The reason is structural: you cannot reason about a production system you cannot see, and you cannot debug at scale by reading code. The teams who built observability in early shipped fixes in minutes; the ones who deferred it shipped fixes in days, because they spent the day reproducing the issue locally.

The good news is that observability does not need to be expensive on day one. Structured logs, basic metrics on the four golden signals, and a tracing story for cross-service calls cover ninety percent of what you actually need. The cost is small, the value is enormous, and the time to add it is before you have a production incident, not after.

Rule three: tenancy is not a feature you can bolt on

I have watched two systems try to retrofit multi-tenancy onto a single-tenant codebase. Both projects took longer than the original system had taken to build. The reason is that tenancy is not a feature; it is a thread that runs through every query, every cache key, every background job, and every log entry. Retrofitting it means going through all of those and getting every single one right, with no margin for error because a single leak is a security incident.

If there is any chance the product will need to serve more than one customer with isolated data, design for it from day one. The cost on day one is modest. The cost in year three is enormous and risky.

The bills you cannot afford in year three are the ones you saved on in week three.

Rule four: integrations are first-class, not afterthoughts

The most successful enterprise systems I have worked on were good at integrations from the start. Not because they had every connector, but because they treated the integration surface as a first-class product surface. APIs were documented, webhooks were reliable, rate limits were sensible, errors were debuggable.

The reason this matters is that enterprise customers buy your system into a world that already has fifty other systems. If yours is the one that does not talk to them, you become the bottleneck regardless of how good your core product is. Conversely, a system that integrates beautifully gets adopted into workflows you did not even imagine, and those workflows compound your value over time.

The practical version: treat your own product team as the first user of your API. If they cannot build your most-used flows on top of your own public API, your API is not yet good enough.

Rule five: the migration story is part of the product

Every enterprise system replaces something. The thing it replaces has data the customer cares about. If your product does not have a credible migration story from the most likely things it replaces, you will lose deals to competitors who do, no matter how much better your core product is.

This is the rule I see violated most often in newer products. The team builds a great workflow, demos beautifully, and then loses every other deal because the customer cannot get their existing data in. The retrofit, when it eventually happens, is brittle and never quite works, because migration tooling is hard and was an afterthought.

If your product replaces something specific, build the migration as a real surface, with someone on the team who owns it. Treat it as a feature, not a service.

Why these compound

The rules are not independent. The data model decision constrains tenancy. The tenancy decision constrains observability. The integration surface depends on the data model being legible. The migration story depends on all four. Get one wrong and the others get harder; get them right and the system ages well.

This is the discipline behind how we build inside Cafiyn™ OS and the lens we bring to systems work in Cafiyn™ Biz. None of these rules are about being clever. They are about removing predictable categories of pain before the team has to live with them.

One thing to do this week

Pick the rule you most violated on your current system. Write down what it has cost you, honestly. Decide what you would do differently if you were starting over. That document, dated and saved, is the most useful thing your engineering team can carry into the next system.

The reason is that the AI-native competitors are now actually arriving. Not the demos; the real products, with real customers, in the workflows where the incumbents were strongest. And they look unrecognisable to anyone who is still bolting AI onto the old UI. The divide between AI-native and AI-bolted-on is no longer a stylistic distinction. It is becoming a moat, and it compounds in a way that is hard to recover from.

Why the divide is harder to close than it looks

Bolted-on AI lives at the surface of an existing product. The product was designed in a world where the user did the cognitive work, so the screens, the navigation, the data model, and the workflows all assume a human in every step. The AI assistant helps that human a little faster. Useful, but not transformative.

An AI-native product starts from a different question: what does this workflow look like if the model does the cognitive work and the human reviews? The answer is almost never the same product with a chat icon. It is fewer screens, more conversation, and a fundamentally different shape of work. Once a customer has experienced that shape for a workflow they care about, the bolted-on version of the same workflow feels old.

The reason this matters strategically is that it is much harder to remove the human assumptions from an existing product than it is to design without them in the first place. The data model is wrong. The permissions model is wrong. The UI is structured around steps the user no longer needs. Each individual rewrite is possible; doing them all without losing the existing customers is not.

Where the compounding starts

The compounding starts the moment an AI-native product reaches feature parity in any single workflow. Once it does, three things follow.

First, the AI-native pricing model usually undercuts the incumbent on the workflow in question, because the product is shaped around outcomes rather than seats. (See our note on outcome-based pricing for why this is more than a pricing detail.)

Second, the AI-native product gets faster, because its team is iterating on a smaller surface area built for a clearer thesis. The incumbent's team is iterating on a sprawling surface with a thesis written in 2018.

Third, talent. Engineers and product people increasingly want to work where the AI is the product, not where it is an icon. This is uncomfortable to talk about but real, and it is showing up in the hiring funnels of every company I work with.

Bolted-on AI competes on parity with other bolted-on AI. AI-native products compete on workflows that look impossible to anyone still designing for the manual world.

If you are an incumbent

The temptation, when an AI-native competitor shows up in one of your workflows, is to ship a faster bolted-on response. This rarely works because the AI-native company is iterating faster on the same workflow. You will not catch them with the same shape of product they have a head start on.

The harder move, but the only one I have seen work, is to pick one workflow and redesign it from scratch with AI at the centre. Treat that one workflow as a separate product, with its own team, own UI, own metrics, and own pricing if needed. Keep the bolted-on version of the rest of the product running for the customers who depend on it, but give yourself a real beachhead in the AI-native world. From that beachhead you can expand.

The companies that try to AI-redesign everything at once usually fail, because the political cost is too high. The companies that pick one workflow and go deep on it tend to surprise themselves with how quickly they can match the AI-native upstart on that workflow, while keeping the rest of the business intact.

If you are a founder

If you are building a new company, the bar is now genuinely higher than it was twelve months ago. "AI-powered" is no longer a positioning; it is table stakes. The honest question to answer is whether your product would still make sense if you removed the model entirely. If yes, you are bolted-on by another name and you will be competing with the incumbent's bolted-on version, which has distribution. If no, the product would only exist with a model in the loop, you have something genuinely new.

This is a higher bar than it sounds. Most "AI startup" pitches I read could be removed of their AI and still describe a sensible product. That is a warning sign, not a feature.

What this means for buyers

If you are buying software in 2026, the questions to ask vendors are different than they were even a year ago. Not "do you have an AI feature." Yes, everyone does. The questions are: which workflows have you rebuilt around AI, not just augmented? What does the cost-per-resolved-task look like for those workflows? How does the product behave when the AI is wrong, and how often is that?

The vendors with good answers will be the ones that survive the next two years intact. The vendors who answer with a tour of the chat icon will not.

The two-year window

The window for being the AI-native player in a category is small. A year from now, the categories that are going to consolidate around AI-native winners will mostly have done so. The incumbents that picked their one workflow and went deep will have a beachhead; the ones that shipped a faster icon will be defending shrinking share. The founders who staked out a real AI-native position will be raising at multiples that assume the moat is real, because by then it will be.

None of this is hopeful or doom-laden. It is the second derivative of the AI hype cycle finally hitting the products. We are about to find out which companies took the moment seriously and which ones treated it as marketing.

This is the lens we use when we work with leadership teams at Cafiyn™ Biz, and the principle behind every product we build inside Cafiyn™ OS and Cafiyn™ Apps. Less surface area, redesigned around what AI now makes free.

The framing is the actual problem. Customer success is not a department; it is an operational function that runs across sales, product, support and ops. When you treat it that way, the metrics change, the rituals change, and the team finally has the leverage it always needed.

Why the department framing breaks

A department owns its function. It hires for it, measures it, and gets rewarded for moving its number. The trouble is that the metrics customer success is measured on, retention and expansion, are produced by the entire customer journey, not by any one team. By the time the CS team meets the customer, the impressions formed in sales, the product fit decisions made in roadmap, and the support quality from week one have already loaded the dice.

If the CS team is held accountable for that outcome without the authority to shape the inputs, two things happen. They burn out chasing fires that started upstream. And the upstream teams stop owning customer outcomes because someone else is officially responsible. The structure produces exactly the wrong incentives.

What changes when you treat it as operations

Operational functions are different in kind from departments. They are responsible for an outcome that crosses teams, and their leverage comes from making the work of those teams visible and accountable, not from doing it themselves. Think of how a good operations function manages a manufacturing line: it does not build the product; it ensures the conditions for the product to be built well.

When CS is positioned this way, three shifts happen.

One: shared metrics

Retention is a company metric, not a CS metric. Sales gets a quality-of-fit number that affects their comp. Product gets time-to-value as a release metric. Support gets first-contact resolution. CS is the convener that watches the whole picture and escalates when the cross-team metric is at risk.

Two: ambient signal

The CS function is the eyes and ears. Their job is not just to save accounts; it is to make signal from customer reality flow to the teams who can act on it. The product team sees, every week, the three things customers most asked about. Sales sees, every week, the gap between what was promised and what landed. Support sees the patterns that keep coming back.

The best CS teams do not save accounts. They make the rest of the company so attentive that fewer accounts need saving.

Three: cross-functional rituals

The accounts that get saved are saved by the right person, often outside CS, intervening at the right moment. That only happens if there is a ritual that surfaces the right accounts to the right people on a cadence. A weekly cross-functional twenty-minute review of the at-risk accounts, with named owners from sales, product, support, and CS, will save more accounts than any number of CS-only QBRs.

What good metrics look like

The metrics shift to reflect the operational framing. The number we report up is not "CS-driven retention" because that number does not exist; everyone touched the customer. It is gross and net retention, broken down by cohort and by product, with the inputs that drive each made visible.

The inputs that consistently predict the output, in my experience, are time-to-first-value (how fast did the customer feel the product worked), product-quality-of-fit (do they use the parts of the product that matter for their use case), and contact-resolution-time on support tickets (do their problems get solved fast enough that they trust the company). Move those, retention follows. Try to move retention directly without moving them, you are doing theatre.

What this requires of leadership

For CS to operate this way, the CEO has to back the framing. The first time the head of sales says "that is a CS problem" about a renewal, leadership has to respond with "that is a company problem, here is what each team is going to change." Without that, the operational framing collapses back into the departmental one within a quarter.

I have seen this shift work most often when CS reports to the COO or directly to the CEO rather than to revenue. The reporting line matters because incentives follow it. CS reporting to revenue will, over time, start optimising for short-term renewals. CS reporting to operations will keep optimising for the inputs that produce durable retention.

One thing to try this week

If you only do one thing, start the cross-functional at-risk review. Twenty minutes, weekly, with sales, product, support, and CS in the room. The first one will be uncomfortable. By the fourth, you will start to see accounts saved by the right person at the right moment. That is what CS-as-operations looks like in practice.

The same thinking informs how we shape engagements at Cafiyn™ Biz: outcomes that cross teams need operational ownership, not departmental responsibility.

I have been through two of these journeys end to end, and watched a dozen others up close. The pattern is consistent enough that I want to lay it out, plainly, because most of the advice I read on this topic is too clever. The actual moves are simpler than they sound, and the discipline is in making them on time.

Zero to one: founders are the system

At zero to one, the founders are the system. There is no process because there is no time for process; everything is invented in the moment by whoever is closest to the problem. This stage rewards three things: judgement, speed, and willingness to do work that is technically below your title. The founders sell, support, code, hire, and pack boxes, and the company depends on their tireless context switching.

What you should not do here, even though it feels grown-up, is build process. There is nothing to process yet. There is no repeatable pattern; you are still figuring out what the pattern is. Process built at this stage encodes guesses and locks you into them.

One to ten: process replaces founders

The shift starts the day the founders are the bottleneck. Decisions queue waiting for them. Customers wait too long for answers. The next deal cannot move forward because someone needs the founder's brain for half an hour. This is the moment to start replacing the founders' judgement with explicit process for the most repeatable decisions.

This is where most founders stall. The judgement they used at zero to one is now too expensive to apply to every decision, but writing it down feels like losing control. The fix is to write down the decisions you make the same way every time, hand the framework to someone you trust, and let them make those decisions without you. You will be wrong about a few of them. That is the price of buying back your time.

Process is judgement, externalised. It does not replace founders; it replicates them.

The hires you make in this stage are critical and different in kind from the first ten. You are no longer hiring people who can do anything; you are hiring people who can run a specific function and build a small team. Generalists are still valuable, but the centre of gravity shifts to operators with depth.

Ten to fifty: layers and specialists

By ten to fifty, the company has functions. Functions have heads. The founders have to learn to operate through them, which means accepting decisions that are not what they would have made. This is the hardest transition because it requires founders to relinquish the very judgement that worked at the earlier stages.

The companies that get this right develop what I call a signal layer: deliberate, lightweight ways for founders to stay in touch with reality without inserting themselves into every decision. Skip-level conversations, regular customer time, an honest weekly written summary from each function. None of these are expensive; all of them are skipped at the companies that struggle.

The temptation at this stage is to over-correct into management. To build review cycles, OKR cascades, dashboards. Some of this is necessary. Most of it is theatre that buys the appearance of control while the real signal is happening in conversations the founders no longer hear.

The three skips that hurt most

Three transitions get skipped most often, and each one shows up later as a much bigger problem.

1. Founders try to manage at scale the way they led at zero. By being everywhere. The result is a brittle company that depends on the founders being available, which they cannot be once the company is large enough to need them most.
2. Companies build process for problems they do not yet have. Usually because someone joined from a bigger company and brought the playbook. The process slows things down without removing any real friction, because the friction it was designed for has not appeared yet.
3. Founders never replace their own judgement on the repeatable decisions. They keep approving routine things long after it is the worst use of their time, because handing off feels like losing the thread. It is losing the thread on the things that should have been let go.

How to know which stage you are in

The honest test is not revenue or headcount. It is how often the founders are the bottleneck. If decisions queue waiting for you, you are past zero to one and resisting it. If your hires keep failing because the company has no system to support them, you are past one to ten and have not built the process. If your function heads do not really run their functions, you are at ten to fifty pretending to be at one to ten.

None of this is meant to make the work sound easy. It is not. But the diagnosis is usually straightforward, and the move usually obvious once the diagnosis is honest. The hard part is the unlearning, and the only thing that helps with that is starting before you are forced to.

If any of this lands on a current situation, that is what Cafiyn™ Biz exists for. We embed with founder-led teams in exactly these transitions and help them make the moves they already know they need to make.

This is not a popular position because it sounds like an excuse. It is not. It is a discipline, and the discipline is what I now call the smallest viable architecture: the simplest design that can credibly carry your real, near-term load, with a deliberate plan for what you will change when the load actually arrives.

What the rule actually says

Architect for the load you will have in twelve months, plus one credible failure mode you know about. Not for the load you might have in three years. Not for the integrations you will probably want. Not for the abstractions a senior engineer thinks are inevitable. Twelve months and one failure mode. That is the budget.

The reason for the cap is not faith that nothing will change. It is the opposite. So much will change in three years that any architecture built for it will be wrong in ways the team cannot predict. The cheaper path is to build for the next year, ship faster, and learn enough from real users to make the next year's investment with real data. The teams I trust most ship a thinner system, watch how it bends, and reinforce the parts that actually need it.

Where to spend complexity, and where not to

The hardest skill in this discipline is choosing where to invest complexity early and where to defer it. A short list that has held up across very different systems:

Invest early

• The data model. Schema changes are the most expensive thing in any growing system. Spend deliberate time here.
• Authentication and authorisation. Rebuilding these in flight is painful and exposes real risk.
• Observability. You cannot reason about a production system you cannot see.

Defer

• Premature service decomposition. Most monoliths that got split too early ended up as distributed monoliths with extra latency.
• Custom infrastructure. Use managed services until they hurt; the bill is almost always cheaper than the engineering time.
• Generic abstractions. Resist building a framework before you have three concrete uses of the thing the framework would generalise.

The cost of premature scalability is paid in every deploy. The cost of insufficient scalability is paid once, loudly, and then fixed.

The one signal that justifies investment

The signal to invest in scale is not a forecast. It is contact with the current ceiling. Latency rising. A queue backing up. A nightly job running into the morning. When you have hit a real ceiling, you have all the information you did not have before, and you can invest with confidence. The teams I have seen waste the most time invested in ceilings they had not yet touched, based on slide-deck assumptions about what was coming.

How this looks at scale

At Zoho and Freshworks the systems that aged well were the ones whose original architects had been disciplined about deferring. The ones that aged badly were the ones that tried to be cloud-native multi-tenant globally distributed event-driven on day one. Both kinds of systems eventually reached real scale. The first kind got there with engineers who still understood how it worked. The second kind got there with engineers who were apprehensive about touching anything.

What to take from this

If you are starting a new system, write down the load you are designing for, the one failure mode you are designing against, and the assumptions both depend on. Pin it somewhere visible. In six months, compare the assumptions to reality. The gap is the most accurate guide you have to where to invest next.

The same discipline shows up in the systems we build inside Cafiyn™ OS and the way we coach teams through Cafiyn™ Biz. Smaller, adapted, observed. Less ambitious than the architecture astronauts of any era, and consistently faster to get to real, durable scale.

The pattern is so consistent that I have stopped treating it as bad luck and started treating it as a design failure. Three forces produce it, and any team adopting or building operational software can design against them deliberately.

Force one: the model that was almost right

The first force is the rigid model. Every operational tool encodes assumptions about how the work flows, which roles exist, and which transitions are valid. Those assumptions were correct, more or less, on the day the tool was chosen. They drift slowly. The org chart changes. The product line adds a wrinkle. A new compliance requirement adds a step. The tool does not move with the work, so the work moves around the tool. Spreadsheets reappear. A Slack channel becomes the real status board.

The remedy is not to pick a more flexible tool; flexibility is usually a euphemism for "you can build the rigidity yourself." The remedy is to keep the encoded model deliberately thinner than the work, and to give the team an explicit, low-friction way to evolve it. The tool that survives eighteen months is the one whose model the operators can change without filing a ticket.

Force two: the knowledge that lived in one head

The second force is knowledge isolation. The person who set up the tool, designed the workflows, and trained the team usually leaves within a year. Their knowledge of why the tool was configured the way it was leaves with them. The next admin inherits a system whose decisions feel arbitrary, so changes get made conservatively, which means hardly at all. The tool ossifies.

This is fixable but rarely fixed. Decisions about configuration belong next to the configuration itself, not in a wiki nobody opens. Every workflow change should carry the why with it. We borrowed this discipline from software engineering, where any change without a rationale gets quietly reversed by the next person who reads the code.

Force three: the sunk-cost defence

The third force is the politics of admitting the tool is not working. Someone fought for the purchase, ran the rollout, and put it on their resume. Admitting it has decayed is admitting that work was wasted. So the workarounds get tolerated, the dashboards get massaged, and the eighteen-month decline is described as "we are still maturing on the platform." Honest reviews stop happening exactly when they would be most useful.

The most expensive operational tool is the one your team has stopped trusting but cannot afford to replace.

What to design for, on day one

The three forces are predictable, which means they can be designed against. We start every Cafiyn™ OS engagement with three commitments. First, the encoded model is small and visibly editable by the operators who actually run the process, not just the admins. Second, every configuration carries the reasoning that produced it, in the same place as the configuration, dated and attributable. Third, we run a deliberate twelve-month review where the team can change the model without it being a referendum on the original decision. That single review, scheduled in advance, prevents most of the sunk-cost paralysis.

None of this is novel. It is just unfashionable, because it requires a tool philosophy that prioritises adaptability over completeness. The completeness pitch wins more sales. The adaptability pitch wins more eighteen-month-old systems that are still trusted.

Two questions to ask before you buy

If you are evaluating an operational tool right now, two questions filter out most of the future regret. Who, on my team, will be able to change the workflow next year without help? And how does the tool record why it is configured the way it is, so we can revisit those choices later? If the answers are "the vendor" and "it does not," you are buying the eighteen-month decline.