There’s a website called deathbyclawd.com that scores SaaS companies on how likely they are to be replaced by a markdown file. It’s a gag. It’s also right enough to sting.
The idea — sometimes labelled the SaaSpocalypse, sometimes just the latest “vibe coding” pitch — is that a non-trivial amount of SaaS is a UI wrapper around logic an LLM can replicate. Drop a system prompt in a .md file, hand it to Claude, get most of the product back. The rebuttal you’ve heard from incumbents is that the moat was never the code, it was the knowledge. Both things are true.
We make a feature flag service. We expect this objection. We want to address it directly, without insulting anyone, because pretending it isn’t a real question is how vendors get themselves on the deathbyclawd leaderboard in the first place.
So: yes, you could vibe-code this. Here’s the pitch anyway.
The honest part: you can absolutely one-shot a basic version
Open Claude. Type:
Build me a feature flag service. Postgres for storage, a TypeScript SDK with a simple
getFlag(key, context)method, percentage rollouts, a tiny React admin UI, deploy on Cloudflare Workers.
You will get a working system in one shot. We have tested this. It will have:
- A flags table with key/enabled columns
- An evaluation function that hashes user IDs into 0–99 buckets
- A REST endpoint your SDK calls
- A login form that probably just compares against an env var
- A dashboard that mostly works and looks fine
For an afternoon’s investment, that is genuinely impressive. Two years ago that was a quarter of engineering work. Today it’s lunch.
If your needs end at “boolean flag, on or off, two engineers, no compliance story, no real customers yet” — that one-shot is the right answer. We mean it. Don’t pay us. Come back when you outgrow it. We have migration guides for when that day arrives, and they work for whatever Claude generated for you too.
The dishonest part of the vibe-coding pitch
Where the deathbyclawd gag overshoots — and where the SaaS-replacement essays start to wave their hands — is in skipping straight from the first afternoon to forever. The first afternoon is free. It’s the next two hundred afternoons that have a price tag.
Here’s what the prompt didn’t generate.
The second feature. A week after you ship, marketing asks for “users in Germany on the Pro plan, but only if their account is older than 30 days, and not if they’re on the legacy billing path.” That is a rule engine. Rule engines are fractal. The prompt that gave you boolean toggles will not give you a rule engine that doesn’t have three subtle off-by-one bugs in the operator precedence. You will spend a Saturday discovering this.
The bug fix you didn’t know you needed. A user reports that flag evaluation is sometimes returning the wrong value. After a day of digging, you find that your hashing function isn’t stable across SDK versions — same user, same flag, different bucket depending on which SDK rebuilt last. The deathbyclawd skill you generated did not have this bug because it didn’t have multiple SDKs. You now have multiple SDKs because Android needed one. This is how scope creeps.
The 3am page. Your eval endpoint is at 100% CPU. The cache that the LLM cheerfully suggested in the first prompt — // TODO: invalidate properly — is doing exactly what // TODO comments do. You are now on call for an internal tool you built to avoid being on call for a vendor.
The compliance ask. Your first enterprise prospect asks for SOC 2, role-based access control, audit logs that satisfy an external auditor, SSO that works with their IdP, and data residency. None of this is hard individually. Together it is six months of work, and “Claude built it” is not an answer your prospect’s security review is going to accept.
The flag graveyard. Eighteen months in you have 240 flags, twelve are checked in code, and nobody knows which is which. Removing one is a four-hour archaeological dig. (We have a whole post on this level — it’s why most teams that build their own get stuck.)
Each of these is a weekend. Each weekend is fine. Two hundred weekends in a row is a side project that ate your roadmap.
What you’re actually buying when you don’t build it
We are not going to claim moat-by-knowledge or moat-by-code. The moat — to the extent there is one — is more boring and more honest: other customers.
When you pay us, you are buying a slice of the time, scars, and pattern recognition of every team that ever ran into something weird and made us fix it. Specifically:
- The bug your fourth customer hit, that we fixed before your first. Streaming SDK reconnects under Kubernetes pod restarts. Stable hashing across language SDKs. The exact float-comparison bug in percentage rollouts that bites you at 50.0% but not at 49.9%. We have already had these bad days.
- A rule engine someone else paid the cost of getting right. Not “good enough for today’s three rules” — good enough for the rule that marketing requests in eighteen months that you can’t even imagine yet.
- An SDK in the language your platform team adopted last quarter. Without you writing it.
- Audit logs, RBAC, SSO, SCIM, data residency, SOC 2. Pre-built, pre-audited, pre-arguments-with-your-prospect’s-security-team.
- A staleness story for the flag graveyard. Owners, expirations, last-eval timestamps, an opinion about when a flag is dead. The thing nobody remembers to build into the one-shot prompt.
- A team whose pager goes off so yours doesn’t. When the eval layer hiccups at 3am, it wakes someone whose entire job is keeping it from hiccupping. That someone is not you.
None of this is moat-by-mystery. You could build all of it. The question is whether you want the next eighteen months of your roadmap to be a feature flag service, or whether you want it to be your actual product.
The deal, stated plainly
Here is the math, without pretending you can’t read.
A reasonable mid-stage team running its own flag system spends — in our experience asking — somewhere between half and one full backend engineer-quarter per year on it. Call that $40k to $80k loaded, plus the opportunity cost of whatever they didn’t ship.
Our paid plans start at $20/month. Even our enterprise tier — the one with all the SOC 2, SSO, audit-log-export, dedicated-support, multi-region things — costs less per year than one engineer’s pay for one good Sprint.
That’s the entire pitch. We’re not pretending to be irreplaceable, we’re not telling you Claude can’t write code, and we’re not going to roll our eyes at the deathbyclawd leaderboard. We’re saying: the vibe-coded version is the cheap part. The next two years of keeping it alive is the expensive part. We do that part for less than it would cost you to do it yourself, and we do it for many other customers at the same time, which is why the price works.
That isn’t a clever sales argument. It’s just the spreadsheet.
When you should ignore this post
We will name the cases where the deathbyclawd answer is correct, because pretending they don’t exist is how trust evaporates.
- You’re pre-PMF, two engineers, twelve users. You don’t need us. You barely need flags. An env var or a boolean constant is right. Spend the $20/mo on something you’ll actually feel.
- You have one product, one environment, no compliance customers, and you’re never going to. A vibe-coded internal tool is genuinely fine. It’s also genuinely fine if it never becomes anything more.
- You have a strict no-vendors policy your security team enforces. We aren’t going to talk you out of that. Self-host an OSS option, or build it. Both are reasonable.
- You’re a hobbyist, an indie, or an internal-tools shop with no SLA pressure. Build it. Have fun. We mean that.
The honest pitch isn’t “you’d be foolish not to use us.” It’s “if your situation is one of these, please don’t — and if it isn’t, please do, because the math is genuinely on your side.”
The “we have your back” part
The thing the one-shot prompt absolutely cannot give you is someone who answers when you write in. We staff support with engineers — not a routing layer. When something is weird, you describe it once, to a human who can read your stack trace, and the next reply is from someone who has fixed it before. That is not a markdown file. It is also, somehow, the part most build-vs-buy posts skip.
If your flag system breaks at 11pm before a launch, you can either:
- Wake yourself up, page a teammate, and dig through the LLM-generated code that nobody on the team has fully read, or
- Open our app, see what’s wrong, and — if you can’t tell — get a reply from us in minutes.
We pick (2) because we’ve lived through (1). We assume you have too.
A friendly note to anyone who just left deathbyclawd.com
The site is funny. The thesis is sharper than vendors want to admit. A surprising amount of SaaS really is a .md file with extra steps, and the next decade is going to be a slow and uncomfortable conversation about which categories survive that.
Feature flags are, awkwardly, on both sides of the line. The evaluation logic is genuinely close to a markdown file. The system around it — the SDKs, the dashboards, the rule engine, the audit story, the on-call rotation, the eighteen months of bugs we have already absorbed on your behalf — is not. That second part is what we sell. We charge a small enough amount for it that the spreadsheet works in your favor before you’ve even opened the dashboard.
If you’ve gotten this far and you’re still going to vibe-code it, we genuinely wish you well. Bookmark our migration guides — you’ll know when you need them.
If you’ve gotten this far and the spreadsheet won, the free tier is right here. No sales call. No demo. No “let’s hop on a quick chat.” Just the product, ready when you are.
ShipSilently is a managed feature flag service with sub-millisecond edge evaluation, real SDKs, real audit logs, and a real human on the other end of support tickets. Start free — no credit card, no lock-in, migration guides if you outgrow us.