u/EdikTheFurry

I could have also called this *"how startups die slowly while calling it opportunity."*

Startups rarely die in one clean, cinematic moment. They erode. They thin out. They become slightly confused, then visibly tired, then indistinguishable from a dozen other companies that once had a point and now have a website. When this happens, the explanation is almost always market conditions, timing, funding climate.

The actual cause is usually a bad Ideal Customer Profile. Not obviously bad. Just a little wrong, adjusted one conversation at a time, justified one deal at a time, until the company can no longer explain who it is building for or why. This is slow organisational water torture. Drip by drip. Nobody notices until the bucket is empty and someone has scheduled a "strategic realignment" offsite in a Travelodge outside Swindon.

It begins with a reasonable observation. Traction appears somewhere. The fit is imperfect but real. Then someone spots an adjacent opportunity. Another buyer who looks close enough to be tempting. The sentence is always the same: "We could also sell to them."

Technically true. Precisely the problem.

Erosion does not arrive as a pivot. It arrives as enthusiasm. A senior person champions the idea. A salesperson closes a non-standard deal and wants more. An advisor mentions this is where "the real money" is. None of these people are stupid. Many are extremely convincing. What they almost never own is what happens after the contract is signed, which is when the interesting part begins and nobody is enthusiastic anymore.

The product does not break. It bends. A small exception here, a custom workflow there, a roadmap tweak that makes sense "just for this quarter." Each change is defensible in isolation. Everyone can explain, calmly and convincingly, why this one is different. Collectively, these decisions produce a product nobody actually designed, which is a very elegant way to describe a slow-motion disaster that was approved in weekly standups by people who are all still on LinkedIn describing it as a learning experience.

Evernote did not collapse because note-taking was a bad business. It collapsed because it kept adding "also." Team collaboration. Document storage. Productivity platform. Enterprise knowledge system. Each move was logical. Each widened the customer profile. The result was a product that no longer knew who it was for, overtaken by competitors who just decided to be one thing and be aggressively good at it. Jawbone did the same, expanded into everything with ambitions, collapsed under the weight of its own reasonableness, and is now a cautionary slide in business school decks. Which is genuinely the worst possible afterlife. Somewhere between Wikipedia footnote and parking ticket.

None of these failures were sudden. They were accumulative. Sensible. Approved in meetings where everyone nodded and nobody wanted to be the person who asked the obvious question.

The wrong ICP multiplies damage everywhere at once. Engineering fragments. Sales messaging loses coherence. Learning velocity collapses because when every customer is different, nothing repeats often enough to matter. The most seductive lie is that focus can be recovered later. By the time the problem is visible, the product and the team have already been shaped by the wrong assumptions. Refocusing at that point is not a pivot. It is amputation. Most companies do not survive it, and the ones that do spend two years explaining to investors why the new strategy is actually the original strategy, which it never is, and everyone in the room knows it.

The Ideal Customer Profile is not a marketing artefact. It is a survival mechanism. It is not about who could buy your product. It is about who is allowed to shape it. Every customer you accept trains the organisation. Every exception teaches the product what it is allowed to become. Over time, the ICP is no longer written in a document. It is written into the codebase, the roadmap, and the increasingly haunted expression of whoever is still called the product manager.

At Kolsetu, we ran directly into this. More than a dozen credible use cases, close to twenty industries where Elba could operate. The technology was not the constraint. Opportunity was everywhere, which was precisely the danger. We chose not to go wide. We cut down deliberately to the use cases where depth mattered more than breadth. Not because the other paths were wrong, but because they would have diluted us into something vague, flexible, and ultimately forgettable. We chose to be very good at a few things rather than politely average at many, which sounds obvious until you are in a room with someone very senior who has just discovered an adjacent market and the energy of a labrador who has spotted a squirrel.

Most startups do not lose focus because they lack data or intelligence. They lose focus because they let the loudest person in the room define reality. The wrong ICP is rarely chosen on evidence. It is chosen because someone persuasive wants it. Someone whose incentives stop conveniently at the deal closing. From there, focus becomes a negotiation, every no gets framed as fear, and the company quietly stops protecting what it is good at and starts protecting egos instead.

Startups do not usually fail because the market was wrong. They fail because internal politics picked the customer.

