Frankenstack: we named ourselves after your problem

You searched for the word. Maybe you own one. A stack of tools that mostly works, glued together by whoever built it, understood fully by no one. The word for that is frankenstack, and we took it on purpose — because we think the advice everyone gives about it is half wrong.

This post is the honest version: where the word comes from, what a frankenstack actually costs, and why the standard fix — consolidate everything onto one platform — doesn't work for the people we built this for.

What the word means

A frankenstack is a stack of tools assembled piece by piece, reactively, with no overall architecture — named after Frankenstein's monster, stitched together from parts that were never designed to fit.

The term is older than most people think. The earliest usage in print we could find is a May 2015 CIO interview with martech analyst Scott Brinker, who described the frankenstack as "a hodge-podge bunch of tools and data islands not integrated, not working in concert" — and treated it as a label already in circulation. A 2017 NATO cyber-defence paper named a monitoring framework Frankenstack, which is a tool that happens to share the name, not the origin of the insult. No individual is reliably credited with coining it. The spelling never settled either: frankenstack, franken stack and Frankenstein stack all mean the same thing, with the one-word form most common.

It started in martech and spread everywhere. Content teams have one (Trello, Slack, Google Docs, Notion). RevOps teams have one (Webform → enrichment → HubSpot → Slack → Calendly → Outreach). Retail has one (POS, OMS, ERP, CMS, each holding a different copy of the truth). Data teams have one. Enterprise AI teams have one. The word stuck because the shoe fits everywhere.

The symptoms (you probably know some)

• No single person can map the whole stack and explain how the pieces connect.
• The same fact lives in more than one place, and someone reconciles it by hand, forever.
• A vendor API change breaks a critical flow, and nobody notices until something downstream fails.
• Total spend across tools is unclear, or takes an afternoon of manual aggregation.
• When something breaks, vendors blame each other.
• The real system of record is in someone's head. When they leave, the stack amputates.

That last one is the killer. As one content lead put it: "No one but me knows where everything is — and I only know because of way too many late nights spent on maintenance."

How much does it cost? Honest answer: nobody knows, and the numbers don't agree

This is where most posts lie by precision. The published benchmarks disagree wildly: Okta counted 93 apps per average company (231 for large enterprises); BetterCloud reported 164 for mid-market; Zylo said 305 and flat; Torii argued 831, on the grounds that most studies only see what procurement approved. Pick three vendor reports, get three different worlds.

The counts disagree because they measure different things — and because the count was never the right question anyway. Two questions are better:

1. Is the same fact stored in more than one place? Every duplicate is a reconciliation job someone performs by hand.
2. Can a new person find the current version without asking? If the map lives in someone's head, that map is the most fragile component you own.

Some real numbers do survive scrutiny. McKinsey estimates 40% of enterprise tech spend goes to dormant licenses and redundancies. Flexera's cloud survey puts 27% of public cloud spend as waste. And one RevOps figure is brutal: responding to an inbound lead within five minutes matters, so a slow or broken handoff flow leaks revenue silently, with no error message.

The standard advice — and why it's half wrong

Search "frankenstack" and every result pitches the same cure: consolidate. Kill your stack of point solutions, move to the one platform, escape the monster. The vendors selling all-in-one platforms write these posts. The advice isn't fake — for them it's often correct.

But here's the part they skip: for a huge class of builders, consolidation is not an option. It's not a budget problem. It's structural.

If you're an indie developer or a small team shipping software, your stack is: one platform for hosting, another for the database, a third for payments, a fourth for analytics, a fifth for email, a sixth for domains and DNS, a seventh for auth. Each of these is best-in-class or cheap-enough-in-class, and — this is the part — the variety is the price of shipping. Building your own payment processor because Stripe "doesn't integrate with your database" is not escaping the frankenstack; it's building a worse one with your weekends.

The consolidation advice assumes the stack exists because nobody made a decision. But your stack exists because you made decisions — dozens of small, rational ones, each defensible at the time it was made. That's the difference between a mess and a way of life.

Composable vs. frankenstack: the distinction that matters

Shopify's take contains the sharpest one-line distinction in the whole conversation, so we'll steal it: the difference between a composable stack and a frankenstack is whether the architecture was designed or accumulated.

A composable stack has, per component: a defined API contract, a named owner, governed integration points, and monitoring. You can swap a piece without destabilizing the rest.

A frankenstack has none of that. Same tools, same count — different relationship between you and them. Which means the monster isn't the number of tools. It's the ungoverned seams between them. A 30-tool stack with clear ownership and monitoring is healthier than a 5-tool stack held together by a script one person wrote two years ago and forgot.

Our position: don't kill your frankenstack. Own it.

Everything above is the received wisdom. Here's what we think is missing from it.

The indie stack will never be one platform. The realistic goals are:

1. Inventory. You should be able to answer "what do I run, where, at what cost" in one screen. Most builders can't, because the answer lives across seven dashboards.
2. Ownership. Every tool has a name attached. Every integration has an owner. Retiring a tool should mean retiring its champion's decision — a real, emotional step that consolidation advice skips.
3. Observability of the seams. The failures don't come from the tools. They come from the connections: the webhook that silently died, the cron that stopped, the API key that expired, the integration that broke when the vendor shipped a change. Monitoring the tools is table stakes. Monitoring the seams is the actual job.
4. A stack that can be shown. This one is radical and underused: your stack is part of your product's credibility. When someone evaluates whether to trust your small SaaS, "what is this built on" is a real question. Being able to answer it publicly — hosting, database, payments, uptime — is a competitive advantage that only the deliberate builder has.

That's what we're building. Not a platform to replace your tools — a cockpit for the tools you already have: what runs where, what it costs, whether it's alive, and what it looks like from the outside.

The two questions we'd leave you with

Not "how many tools do you run." The two that actually predict whether your stack is a monster or just a stack:

1. If your payment provider shipped a breaking API change tonight, how long until you'd know — from your own monitoring, not from an angry email?
2. If you got hit by a bus (or simply took a week off), could someone else find the current version of everything without calling you?

If both answers are "yes, quickly" — congratulations, you have a composable stack, whatever its size. If either answer is a nervous laugh, you know exactly which seam to fix first.

The frankenstack isn't the enemy. Nobody knowing what it is — that's the enemy.