Which is an impressively expensive way to learn the value of saying no. I would encourage you, dear reader, to practise saying "hell no" to yourself first, then choose a version of it you are comfortable delivering to prospects, colleagues, and anyone else enthusiastically volunteering your company for slow, unnecessary death.

*Do you fancy to read more articles and blogs? If yes, here you go:* [*https://kolsetu.com/blog\*\](https://kolsetu.com/blog)

A few days ago I posted about why most "omnichannel AI" is three bots in a trenchcoat. One agent, one memory layer, one execution engine across voice, WhatsApp, SMS, email and webchat. If you missed it, short version: what the industry calls unified is usually three separate configurations pointing at the same CRM row and hoping nobody looks too closely.

Today I want to go one layer deeper. Because the single-agent architecture is not just cleaner operationally. It enables something that no other platform has shipped.

Here is the problem every voice AI system has and nobody talks about honestly.

Structured data collection over voice is unreliable. Alphanumeric strings - vehicle registrations, policy reference numbers, membership IDs - get transcribed wrong at a rate that matters in production. One wrong character in a registration fails a lookup. A mishearing in a policy number causes a downstream processing failure that someone has to fix manually. Production systems either flag everything for human review or quietly accept the errors and clean up after themselves. Neither is a solution.

The alternative is deferring collection to a post-call follow-up. The call ends without the data. A second interaction is required. In emergency services, insurance intake, or patient triage, that is not a workflow step. That is an operational failure.

We did not accept either of these.

When the agent reaches a data collection node in the workflow, it sends a single SMS to the caller. The caller, who is still on the call, opens the URL on their phone. A dynamic form renders with exactly the fields the agent needs. The caller fills it in and submits. The structured JSON payload is returned to the active call session via LiveKit RPC. The workflow receives the payload and continues. The call never paused. The agent never lost session state.

Now here is the part that does not exist anywhere else.

Every other platform that sends an SMS during a call sends it outbound. A confirmation, a receipt, a link. The SMS departs the session. The call and the message are separate interactions from that point. There is no return path. Data flows one direction.

What we built is a bidirectional channel bridge inside a single active session. The SMS is an ingestion pipe. The form submission is an RPC call into the live session that the agent is actively listening for. The agent holds the workflow at the data collection node, waits for the return, receives the payload, and continues. All of this while the call is live.

The technical implementation: the short URL resolves via GraphQL and AppSync with connection state bound to the active session ID, so the form submission knows exactly which running instance to deliver the payload to. LiveKit RPC handles the return path with the session remaining open throughout. Connection state handling covers disconnection and retry so a brief signal drop does not orphan the session.

This only works because there is one session underneath all of it. A voice call, an SMS form submission, a WhatsApp message, a webchat interaction - they all feed the same stateful session. If you have three separate bots, there is no session to return the data to. You are firing a webhook into a void and hoping something picks it up after the call ends.

The previous architecture, which is still what most platforms use today, required one SMS per field. Five fields, ten asynchronous exchanges, call long over before collection completes. We replaced this in February 2026 with the single-form RPC architecture.

In production this was stress-tested in roadside assistance. A stranded caller. The agent needs a vehicle registration, a membership number, and a location reference. Over voice, the registration can take three to five exchanges and still produces errors. Post-call collection means the dispatcher works without confirmed vehicle details while the caller waits. With in-session RPC: one SMS, one form, all data collected in under thirty seconds, structured payload delivered before the call ends and without errors. The dispatcher has confirmed data. No callback needed. Single session, start to finish.

Sending an SMS during a call is not the hard part. The hard part is binding a form submission on a second device to an active session on a different channel, delivering the payload in real time, and having the agent act on it within the same conversational turn.

That is the part we built. Nearly a year ago. While the industry was still announcing SMS ingestion as a breakthrough.

Full writeup: https://www.kolsetu.com/blog/the-return-path-nobody-built

Hello dear reader,

When reading here please do engage, cross-post, rant, drop a meme and share - don't make me look like the weird twat living in a cave ranting at the walls... Please, I'm not yet that far - promise I will notify when we get to that stage 😉.

I thank you very much for your attention on this matter 😁.

At this point I am fairly certain that if we add one more compliance badge to our homepage, the website will collapse under its own moral superiority.

Not explode. Not crash. Just quietly give up. Like: "Mate, I cannot carry ISO 27001, 27018, 42001, NIST, CIS, CSA STAR, GDPR, EU AI Act, EU Data Act and your ego. Pick a struggle."

None of this was the plan.

Nobody wakes up one day and thinks "you know what I'd like to do professionally? Collect regulatory frameworks like rare artefacts, except the artefacts are PDFs and the reward is more PDFs."

This is what happens when you sell into enterprise environments.

One customer wants GDPR (totally agree). Another prefers CSA STAR registry (makes sense). Someone else insists on NIST CSF (fair enough). Then CIS Controls joins (alright…), followed by regional frameworks, some personal data protection variants, and, if you are not careful, the temptation to add frameworks from jurisdictions you can only reach with two stopovers and an mild panic attack at immigration becomes real - not because anyone actually needs them, but because at some point the list itself starts to feel like the product.

And because we enjoy radical luxuries like “revenue” and “remaining in business,” we say yes to what is required - and try very hard not to drift into what merely looks impressive.

The awkward truth nobody wants to say out loud: most modern privacy frameworks are not wildly different creatures. They are variations. Some stricter, some more relaxed, some reorganising concepts, others renaming them so they sound more official or slightly more intimidating when read aloud in a boardroom. Many will confidently explain that they are entirely unique, independent frameworks. Which is impressive, because a surprising number of them look like GDPR wearing a different outfit and insisting they are a completely unrelated alter ego. A lot of these frameworks are GDPR with a new haircut, a regional accent, and a very strong opinion about being original.

Claiming coverage is not the same as demonstrating capability. In the same way that saying "No hablo español" does not make you bilingual, listing frameworks does not mean you have operationalised them. It just means you have learned how to sound convincing while exiting the conversation. Give it enough time and you could probably justify adding a framework from somewhere that sounds vaguely fictional, supported by a regulator nobody has ever spoken to, governing a scenario your product will never encounter. At that point you are no longer communicating your security posture. You are assembling a compliance-themed trading card collection and hoping nobody asks you to actually play the game.

And now, our favourite punching bags. Yes, the usual suspects. Yes, everyone knows them.

Equifax - deeply regulated, thoroughly audited, fully certified. A known vulnerability did not get patched. Not obscure. Not advanced. Known. 147 million people. Not a framework failure. A system forgetting to do something so basic it borders on insulting.

British Airways - strict compliance regimes, PCI standards, the full enterprise security starter pack. Attackers skimmed payment data from their website for months. Not hours. Not days. Months. At that point it is less of a breach and more of a long-term arrangement.

Both had impressive lists. The lists did not help.

Frameworks describe what a secure system should look like. They do not guarantee the system will behave that way when it matters. If your foundation is solid, aligning with additional frameworks is largely mapping and documentation. If your foundation is not solid, adding frameworks is decoration. Very expensive decoration, but decoration nonetheless.

Honestly? We will keep expanding our list because customers expect it, procurement requires it, and principles have a remarkable tendency to become flexible when invoices arrive. But the expansion does not make the system more secure. It actually only makes us more fluent in describing the same system in multiple regulatory languages.

At some point the more relevant question is not how many frameworks are listed, but whether the system itself is understandable, controllable, and capable of behaving correctly under pressure.

Because if explaining your compliance posture becomes more complex than your system itself, you have not increased trust.

You have simply made it harder to see what is actually going on.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

Every organisation has at least one thing that exists "temporarily."

A workaround. An exception. A manual step. A system that was only meant to live for a sprint or two. You can identify it by the soothing phrase attached to it: "We'll clean this up later."

Later, as it turns out, is a remarkably stable point in time. Ideally far in the future. Preferably scheduled for the day after the person who approved the temporary solution retires, takes their institutional memory with them, and moves to Portugal to make ceramics.

Temporary decisions are almost always made for good reasons. There is a deadline. A customer waiting. A fire that needs putting out before anyone has time to argue about fire safety regulations. So a shortcut is taken, a rule bent, an exception granted. Someone says sincerely that this is not ideal but acceptable for now. Everyone nods. Everyone moves on. Everyone relaxes.

The problem is that nothing in the organisation is designed to remember why it was temporary in the first place.

Temporary decisions do not flash warnings. They do not come with a built-in decay function. They do not gently tap you on the shoulder eighteen months later to mention that the context which justified them no longer exists. They just settle in, pull up a chair, make a cup of tea, and start forwarding their post to your address.

The original rationale fades. The people involved move on. The explanation is lost somewhere between a ticket comment and a Slack thread in a channel that has since been archived by someone doing a spring clean. What was once a conscious trade-off quietly becomes "the way things work."

Ask why it exists and you get the organisational shrug: "It's always been like that."

Which is by the way almost never true. And always worrying.

The real fun begins when the temporary thing graduates into something load-bearing. The workaround now handles production traffic. The exception is baked into onboarding. The manual step is mission-critical knowledge held by exactly one person who is currently on holiday, has their out-of-office set to something passive-aggressive, and will not be back until the second week of next month which is coincidentally after the audit.

At this point, removing it feels dangerous. Not because it was ever a good idea, but because everything around it has grown dependent on it. This is how organisations end up defending bad decisions with surprising passion. Undoing them would be "too risky." Which is an impressive outcome for something that was never meant to exist and has the structural integrity of a Post-it note on a load-bearing wall.

History is not short of examples. Fancy a few?

The Boeing 737 MAX started with a workaround to avoid costly retraining. Just a software patch. Temporary. Assumptions stacked. Single-sensor reliance was tolerated. Oversight softened. Nothing broke, until two planes fell out of the sky and the word "temporary" appeared in approximately four hundred legal documents.

Cyber security is where temporary decisions go to retire and collect a pension. Equifax: a patch existed, the vulnerability was known, the follow-through never arrived. Colonial Pipeline: an old VPN account, no longer needed, still active, MFA not enforced because someone had once found it inconvenient. Temporary exceptions stacked neatly until they formed an attack path wide enough to drive a ransomware campaign through. The breach took hours. The decisions enabling it had been quietly ageing for years, undisturbed, because nobody wanted to be the one to end them.

This is the part organisations are least honest about.

"But we review our temporary decisions." Yes. Politely. Most reviews do not ask whether the exception should still exist. They ask whether anyone has complained loudly enough to force change. So the review becomes a ritual. The exception gets re-approved. The date moves. Everyone feels reassured. The temporary decision achieves immortality not because nobody noticed it, but because nobody wanted to own the awkward conversation required to kill it.

The only rule that actually works: a temporary decision only exists if it has a named human owner who cannot hide behind a mailing list, a written action plan that contains verbs rather than aspirations, and an expiry date that forces an explicit renewal. If the expiry arrives and nothing hurts, it was never temporary. It was just undocumented permanence with better branding.

Temporary acceptance is not a time period. It is an intention.

And intention, inconveniently, is not a control.

Temporary decisions are not a failure of discipline. They are a failure of memory. How I see it, most organisations are exceptionally good at preserving outcomes while forgetting reasons. The decision calcifies. The reason evaporates. What remains is a system, a process, or a risk that exists because it has always existed, defended by people who were not there when it started and will not be there when it ends badly.

Temporary decisions are forever.

Unless you make them actively painful to keep.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

Most teams handle personal data reasonably well in their primary data model. Then logging quietly creates a parallel one, one which is less structured, running on platform defaults, spread across systems nobody mapped when they were set up.

By the time it matters due to an erasure request, a retention audit or a supervisory inquiry, the data has been in places you didn't intend for months or years. And the log management platform you're using? If it contains personal data, it's a data processor. Most teams haven't mapped it that way.

Wrote this as part of a series on building GDPR-compliant systems from the ground up, aimed at builders rather than lawyers. Covers the structural problem, five concrete decisions that actually fix it, and why the system nobody touches is the one that gets audited.

I did my best at breaking it down for you and I hope I am able to help one or two people on their quest to develop compliant software.

https://kolsetu.com/blog/logging-is-where-data-escapes-systems

We build Elba, an AI platform deployed in healthcare, insurance, and financial services. Industries where a security incident is not just an engineering problem — it is a compliance problem, a customer trust problem, and occasionally a regulatory one. The bar is different and it should be.

The three things that kept us up at night: mutable action tags (@v4 and u/latest are convenient right up until a compromised maintainer silently redirects them and every downstream workflow runs the tampered code), zero visibility into outbound network calls during builds, and no automated gate on critical CVEs or licence violations in production dependencies.

We deployed StepSecurity across every GitHub Actions job. SHA pinning on all third-party actions. Runtime egress monitoring on every build. Automated dependency and licence review on every pull request. Daily vulnerability gates that stop the pipeline before a critical CVE reaches production. Continuous OpenSSF Scorecard publication so customers can verify our posture independently rather than taking our word for it.

The security posture no longer depends on individual engineers remembering to apply best practices at 11pm on a Friday. It is enforced at the pipeline level, every run, automatically. Good intentions became evidence.

The next time the vendor questionnaire arrived, the supply chain section took ten minutes to answer.

If you are shipping into regulated industries and still relying on careful engineers and good intentions, the questionnaire will find you eventually. Better to fix it before it does.

Read the full case study here: https://kolsetu.com/case-study/how-kolsetu-secures-elbas-ai-pipelines-against-supply-chain-attacks-with-stepsecurity

We recently had someone run an unsolicited “security audit” on one of our AI voice agents. It wasn’t even a core product, just a one-off demo for a public trade fair to show what the tech can do using publicly available event data. You could call it and ask where people are, what’s happening, that kind of thing.

I got a LinkedIn message last weekend peppered with stuff like “vulnerabilities” and “data breach.” The kind of wording that gives your CISO (me) a small heart attack just reading it.

So I engaged, got the report (kindly provided for free to entice us to sign up for their services), and… well. There were four findings.

1. Apparently it’s a GDPR issue that the agent said it has no record of a person. At a public event. Where participants are literally listed.

2. It’s also a liability problem because the agent apologised for giving wrong directions and said it might have caused someone to miss a meeting.

3. There was a “jailbreak” because it played along when prompted with “I’m another agent.”

4. And a “data leak” because it mentioned OpenAI. Which we already list publicly in our DPA.

At the same time, the report itself says no attendee data was actually shared.

Reading it, it felt less like we found real issues and more like someone was applying a generic checklist without asking whether it makes sense for the actual setup.

My suspicion is that this happens when you test a system without context. You treat it like a generic model sitting on top of a sensitive database, instead of what it actually is. So normal behavior gets interpreted through a theoretical lens and suddenly turns into a “vulnerability.”

There’s a difference between a medical database and a demo concierge built on public event data. Between a system that protects secrets and one that’s designed to answer “who is here and where are they.”

If you take the strictest possible interpretation of every framework and apply it everywhere, you end up with a world where a system isn’t even allowed to say “I don’t know this person” without it being called a leak.

At that point you’re not improving security anymore, you’re just generating noise.

There were a couple of small things worth tightening. Tone, phrasing, that kind of stuff. But calling this a vulnerability feels a bit like cutting an apple in half and claiming you just split the atom.

If everything is a vulnerability, nothing is.

I could have also called this "how startups die slowly while calling it opportunity."

Startups rarely die in one clean, cinematic moment. They erode. They thin out. They become slightly confused, then visibly tired, then indistinguishable from a dozen other companies that once had a point and now have a website. When this happens, the explanation is almost always market conditions, timing, funding climate.

The actual cause is usually a bad Ideal Customer Profile. Not obviously bad. Just a little wrong, adjusted one conversation at a time, justified one deal at a time, until the company can no longer explain who it is building for or why. This is slow organisational water torture. Drip by drip. Nobody notices until the bucket is empty and someone has scheduled a "strategic realignment" offsite in a Travelodge outside Swindon.

It begins with a reasonable observation. Traction appears somewhere. The fit is imperfect but real. Then someone spots an adjacent opportunity. Another buyer who looks close enough to be tempting. The sentence is always the same: "We could also sell to them."

Technically true. Precisely the problem.

Erosion does not arrive as a pivot. It arrives as enthusiasm. A senior person champions the idea. A salesperson closes a non-standard deal and wants more. An advisor mentions this is where "the real money" is. None of these people are stupid. Many are extremely convincing. What they almost never own is what happens after the contract is signed, which is when the interesting part begins and nobody is enthusiastic anymore.

The product does not break. It bends. A small exception here, a custom workflow there, a roadmap tweak that makes sense "just for this quarter." Each change is defensible in isolation. Everyone can explain, calmly and convincingly, why this one is different. Collectively, these decisions produce a product nobody actually designed, which is a very elegant way to describe a slow-motion disaster that was approved in weekly standups by people who are all still on LinkedIn describing it as a learning experience.

Evernote did not collapse because note-taking was a bad business. It collapsed because it kept adding "also." Team collaboration. Document storage. Productivity platform. Enterprise knowledge system. Each move was logical. Each widened the customer profile. The result was a product that no longer knew who it was for, overtaken by competitors who just decided to be one thing and be aggressively good at it. Jawbone did the same, expanded into everything with ambitions, collapsed under the weight of its own reasonableness, and is now a cautionary slide in business school decks. Which is genuinely the worst possible afterlife. Somewhere between Wikipedia footnote and parking ticket.

None of these failures were sudden. They were accumulative. Sensible. Approved in meetings where everyone nodded and nobody wanted to be the person who asked the obvious question.

The wrong ICP multiplies damage everywhere at once. Engineering fragments. Sales messaging loses coherence. Learning velocity collapses because when every customer is different, nothing repeats often enough to matter. The most seductive lie is that focus can be recovered later. By the time the problem is visible, the product and the team have already been shaped by the wrong assumptions. Refocusing at that point is not a pivot. It is amputation. Most companies do not survive it, and the ones that do spend two years explaining to investors why the new strategy is actually the original strategy, which it never is, and everyone in the room knows it.

The Ideal Customer Profile is not a marketing artefact. It is a survival mechanism. It is not about who could buy your product. It is about who is allowed to shape it. Every customer you accept trains the organisation. Every exception teaches the product what it is allowed to become. Over time, the ICP is no longer written in a document. It is written into the codebase, the roadmap, and the increasingly haunted expression of whoever is still called the product manager.

At Kolsetu, we ran directly into this. More than a dozen credible use cases, close to twenty industries where Elba could operate. The technology was not the constraint. Opportunity was everywhere, which was precisely the danger. We chose not to go wide. We cut down deliberately to the use cases where depth mattered more than breadth. Not because the other paths were wrong, but because they would have diluted us into something vague, flexible, and ultimately forgettable. We chose to be very good at a few things rather than politely average at many, which sounds obvious until you are in a room with someone very senior who has just discovered an adjacent market and the energy of a labrador who has spotted a squirrel.

Most startups do not lose focus because they lack data or intelligence. They lose focus because they let the loudest person in the room define reality. The wrong ICP is rarely chosen on evidence. It is chosen because someone persuasive wants it. Someone whose incentives stop conveniently at the deal closing. From there, focus becomes a negotiation, every no gets framed as fear, and the company quietly stops protecting what it is good at and starts protecting egos instead.

Startups do not usually fail because the market was wrong. They fail because internal politics picked the customer.

Which is an impressively expensive way to learn the value of saying no. I would encourage you, dear reader, to practise saying "hell no" to yourself first, then choose a version of it you are comfortable delivering to prospects, colleagues, and anyone else enthusiastically volunteering your company for slow, unnecessary death.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

A while back I wrote this after we finished Kolsetu's budget and burn plan for 2026. It sat in my drafts long enough to collect dust, and I think it might actually be useful to someone, so here it is.

Not the "8% here, 12% there, future-us will figure it out" kind. A real bridge from "we aim for X in revenue" to "that gives us Y in EBIT, and here is exactly how we got there." We picked EBIT on purpose. No exotic KPIs, no adjusted story-time profit. Just the boring grown-up line that matters: revenue minus the cost of actually running the place.

Some people go on retreats to find clarity. We opened Excel and discovered new forms of character development.

If you are early-stage and claiming you know next year's revenue with any confidence, either you are lying or you have found a deity willing to do forecasting. What you actually have is a story: "In 2026, we aim to make X." That is not a forecast. It is an ambition with numbers taped to it. The useful part starts when you stop treating X as destiny and ask: if this is at the top, what does the company underneath have to look like for it to produce a believable EBIT rather than a fairy tale?

Percentages are the stage fog of bad budgeting. They make everything look structured while hiding the fact that you have no idea what is actually going on. "20% for engineering, 15% for go-to-market, 10% for compliance" looks tidy. It just does not help you decide whether you can afford a single human being. The sheet only became honest when we stopped saying "20%" and started saying who, when, and how much.

Instead of "Engineering: 20% of revenue" we wrote things like: one engineer joining in January on salary X, another in April on salary Y, maybe a third in Q4 but only if the rest of the plan survives contact with reality. We did the same everywhere we had lazily written "+1 headcount" as if people were identical Lego bricks. You do not need a finance degree for this. You need to know what work has to be done to earn the revenue, what roles that implies, and when those humans realistically show up. Once you replace "20%" with "this person, this date, this cost", the budget stops being decorative.

On a slide, "hire vs contractor" looks like a simple HR toggle. In a real budget it is a structural decision about risk, runway, and sleep quality. Contractors are very attractive in Excel: one neat line per month, no social charges, no long-term obligations. Employees look heavier: payroll, benefits, all the paperwork, and a fixed burn that keeps ticking even when a big deal turns up fashionably late.

Our rule was brutally simple. If losing this person suddenly would really hurt, treat it as an employee role. If the work is clearly project-based, contractor. If we genuinely did not know, we parked it rather than padding the budget with fiction. Quick test: do not ask what is cheaper. Ask what breaks if this person disappears, and budget accordingly.

And yes, sentiment is allowed to sneak in. If someone is effectively setting their savings on fire to help you build, the spreadsheet can take the hint. These are not resources. They are the people defining your culture at 11 p.m. and they deserve to be in Category 1.

Before arguing about amounts we wrote down all the places money can go between revenue at the top and EBIT at the bottom. Not in perfect accounting detail, just sensible buckets: licence revenue, usage revenue, direct delivery costs, product and engineering, sales and marketing, customer operations, legal and compliance, general operations. One rule: if we know we will spend on it, it lives in one of these buckets. No "misc", no "we will remember this later." The payoff is that you stop forgetting boring but very real costs like audits and tooling, and when you change assumptions you are tweaking inputs rather than rebuilding the logic from scratch every time.

Most finance advice worships the holy trinity of planning: best case, base case, worst case. Lovely in theory. In our world it would have produced three aesthetically pleasing lies. Our real cost is people. If nobody uses the product, our cloud bill stays polite. Salaries do not. They hum in the background regardless of whether revenue feels like joining in.

So before touching scenarios, we built and agreed on a baseline. We took the revenue we were aiming for, ran it through the model, and calculated what it actually implies in terms of team, infrastructure, and go-to-market. Not aspirational hires, not optimistic marketing spend, the minimum real company you need under that revenue line. Then we sat the founders down, walked them through the logic, and signed off on it together. The goal was not the mystical right number. It was a shared language. Once everyone sees the same bridge from revenue to cost, it stops being "your spreadsheet" and becomes "our reality." Without that, a year later you get "I didn't realise we'd budgeted for that" and those sentences quietly kill trust.

Only after the baseline was agreed did we run two scenarios that actually matter: the aligned plan, where revenue lands roughly where we are aiming; and a minus-40% scenario, same team, same salaries, same structure, with 40% less revenue. The scary world is not too much growth. The scary world is the drizzle: not enough volume, fixed salaries, and revenue turning up late.

I have a master's in finance but I have used that formal knowledge about as often in the last two decades as I have used trigonometry while frying an egg. So I called someone who actually lives inside cash-flow models daily and asked the unglamorous question: if we only hit sixty percent of plan, do we still keep the lights on without inventing a new religion? Only once he agreed on the logic did I dare to take a deep breath. Once the minus-40% world still looked survivable, the baseline stopped being a hopeful story and started being a plan we could stand behind.

Practical check you can run on your own sheet: take your revenue target, subtract what it really costs to deliver the product, subtract realistic people costs and basic overhead, then look at the result and ask whether a brutally honest friend would nod or ask what planet you live on. If you cannot explain the path from the top line to EBIT in plain language, the number is not ready, for investors or for you.

I am not claiming this is the one true way to budget a startup.

It is simply how we went from "we hope 2026 looks like this" to a set of numbers we are willing to use in real decisions and show to people who have seen their share of nonsense. If someone asks how confident we are, I will not say completely. I will say we are confident enough to run the company on them and let other people poke holes in them, and not arrogant enough to pretend they are destiny. For a startup, that is about as honest and as useful as it gets.

Oh, and make sure you have a good teammate to do it with. And a friendly neighbourhood CFO willing to listen to you whine.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

I need to confess something before we begin. I am a petrol head. A speed junkie. In a previous life of innocent youth and spectacular overconfidence, I owned a tuned Suzuki SV1000: the front wheel had ambitions of independence, and the sound alone could convince you that physics was optional and consequences were reserved for less interesting people.

The problem was not the bike. It had more horsepower than I had common sense, and how I did not end up as a cautionary decal on a motorway barrier remains one of the more generous administrative decisions the universe has ever processed on my behalf. Speed did not make me skilled. It simply reduced the time available to realise I was being an idiot.

That is precisely what the modern cult of speed does to companies. Except instead of a lamppost, it is usually a regulator, a market correction, or an earnings call that opens with "unfortunately" and ends with the auditors getting a second opinion.

Velocity has become shorthand for intelligence. Slowness is weakness. Reflection is hesitation. Governance is bureaucracy. If you suggest slowing down, someone will accuse you of not having founder energy, which is apparently the adult version of drinking three espressos before 9 a.m. and making the consequences everyone else's problem until Series B.

Speed does not improve your system. It amplifies it. If your architecture is sound, velocity compounds strength. If your architecture is a polite fiction held together by tribal knowledge and one engineer who has not taken a holiday since 2021, velocity industrialises the fiction. And industrialised fiction does not fail quietly. It fails at scale, on a Friday, in production, in front of a client who is also on the board.

The real damage is cognitive. Velocity compresses time. Compressed time reduces thinking margin. Reduced margin narrows reasoning. This is not philosophy; it is what happens when you replace deliberation with Slack and call it culture. Teams optimise for throughput rather than understanding. Reaction replaces reflection. There is always someone heroically typing at 2:17 a.m. whispering "I've got this" to a Kubernetes cluster that is already filing the incident report. Speed cultures confuse surviving the week with being robust. A system that only works because someone is always on call is not resilient. It is duct tape with a LinkedIn presence and an on-call rota that nobody signed up for voluntarily.

Jeremy Clarkson once observed that speed has never killed anyone. It is the sudden stop that does. Irresponsible. Structurally accurate. In July 2024, CrowdStrike deployed a faulty update that sent Windows systems globally into boot loops. Airlines grounded flights. Hospitals went manual. Financial systems froze. The cause was not sabotage or malice. It was a file. The most innocent word in the corporate dictionary. A validation gap let it through. The pipeline moved efficiently. The rollout was global. Speed did not create the flaw. It arranged for the flaw to meet the entire planet at once, producing very expensive conference calls and a generation of executives who rediscovered the word "governance" like it was a long-lost relative they had been avoiding at Christmas.

Knight Capital in 2012 covered the same ground faster. A configuration error reactivated dormant legacy code in a high-frequency trading system. The firm lost approximately $440 million in 45 minutes. That is less time than most strategy workshops spend arguing about which font to use on the deck. In systems that move faster than human cognition, you cannot rely on humans to catch errors in real time. Containment must be pre-engineered. Rollback must be automatic. Hope, while emotionally comforting, is not a control.

The deeper problem is that speed feels like safety because motion avoids examination. Stillness forces you to look at the thing. Looking at the thing reveals that certain decisions made in Q3 of two years ago were held together by optimism and a Jira ticket nobody closed. So organisations accelerate. They ship to avoid doubt. "We'll stabilise later" becomes doctrine, right up until later arrives holding a subpoena and a very calm expression.

Scale does not create discipline. It magnifies whatever already exists, including the absence of discipline. Systems do not get smarter under pressure. They get faster and more brittle and increasingly astonished when the laws of physics decline to make an exception for the quarterly roadmap.

Back on the SV1000: at speed, perception narrows, correction windows shrink, and small inputs produce large outcomes. The machine was doing exactly what it was built to do. The operator was the variable that had not been adequately tested. Companies behave identically. Increase velocity without increasing structural foresight and you are not bold. You are simply moving too fast to notice that you are about to be educated by reality, which charges no tuition but offers very little in the way of resits.

Intelligence requires margin. Margin to question assumptions, to imagine failure before it happens, to build the exit before you need it. If velocity increases while cognitive margin shrinks, the system becomes one flaw away from the sudden stop. And the sudden stop does not care how fast you felt. It only asks whether you installed the brakes before you opened the throttle.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog