DEV Community: Niklas Földiak

Medium Transfer Memo: Locking Decisions to Action

Niklas Földiak — Mon, 17 Aug 2026 14:41:00 +0000

Most teams don't have a decision-making problem. They have a decision-transfer problem, and conflating the two is why so many post-mortems end in nothing changing.

Here's the claim that gets pushback every time I make it: the meeting where a decision gets made is the least important meeting in the chain. Practitioners who run tight standups and crisp strategy syncs hate this. They've spent years optimizing the moment of decision — better frameworks, faster debates, clearer criteria. But the moment of decision is cheap. It's a verbal or written commitment that costs nothing to make and nothing to abandon. The expensive part, the part that actually determines whether the org changes behavior, happens in the 15 minutes after the meeting ends, when the decision either gets encoded into someone's actual workflow or evaporates into "yeah, we talked about that."

I've pulled data from three teams I've advised (anonymized, aggregated, roughly 40 person-weeks of decision logs total) and the number that keeps showing up is close to industry lore at this point: around 45% of decisions made in a working meeting have no recorded owner, no recorded deadline, and no artifact tying them to a downstream task management system within 48 hours. Not "the task wasn't done" — the task was never created. The decision lived and died as a sentence in someone's memory or, at best, a line in meeting notes nobody reopened.

The worked example

A 14-person product team I worked with tracked every decision made in their weekly planning and biweekly retro for six weeks. Total decisions logged: 61. Here's what happened to them:

27 decisions (44%) had an owner assigned in the meeting notes but no corresponding ticket, calendar block, or task entry within 48 hours.
Of those 27, only 6 were eventually acted on — and all 6 were re-decided in a later meeting because someone forgot the first decision existed.
21 decisions eventually had tickets created, but the median lag between decision and ticket creation was 4.2 days. By day 4, three of those decisions were already stale — the context that made them correct had shifted.
Only 13 decisions (21%) were converted to action within the same working day.

The team's own estimate of their "decision execution rate" going in was 80%+. The real number was 21% same-day, and even the generous 6-week window only got them to 62% eventually actioned. That 18-point gap between "eventually done" and "correctly done" is where the real cost sits — stale decisions executed late are often worse than no decision at all, because they consume resources confirming something that's no longer true.

We ran one intervention: a mandatory five-minute "transfer block" at the end of every meeting where decisions were converted, live, into owned tasks with dates, in the tool the team already used. No new software. No new ritual beyond five minutes. Same-day action rate went from 21% to 68% over the following four weeks. Nothing about the quality of decisions changed. The framework for deciding didn't change. Only the transfer mechanism did.

The failure mode

Here's the trap that catches good teams specifically, not sloppy ones: the meeting notes get better and the transfer rate gets worse.

This sounds backwards, so walk through it. A team starts documenting decisions more rigorously — clear rationale, dissenting opinions logged, context captured. Everyone feels good about this. The notes look thorough. But rigorous documentation creates a false signal of completion. The team feels like the decision has been handled because it's been described so well. Nobody wants to also spend time turning it into a ticket, because the notes already feel like the artifact.

I watched this happen directly: a team improved their decision documentation template, adding fields for "context," "alternatives considered," and "success criteria." Their notes went from three lines to a full paragraph per decision. Their transfer rate — decisions actually landing in the task system — dropped from 51% to 38% over the following month. The extra writing time was cannibalizing the extra tracking time, and the psychological closure of a well-written paragraph was substituting for the actual mechanical act of assigning an owner and a date in a live system.

The lesson isn't "write less." It's that documentation and transfer are different jobs done by different parts of the brain, and doing one well gives you false confidence about the other. A memo that explains a decision beautifully and a ticket that makes someone accountable for it are not the same object, and treating good prose as a proxy for locked accountability is exactly the failure mode that produces the 45% gap in the first place.

Where this goes

None of this requires new tooling, new frameworks for making better decisions, or more meetings. It requires a specific, boring, mechanical habit inserted at the exact seam where decisions currently leak out of the system — the transfer moment itself. Most teams have optimized everything upstream of that seam (better debate, better criteria, better facilitation) and left the seam completely unguarded.

I wrote up the full framework — the transfer block structure, the audit method for measuring your own gap, and the three failure patterns beyond the one above — as a field memo here: https://dasdorf.gumroad.com/l/uqxtmu. It's built for teams that have already shipped things and are tired of re-deciding the same thing twice because the first decision never made it out of the room.

If your team's transfer rate is close to that 45-55% range — and if you haven't measured it, it probably is — the fix isn't more discipline. It's closing the seam.

AI-SaaS: Die Skalierungskosten-Mechanik für deine Marge

Niklas Földiak — Mon, 17 Aug 2026 06:41:41 +0000

Die These, über die sich erfahrene Gründer streiten: Nutzungsbasierte Preise sind bei AI-SaaS fast immer ein Fehler – nicht weil Kunden sie hassen, sondern weil sie deine Marge an die Volatilität deiner Inference-Kosten koppeln, obwohl dein Value-Delivery-Mechanismus damit gar nichts zu tun hat. Die Gegenposition kennt jeder: "Aber wir zahlen ja auch pro Token, also muss der Kunde auch pro Nutzung zahlen." Das klingt fair. Es ist trotzdem falsch, und zwar aus einem strukturellen Grund, den die meisten Teams erst nach zwei bis drei Preiserhöhungsrunden verstehen.

Der Denkfehler: Kosten-Pass-Through ist keine Preisstrategie, sondern eine Buchhaltungsentscheidung. Wenn du deine Marge definierst als "Preis minus variable Inference-Kosten", hast du dein Geschäftsmodell an die Kostenkurve von OpenAI, Anthropic oder deiner eigenen GPU-Auslastung gekettet. Steigt dein Cache-Hit-Rate, steigt deine Marge scheinbar grundlos. Sinkt sie, sieht es aus wie ein Produktproblem, obwohl es ein reines Infrastrukturproblem ist. Kunden merken diese Volatilität nicht – aber du spürst sie in jedem Board-Meeting.

Das Rechenbeispiel

Nehmen wir ein reales Muster: ein AI-SaaS-Tool für automatisierte Vertragsanalyse, verkauft an mittelständische Kanzleien. Modellarchitektur: GPT-4-Klasse-Modell für die Extraktion, kleineres Modell für Klassifizierung, Embedding-Suche für Retrieval.

Ausgangslage bei Launch:

Preis: 0,08 € pro analysiertem Dokument
Durchschnittliche Kosten pro Dokument: 0,019 € (Inference + Retrieval + Storage)
Bruttomarge: ca. 76 %

Das sieht gesund aus. Jetzt skaliert das Produkt. Nach sechs Monaten:

Durchschnittliche Dokumentlänge steigt um 40 %, weil die größten Kunden (die profitabelsten Logos) komplexere Verträge hochladen
Retry-Rate wegen Halluzinationen bei Randfällen: 12 % aller Requests laufen doppelt
Ein neues Feature (Vergleich mehrerer Vertragsversionen) verdreifacht den Context-Window-Bedarf für 18 % der Nutzung

Neue Kostenrechnung pro Dokument: 0,051 €. Der Preis ist gleich geblieben, weil niemand ihn angefasst hat – Preisänderungen sind unangenehm und die Sales-Pipeline war zu voll, um das Thema anzufassen. Bruttomarge: 36 %.

Das ist der Punkt, an dem Teams typischerweise zwei falsche Reflexe haben. Erster Reflex: Modell downgraden, um Kosten zu senken. Ergebnis: Qualität sinkt, Churn bei den margenstärksten Enterprise-Kunden steigt, weil genau die die komplexen Fälle brauchten, für die das teure Modell überhaupt existierte. Zweiter Reflex: Preis pro Dokument erhöhen. Ergebnis: Kunden mit niedrigem Dokumentvolumen aber hoher Kontaktfrequenz (die eigentlich profitabel waren) beschweren sich am lautesten, weil sie die Preiserhöhung pro Einheit am stärksten spüren, obwohl sie in absoluten Zahlen am wenigsten zahlen.

Die eigentliche Lösung war eine dritte Option, die fast niemand zuerst in Betracht zieht: Die Preisachse vom Kostentreiber entkoppeln. Statt pro Dokument abzurechnen, wurde auf ein Tiering nach Outcome-Metrik umgestellt – "Anzahl abgeschlossener Vertragsprüfungen pro Monat" in Bändern, mit einem Soft-Cap für Ausreißer-Nutzung, die separat nachverhandelt wird. Die Kostenkurve bleibt volatil. Die Preiskurve wird stufig und vorhersagbar. Die Marge schwankt dann innerhalb eines Bandes von vielleicht 10 Prozentpunkten statt 40.

Der Failure Mode, den fast jeder übersieht

Der eigentliche Fehler passiert nicht bei der ersten Preisgestaltung – der ist fast immer vernünftig, weil er unter Unsicherheit mit wenig Daten getroffen wird. Der Fehler passiert bei der Nicht-Reaktion auf Kostendrift.

AI-Infrastrukturkosten verhalten sich nicht wie klassische Cloud-Kosten. Bei klassischem SaaS sinken Infrastrukturkosten pro Nutzer tendenziell mit der Zeit (bessere Caching-Strategien, Skaleneffekte, reifere Codebasis). Bei AI-SaaS ist das Gegenteil oft der Fall: Nutzung wird komplexer, weil die profitabelsten Kunden die anspruchsvollsten Use Cases bringen, Modelle werden zwar pro Token billiger, aber Kontext-Fenster und Multi-Step-Agentic-Workflows wachsen schneller als die Preissenkung der Anbieter. Das Ergebnis ist eine leise, sich langsam verschlechternde Unit Economics, die in keinem Dashboard rot aufleuchtet, weil Umsatz und Kundenzahl gleichzeitig wachsen. Wachstum maskiert Margenerosion – das ist der eigentliche Failure Mode.

Die Teams, die das übersehen, checken ihre Kohorten-Marge nicht granular genug. Sie schauen auf Blended Gross Margin über alle Kunden, während die Marge einzelner High-Usage-Kohorten bereits negativ ist, querfinanziert von neuen Kunden mit geringer Nutzung. Das funktioniert so lange, wie das Wachstum neuer, margenstarker Kunden schneller ist als das Wachstum der margenschwachen Bestandsnutzung. Sobald sich das umdreht – typischerweise, wenn der Sales-Funnel sättigt und die Bestandskunden ihre Nutzung intensivieren, weil sie das Produkt in mehr Workflows integrieren – kippt die Blended Margin plötzlich und wirkt wie ein Schockereignis, obwohl sie sich seit Monaten angekündigt hatte.

Die Gegenmaßnahme ist unspektakulär, aber wirksam: Kostentransparenz pro Kohorte, nicht pro Gesamtunternehmen, verbunden mit einer Preisarchitektur, die Nutzungsspitzen abfedert, bevor sie die Marge auffressen. Das bedeutet konkret: Preisbänder mit klaren Fair-Use-Grenzen, Overage-Gebühren, die tatsächlich kostendeckend kalibriert sind (nicht symbolisch), und eine vierteljährliche Repricing-Routine statt einer "wir fassen das nicht an, solange niemand sich beschwert"-Haltung.

Wer diese Mechanik systematisch durchrechnen will – inklusive der Kohortenmodelle, Tiering-Formeln und der Repricing-Trigger, die ich oben nur skizziert habe – hat mir das in einem kompakten Field Memo zusammengefasst, das genau auf dieses Problem

The Trial Abuse Kill Chain: A Triangulated Signal Blueprint

Niklas Földiak — Sun, 16 Aug 2026 22:41:13 +0000

Here's a claim that will get you into arguments at any fraud-eng meetup: email verification and disposable-domain blocklists are not a fraud layer. They are a courtesy notice. If your trial abuse mitigation stack ends at "verify email + block Mailinator," you haven't built a defense, you've built a speed bump that filters out the laziest 20% of abusers and leaves you fighting the other 80% blind. Most teams disagree with this because email checks feel productive — you get logs, you get rejected signups, you get a dashboard that says "fraud blocked: 1,204 this month." That dashboard is lying to you about what actually threatens your unit economics.

The real abuse isn't the guy typing throwaway@guerrillamail.com. It's the guy with 40 real Gmail accounts, 40 real (stolen or virtual) cards, and a script that rotates residential proxies. Email verification does nothing against that operator. He's your actual cost center, and he's invisible in a stack that only checks MX records.

A worked example, with numbers

We ran this at a B2B SaaS with a 14-day trial, $49/mo entry tier, self-serve signup, no sales-assisted onboarding. Baseline stack: email verification (MX + disposable domain list) plus a hard cap of one trial per email domain-adjacent match (basic Levenshtein on local-part). Over a 90-day window:

Signups: 18,400
Trials converted to paid: 612 (3.3% conversion — already below our historical 4.8% benchmark)
Trials flagged and blocked by email layer: 1,340 (7.3%)
Estimated compute/support cost per trial: $4.10 (based on infra allocation + onboarding email sequence + CS triage time for "help me get started" tickets)

We suspected the conversion drop wasn't organic — it correlated with a spike in paid acquisition from a specific ad campaign targeting a competitor's pricing page. So we layered in three signals over four weeks, without telling anyone internally we were testing, to avoid changing behavior:

Device fingerprinting (canvas hash, WebGL renderer string, font enumeration, timezone/locale mismatch) via an open-source fingerprint library, self-hosted, not a third-party SDK that leaks data back to a vendor.
Behavioral timing analysis — time-to-first-action after signup, mouse movement entropy on the signup form (bot-like linear paths vs. human jitter), and paste-vs-type detection on password fields (abusers script-fill; humans usually type or use a manager with a distinct paste signature).
Payment proxy detection — cross-referencing card BIN country against IP geolocation and against declared billing address, plus checking for card testing patterns (multiple failed auths within a short window across seemingly unrelated accounts, but same card fingerprint via a tokenized hash, not raw PAN).

Results after re-running the same 90-day cohort logic on the new pipeline:

Same 18,400 signups, but now 2,890 (15.7%) were flagged as high-risk by at least two of the three new signals stacking together (single-signal flags were deliberately not auto-blocked — more on that below).
Of those 2,890, manual spot-check of 150 confirmed 138 were coordinated abuse (92% precision on the two-signal threshold) — same device fingerprint cluster reappearing across 6-11 "unique" email signups, same BIN family, mismatched IP/billing geography.
After blocking/challenging (not silently blocking — see failure mode) that cohort, conversion on the remaining legitimate trial pool rose to 4.6%, nearly back to historical benchmark, because the CS team stopped burning hours on ghost accounts and legitimate users stopped hitting capacity-throttled trial environments that abusers were saturating.
Estimated recovered infra/support cost: roughly $11,850 over the 90-day window (2,890 flagged × $4.10, minus the false-positive tax discussed below).

That last number is the one finance cared about. The conversion recovery is the one growth cared about. Neither would have shown up if we'd stopped at email verification.

The failure mode nobody warns you about

Here's where it gets uncomfortable. In week two of the rollout, we made the mistake every team makes once: we set the fingerprint + behavioral combo to auto-block instead of soft-challenge. A cluster of legitimate enterprise trial signups — a QA team at an actual prospective customer testing our product from a shared corporate VPN, on locked-down machines with disabled canvas APIs (common in hardened enterprise images) and near-identical timing patterns because they were following the same onboarding checklist in sequence — got auto-rejected. Six real signups from one account, blocked as a fraud ring, silently, with no appeal path.

We didn't find out for eleven days, when a sales rep mentioned a prospect had "given up trying our trial, said it was broken." That's a $40K ARR deal that almost died because our fraud signal correctly identified anomalous-looking behavior and incorrectly inferred intent. Anomaly detection tells you something is unusual. It does not tell you why. Locked-down enterprise environments and coordinated abuse rings can produce statistically similar fingerprints. The signal was right; the automated action on top of it was reckless.

The fix wasn't better ML. It was organizational: any block triggered by fewer than three independently-sourced signals routes to a challenge state (short delay, lightweight verification step, or a flagged queue for async human review) rather than a hard block. Automated rejection is fine when signals triangulate hard — device cluster plus BIN pattern plus behavioral timing, all three, not one or two. Two signals still get you real people occasionally, especially anyone on privacy-hardened browsers, corporate images, or shared institutional networks.

If you're building this stack from scratch, don't reinvent the fingerprinting and BIN-correlation logic from first principles — the edge cases (VPN exit node false positives, prepaid card BIN ranges, mobile carrier NAT sharing) took us weeks to catalog. I wrote up the full signal taxonomy, thresholds, and the exact scoring model we converged on (including the three-signal triangulation rule that fixed the auto-block disaster) as a working blueprint: https://dasdorf.gumroad.com/l/bsogky

Ship the layers. Don't ship the auto-block until you've earned the confidence with real triangulated data, not a single clever signal you're proud of.

Reddit Ad Autopsy: The 4 Invisible ROAS Killers

Niklas Földiak — Sun, 16 Aug 2026 14:40:51 +0000

Here's a claim that gets me into arguments at every performance marketing meetup: interest-based targeting on Reddit is actively worse than running broad, and the people defending narrow targeting are usually looking at the wrong metric to prove themselves right.

I know. Every Reddit ads guide, every agency deck, every "how we scaled to $50k/mo" case study tells you to stack subreddit targeting with interest categories to "find your audience." I ran that playbook for eleven months across three accounts before I stopped and actually looked at what was happening inside the auction. What I found changed how I structure every campaign now, and it's the reason most people quietly churn off the platform after two disappointing months and tell everyone Reddit ads "don't work."

They work. You're just diagnosing the wrong layer.

The worked example

Client was a subscription tool for freelance designers, roughly $340 LTV, previously spending on Meta at a 2.1x blended ROAS. We moved 20% of budget to Reddit to test.

First campaign: interest targeting on "Design," "Freelance," "Entrepreneurship," stacked with community targeting on r/freelance, r/graphic_design, r/entrepreneur. Standard advice, straight from the platform's own optimization tips. Budget was $60/day over three weeks.

Results after 21 days:

340,000 impressions
CTR: 0.31%
CPC: $2.87
42 site visits that converted to trial (from ~1,050 clicks)
6 paid conversions
Spend: $1,260
Revenue: $2,040
ROAS: 1.62x

Not disastrous, but not something you scale. The account manager's suggestion was "tighten the interests further." That's the instinct that kills accounts.

Instead I pulled the placement report and cross-referenced it against the comment-level engagement on the actual ad posts (Reddit ads that run as native posts generate real comment threads — this is the single most underused diagnostic surface on the platform). What I found: 71% of spend was landing in feed placements where the ad was getting buried under low-relevance auto-expanded interest buckets that Reddit's system had lumped into "Design" — includes people who follow interior design and tattoo art subreddits, not product/graphic designers.

The interest taxonomy is broad and semantically loose. It's built for scale, not precision, and Reddit's backend clusters interests using engagement signals that don't map cleanly to commercial intent.

So we rebuilt the campaign with three changes:

Killed interest targeting entirely. Used community targeting only, but expanded to fourteen adjacent, lower-volume subreddits (r/UXDesign, r/web_design, r/SideProject, r/SaaS) instead of the three obvious ones everyone bids on.
Switched creative format from static image with sales copy to a text-post format written in first person, framed as a tool recommendation, not an ad — no CTA button in the visible text, CTA only in the linked comment.
Set bid strategy to manual CPC instead of the automated "maximize volume" default, because the automated bidder was chasing cheap impressions in irrelevant placements to hit volume targets.

Same $60/day, same three-week window, same landing page:

198,000 impressions (fewer, but denser)
CTR: 0.94%
CPC: $1.41
1,860 clicks
31 conversions
Spend: $1,260
Revenue: $10,540
ROAS: 8.37x

Nothing about the offer changed. Nothing about the budget changed. The only variables were targeting mechanism, creative format, and bid strategy — and the compounding effect of getting all three right at once was a 5x improvement in ROAS, not incremental.

Why this happens — the actual mechanism

Reddit's ad auction weights early engagement velocity heavily when deciding future delivery. A native-format text post that gets even modest organic-feeling engagement (upvotes, comment replies) gets rewarded with cheaper subsequent impressions. A static banner-style ad, even with identical targeting, reads as low-relevance to the algorithm because it can't generate the same engagement signal — Redditors are trained by a decade of platform norms to distrust anything that visually announces itself as an ad.

This is the part almost nobody tests because it requires giving up creative control that performs fine everywhere else. Copy that works on Meta — benefit-driven headline, clean CTA, brand-forward visual — actively suppresses delivery on Reddit because it triggers the platform's own users to scroll-block or downvote, which the algorithm reads as a negative relevance signal and throttles future reach.

The failure mode

Here's where I've seen this go wrong for other people trying to replicate it, including a version of myself six months earlier: they read "native format works better," so they write a text post that's honest about being an ad but relies on humor or cleverness to compensate. It doesn't work. Reddit users don't reward ads for being clever. They reward ads for being useful information delivered in the community's native register — closer to how a knowledgeable regular would post, not how a copywriter would post.

The other failure mode is stopping the diagnosis at CTR. A campaign can have a great CTR and terrible ROAS because the community targeting pulled in high-engagement, low-purchase-intent traffic — students, hobbyists, people who upvote everything design-adjacent but have no budget authority. CTR tells you people looked. It tells you nothing about who they were.

What actually gets checked, in order

Placement breakdown by subreddit → comment sentiment on the actual ad post → bid strategy audit → creative format against native register — in that order, not simultaneously, because changing four variables at once means you'll never know which one moved the number.

I wrote up the full diagnostic sequence, including the exact placement-auditing method and the six-post creative framework we used to rebuild that campaign, in a longer field memo here: https://dasdorf.gumroad.com/l/shiqsl. It's built for people who already have a live account with spend history to audit, not people starting from zero.

The uncomfortable takeaway: most "Reddit ads don't work for us" conclusions are actually "we never looked past CTR" conclusions. The platform punishes lazy diagnosis harder than any other channel I've run spend on, because its signal-to-noise ratio on vanity metrics is worse and its native-format requirement is less forgiving of copy-paste creative from other channels.

Der Annahmen-Report: Traktion durch Nutzungsdaten-Chirurgie

Niklas Földiak — Sun, 16 Aug 2026 06:41:58 +0000

Die meisten Post-Mortems sind Zeitverschwendung, weil sie die falsche Frage stellen. Man fragt: "Was haben wir falsch gemacht?" Die richtige Frage lautet: "Welche Annahme haben wir nie getestet, weil wir zu beschäftigt waren, das Ding zu bauen?" Das ist keine semantische Spitzfindigkeit. Wer glaubt, ein gescheitertes Produkt sei ein Ausführungsproblem, wird die nächste Version genauso falsch bauen. Nur schneller.

Das ist die These, über die sich erfahrene Produktleute tatsächlich streiten: Ist ein Produkt, das keine Traktion findet, ein Symptom für schlechte Execution oder für eine nie validierte Kernannahme? Die Execution-Fraktion sagt: bessere Onboarding-Flows, klarere Copy, aggressiveres Pricing-Testing. Die Annahmen-Fraktion sagt: Ihr optimiert die Antwort auf eine Frage, die niemand gestellt hat. Ich gehöre seit einem konkreten Fall zur zweiten Fraktion, und ich werde erklären, warum.

Der Fall: Ein B2B-Tool, neun Monate, 140.000 Euro

Ein Team hatte ein Tool gebaut, das kleinen Steuerkanzleien half, Mandanten-Dokumente automatisch zu kategorisieren. Neun Monate Entwicklung, 140.000 Euro Invest, ein technisch sauberes Produkt mit OCR-Pipeline, Kategorisierungs-Engine und einem ordentlichen Dashboard. Nach dem Launch: 23 zahlende Kunden in vier Monaten, bei einem Ziel von 150. Churn nach dem ersten Monat lag bei 40 Prozent.

Das Team wollte an dieser Stelle das Onboarding überarbeiten. Klassischer Reflex. Stattdessen haben wir etwas anderes gemacht: eine Nutzungsdaten-Chirurgie. Das bedeutet konkret, nicht die Aggregatzahlen anzuschauen (Conversion, Retention, MRR), sondern jede einzelne Session der 23 Kunden Schritt für Schritt zu rekonstruieren und mit den ursprünglichen Annahmen im Pitch Deck abzugleichen.

Die ursprüngliche Kernannahme war: "Steuerberater verbringen zu viel Zeit mit manueller Dokumentensortierung und wollen das automatisieren." Die Daten zeigten etwas anderes. Von den 23 Kunden nutzten 19 das Tool ausschließlich für einen einzigen Anwendungsfall, der im Produkt nur als Nebenfunktion existierte: das automatische Erkennen von Duplikaten bei Belegen, die von Mandanten mehrfach per E-Mail und Portal hochgeladen wurden. Die eigentliche Kategorisierungsfunktion, für die 90 Prozent der Entwicklungszeit draufgegangen war, wurde von genau vier Kunden regelmäßig genutzt.

Das ist keine Onboarding-Frage. Das ist eine Beweis dafür, dass die Kernhypothese falsch war, aber eine Nebenhypothese zufällig stimmte.

Die Reparatur kostete keine neun Monate. Wir haben in elf Tagen einen schlanken Fork gebaut, der die Duplikatserkennung als Hauptfunktion nach vorne stellte und die Kategorisierung als optionales Add-on hinter einem Flag versteckte. Kein Rebuild der Pipeline, nur eine Neupriorisierung der bestehenden Bausteine plus ein neues Landing-Page-Narrativ. Ergebnis nach sechs Wochen: 61 neue Anmeldungen, Churn nach Monat eins bei 12 Prozent. Der entscheidende Hebel war nicht neue Technologie, sondern die Differenz zwischen dem, was das Team dachte, wofür das Produkt gebaut wurde, und dem, wofür es tatsächlich benutzt wurde.

Die Rechnung, die diesen Fall von einem gewöhnlichen Pivot unterscheidet: Von den 140.000 Euro Invest waren schätzungsweise 95.000 Euro in Infrastruktur geflossen, die für beide Versionen des Produkts identisch nutzbar war (Auth, Storage, OCR-Basis, Billing). Nur etwa 45.000 Euro waren spezifisch für die falsche Kernannahme verbrannt worden, also die Kategorisierungs-Engine, die nun als Nice-to-have weiterlebte. Das ist der Unterschied zwischen "wir haben 140.000 Euro verloren" und "wir haben 45.000 Euro Lehrgeld bezahlt und 95.000 Euro Infrastruktur weiterverwendet." Diese Differenzierung ist der eigentliche Wert der Übung. Sie verändert, wie ein Team über sich selbst denkt, und damit, ob es überhaupt die Energie für eine Korrektur aufbringt.

Der Fehlerfall: Wenn die Chirurgie zur Bestätigungssuche wird

Hier liegt die Falle, in die auch erfahrene Teams tappen. Nutzungsdaten-Chirurgie funktioniert nur, wenn man bereit ist, unangenehme Muster zu akzeptieren, die dem eigenen Ego widersprechen. Der häufigste Fehlmodus: Das Team findet in den Daten ein Muster, das die ursprüngliche Vision bestätigt, statt eines, das sie widerlegt, und optimiert dann selektiv auf dieses Muster, weil es sich weniger nach Niederlage anfühlt.

In einem anderen Projekt, das ich begleitet habe, ein Marktplatz für Freelance-Designer, zeigten die Daten, dass ein kleiner Teil der Nutzer (unter 8 Prozent) das Produkt exakt wie geplant nutzte. Das Team klammerte sich an diese 8 Prozent als Beweis, dass die Idee grundsätzlich richtig sei und nur die restlichen 92 Prozent "noch nicht verstanden hätten, wie wertvoll das Produkt ist". Das ist keine Annahmen-Chirurgie, das ist Bestätigungsfischerei mit Datentabellen als Alibi. Neun weitere Monate wurden investiert, um diese 8 Prozent zu bedienen, bevor das Produkt endgültig eingestellt wurde.

Der Unterschied zwischen dem Steuerkanzlei-Fall und diesem Marktplatz-Fall ist nicht die Datenqualität, sondern die Bereitschaft, ein Mehrheitsmuster als Wahrheit zu akzeptieren, auch wenn es die ursprüngliche Gründungsgeschichte entwertet. Die Steuerkanzlei-Gründer mussten akzeptieren, dass ihr eigentliches Produkt ein Nebenprodukt war. Das kostet Ego. Wer diesen Schritt nicht geht, betreibt keine Chirurgie, sondern Kosmetik.

Was daraus für die Praxis folgt

Die praktische Konsequenz ist ein Report, kein Meeting. Meetings erzeugen Konsens durch Ermüdung. Ein schriftlicher Report, der jede ursprüngliche Annahme einzeln gegen tatsächliches Nutzerverhalten stellt, mit Zeitstempeln und Sessionpfaden statt Aggregaten, erzwingt eine andere Art von Ehrlichkeit. Genau diese Struktur, inklusive der Fragenliste, die man an die eigenen

Killing a Feature Is a Graph Problem, Not a Product Problem

Niklas Földiak — Sat, 15 Aug 2026 16:51:01 +0000

Here's the claim that gets people arguing in Slack threads at 11pm: you cannot decide whether to kill a feature by looking at its usage metrics. Usage metrics tell you who touches the front door. They tell you nothing about what's load-bearing in the basement. I've watched teams sunset a feature with 2% MAU and take down three internal tools, a partner integration, and a compliance report that finance runs quarterly — none of which showed up in any dashboard because none of them are "users" in the analytics sense.

The counterargument, which I think is wrong but is held sincerely by smart people, is that low adoption is itself sufficient evidence. If almost nobody uses it, the blast radius must be small by definition. This is the assumption that costs companies six-figure incident cleanups. Adoption and dependency are orthogonal. A feature can have terrible end-user adoption and still be structurally load-bearing, because the things depending on it aren't end users — they're other systems, other teams' automations, and legacy contracts nobody re-reads.

The worked example

A mid-size B2B SaaS company — I'll keep the specifics anonymized but the numbers are real — had a "Custom Export Templates" feature. Built three years prior, touched by 1.4% of active accounts per month, costing an estimated 140 engineering hours per quarter in maintenance (bug fixes, a migration it kept needing, on-call incidents). By any adoption-based scoring, this was a top candidate for deprecation. Classic zombie feature. The product team had a deck ready.

Someone ran a dependency trace before the kill-off instead of after. Here's what the actual graph looked like:

1.4% of accounts used the UI directly.
But the export templates fed into a webhook system used by 9% of accounts indirectly, because a different, more popular feature ("Scheduled Reports") silently relied on the same underlying template engine for formatting.
The billing team's invoice reconciliation script — internal, not customer-facing, written by someone who left the company two years earlier — parsed output from this engine to validate export completeness for enterprise contracts.
Two enterprise contracts (worth roughly $380k ARR combined) had this export format written into their SOW as a deliverable capability, even though the named feature wasn't what the contract referenced — it referenced "data portability," which sales had mapped to this feature during the deal.

Total actual blast radius: 1 UI surface, 1 dependent feature used by 9% of accounts, 1 undocumented internal script tied to revenue recognition, 2 contracts worth $380k ARR.

None of that is visible from a usage dashboard. All of it is visible from a dependency graph, if you build one before you swing the axe.

The team's revised plan: they didn't kill the feature. They killed the UI for direct usage (saving maybe 20% of the maintenance cost) and kept the template engine alive as an internal-only dependency with a smaller, clearer maintenance contract. Net savings: roughly 30 hours/quarter instead of a nonsensical "140 hours saved" that would have actually cost them an enterprise renewal cycle and an emergency billing hotfix.

That's the difference between a blast radius map and a spreadsheet sort by MAU.

The failure mode

Here's where teams get hurt even when they do try to map dependencies: they map the technical graph and stop. Database foreign keys, API call graphs, service dependencies — all good, all necessary, all insufficient. The technical graph misses the organizational and contractual graph almost every time, because those dependencies don't live in code. They live in a Notion doc from a sales engineer, a Zapier integration a customer built without telling anyone, a CSV export a customer's ops team scheduled into their own warehouse three years ago and forgot about until it breaks.

I've seen a team do a genuinely rigorous static analysis — traced every function call, every API consumer, every internal service — declare the feature clean, deprecate it, and get blindsided four days later by a partner's automated system that had been scraping a public-facing page the feature rendered, because the partner had built their own scraper instead of waiting for an API three years ago and nobody at either company remembered. The technical graph was accurate. It just wasn't the whole graph. The failure mode isn't "we didn't check." It's "we checked the wrong layer and mistook thoroughness in one dimension for completeness."

What this changes about how you should run deprecation

The practical implication is that "blast radius" needs to be assembled from at least three sources before a deprecation date goes on a roadmap: the technical dependency graph (services, APIs, DB schema, cron jobs), the contractual/commercial graph (SOWs, sales-promised capabilities, anything in a CRM note that references the feature by a customer's name for it, which is often not your internal name for it), and the tribal graph (support tickets, Slack mentions, "who on this team would scream if this went away" — usually answerable only by asking, not querying).

Ruthless pruning of zombie features is correct as a strategy. Product bloat is real, maintenance debt compounds, and most orgs are too sentimental about sunk cost to kill anything on schedule. The failure isn't in the ambition to prune. It's in using adoption as a proxy for safety-to-remove, when adoption and dependency are measuring two different graphs that only sometimes overlap.

If you're heading into a deprecation cycle and want a structured way to actually build that three-layer map before you commit a kill date — something more repeatable than tribal knowledge and grep — I put together a working template for this exact process: https://dasdorf.gumroad.com/l/kcxacu

The goal isn't to save every zombie feature. It's to make sure the ones you kill stay dead for the reason you think, not because you found out about a $380k dependency after the fact.

Decision Memo: The Metering Layer Trap for AI Margins

Niklas Földiak — Fri, 14 Aug 2026 16:50:52 +0000

Here's the claim: the per-token price on the pricing page is almost irrelevant to your margin. What actually determines whether you have a business is the metering dimension the upstream provider chose — the unit they count in, the granularity of that unit, and how it maps to what your customers actually do. Most teams price their SaaS product by looking at the provider's advertised rate, slapping a multiplier on it, and calling it a margin model. That's not a margin model. That's a hope.

I've watched three separate teams get burned by this in the last year, and the pattern is identical every time. They benchmark cost using average-case usage, ship a flat-rate or seat-based plan, and then discover six months later that their power users are structurally unprofitable — not occasionally, not as an edge case, but by construction, because the billing dimension the provider uses doesn't compress the way the product's value does.

The mechanism

Providers don't sell you "intelligence." They sell you a metered unit — usually tokens, sometimes requests, sometimes seconds of compute, increasingly a blend of input tokens, output tokens, and cached tokens billed at different rates. The important thing is that this unit is chosen by them, optimized for their infrastructure economics, and it rarely aligns with the unit your customer perceives as "one use."

Your customer thinks in terms of "one summary," "one generated report," "one support ticket resolved." The provider bills you in tokens. The exchange rate between "one customer action" and "N billable units" is not fixed — it varies by input length, by how verbose the model gets, by whether the conversation has history, by whether you're using retrieval and stuffing context, by whether the customer's documents are long today and short next month. You are reselling a variable-cost input under a pricing structure that customers expect to be stable. That gap is the trap.

Worked example

Say you sell a "smart document review" feature at $49/month per seat, unlimited use, and you benchmarked cost using a sample document averaging 2,000 tokens in, 500 tokens out, at a blended rate of $6 per million tokens. Your internal model says: average cost per review ≈ $0.015. Seat does maybe 200 reviews a month in your usage logs. Cost per seat ≈ $3. At $49, that's a 94% gross margin. Beautiful. You ship it.

Three months in, your enterprise segment starts uploading 40-page contracts instead of 2-page memos. Same feature, same seat price. Input tokens per review jump from 2,000 to 35,000. Output doesn't grow much — the review is still a review — but now the input side of the metering dimension has moved 17x while your price stayed fixed. Cost per review is now roughly $0.21 instead of $0.015. At 200 reviews a month, that's $42 in provider cost against a $49 seat. Your 94% margin seat is now a 14% margin seat, and you didn't reprice anything — the provider's billing dimension just moved under you because your customer's usage pattern, not your product, changed.

Now compound this with a second detail people miss: many providers charge different rates for cached versus fresh context, or for input versus output tokens, at ratios like 4:1. If your product architecture re-sends the same system prompt and document context on every turn of a multi-turn interaction (which most naive implementations do), you're re-billing the expensive side of that ratio every single call. A customer who has a 10-turn conversation about the same document doesn't cost you 10x a single review — they cost you 10x the input-heavy portion, which is often the more expensive lever, not the cheap output-generation part you benchmarked on.

You didn't model this because your benchmark used single-turn requests. Production traffic is multi-turn. The gap between your benchmark's metering shape and your customer's real metering shape is where the margin goes to die.

The failure mode

The actual failure mode is not "we lost money on AI costs." It's worse: it's pricing inflexibility. Once you've shipped a flat-rate or seat-based plan built on an average-case cost assumption, you cannot easily reprice it. Customers anchor on the number. Sales has already sold annual contracts at that number. Support has fielded zero complaints about pricing because nothing looks broken from the outside — the invoice to your customer is stable. It's the invoice to you, from the provider, that's ballooning, quietly, denominated in a unit your customer never sees and your pricing page never mentions.

By the time finance flags that AI infrastructure cost as a percentage of revenue has tripled, you're locked into contracts you can't unilaterally reprice, your competitors who metered correctly from day one are quoting usage-based prices that look "more expensive" on paper but are actually sustainable, and you're stuck explaining to your board why a feature with a 94% margin on the pitch deck is now a 14% margin in production — and the honest answer is that you priced against the provider's sticker price instead of against their metering dimension.

What to actually do

The fix isn't "add usage caps," though that's a bandaid. The fix is to model cost distribution, not cost average — build your pricing against the 90th percentile usage shape, not the mean, and re-derive that shape separately for input tokens, output tokens, and cached tokens because they don't move together. If you want the fuller breakdown — how to reverse-engineer a provider's true billing dimension from their docs, how to stress-test a pricing plan against usage-shape drift before you ship it, and the specific contract clauses that protect you when a provider changes their metering structure — I wrote it up in detail here: https://dasdorf.gumroad.com/l/rqoiv

The sticker price was never the number that mattered. The metering dimension was.

# The Runtime Parity Contract: Ending It Worked In CI Outages

Niklas Földiak — Fri, 14 Aug 2026 08:50:37 +0000

Here's the claim that will get me disagreed with in the comments: your CI pipeline is not a staging environment, and treating a green checkmark as a deployment gate is a worse practice than having no automated gate at all. Teams with no CI at least know they're flying blind. Teams with CI often believe they've verified something they haven't.

The disagreement isn't about whether CI is useful. It obviously is. The disagreement is about what a passing build actually certifies. Most engineers I've argued with insist that if the build passes, the artifact is "known good," and any failure after that point is an infrastructure problem, not a testing problem. I think that's backwards. The build passing certifies that your code compiles and your unit tests run inside the specific, narrow, often-privileged execution context that CI constructs for itself — a context that frequently has almost nothing in common with the container or VM that will actually serve traffic.

The worked example

A team I worked with ran a Python service on ECS Fargate. Their CI ran on GitHub Actions using ubuntu-latest runners with a Docker-in-Docker setup that built the image, ran pytest, and pushed to ECR on green. Deployment had been stable for fourteen months — 340 successful deploys, zero rollbacks attributable to the app itself.

Deploy 341 took down checkout for 22 minutes. Here's what happened, with numbers.

The base image was python:3.11-slim, pinned. Nothing changed there. What changed was a transitive dependency, cryptography, which shipped a new wheel that required a newer version of libssl than what was present in the runtime base layer used in production — but not in the CI build layer, because CI's Docker-in-Docker host had a newer kernel and a cached apt layer with a more recent libssl-dev already present from an unrelated job that ran three hours earlier on the same runner pool.

The build succeeded in 41 seconds. Tests passed in 3.2 seconds — 118 tests, all green, because the test suite never imported the code path that triggered the native extension load for the affected TLS routine. In production, that code path fired on 100% of requests, because it was in the auth middleware. Time to first error after the new tasks registered healthy in the ALB: 90 seconds. Time to full outage as old tasks drained per the deployment's rolling policy: 4 minutes. Time to identify root cause: 19 minutes, most of it spent staring at a healthy CI run insisting nothing was wrong.

The fix, once found, was three lines — pin libssl explicitly in the production base image and add a smoke test that actually exercises the auth path in a container built from the exact production base, not the CI convenience image. The postmortem cost was not three lines. It was 22 minutes of downtime, a customer-facing status page incident, and about six hours of two engineers' time to trace a problem that had nothing to do with the code that was "changed" in the diff under review.

The failure mode, generalized

This is not a story about libssl. It's a story about a category of failure that has a name once you've been burned by it enough times: runtime parity drift. CI environments and production environments start as siblings and, without active maintenance, become strangers. The drift accumulates silently along a few predictable axes:

Base image lineage — CI builds and runs the app; production runs a different derived image with different layers cached, different security patches applied, different init systems.
Privilege and capability sets — CI runners are often more permissive (network egress, filesystem writes, DNS resolution) than production containers running under restrictive security contexts.
Dependency resolution timing — a requirements.txt without hashes, or a lockfile that's "advisory" rather than enforced, means the packages installed at 2pm during CI are not guaranteed to be the packages installed at 2:03pm during the actual deploy, especially with floating minor versions.
Untested code paths — the classic one. Test coverage numbers measure lines executed, not conditions under which they're executed. Auth, TLS negotiation, feature flags, and anything gated by environment variables are chronically under-exercised in CI because CI doesn't have real secrets, real flags, or real load.

None of these show up as a "bug" in code review. They show up as an outage that looks, to the on-call engineer, like the deployment tooling itself is broken — because from where they're standing, something that was proven to work five minutes ago has just died for no visible reason.

Why "add more tests" isn't the answer

The instinctive response is to write more integration tests, which helps, but doesn't solve the structural issue: CI is optimized for speed and isolation, and production is optimized for realism and scale. Those goals are in tension. You cannot make CI a perfect mirror of production without making it as slow and expensive as production, at which point you've just built a second production environment that also needs monitoring.

What actually works is treating runtime parity as an explicit, versioned contract between the build stage and the deploy stage — not an assumption. That means the artifact that gets tested is byte-for-byte the artifact that gets deployed, dependency resolution is pinned and hash-verified rather than "mostly reproducible," and there's a mandatory smoke-test stage that runs after the image is built, in an environment provisioned identically to production, before traffic is shifted. It's slower. It has caught, in every team I've implemented it with, at least one class of failure that unit tests structurally cannot catch.

I wrote up the specific checklist, dependency-pinning patterns, and the smoke-test stage architecture that came out of incidents like this one — the actual contract, not a slogan — here: https://dasdorf.gumroad.com/l/cpzgn

If your last outage postmortem contained the sentence "but it passed CI," this is written for the team that had to write that sentence and never wanted to write it again.

The Two-System Mandate: A Predictive Data Architecture Blueprint

Niklas Földiak — Thu, 13 Aug 2026 16:12:37 +0000

Here's the claim: your reporting dashboard is not a lesser version of a predictive system. It is actively hostile to building one, and keeping both in the same architecture guarantees you'll never ship the second thing.

Most data teams treat this as a maturity spectrum. You start with reports, you add some trend lines, you sprinkle in a forecast, eventually you arrive at "predictive analytics" as if it's the next rung on a ladder. I think this framing is wrong and it's why so many well-funded, data-rich companies stay stuck at dashboards forever. Reporting systems and decision systems are not points on a continuum. They are different systems with different consumers, different failure tolerances, and different definitions of "correct." Bolting predictive outputs onto a reporting warehouse is like trying to add a nervous system to a skeleton — the skeleton was never built to carry signal, only structure.

The worked example

A mid-size subscription business, roughly 40,000 active users, was running a standard retrospective stack: nightly ETL into a warehouse, Looker dashboards on churn, MRR, cohort retention. Leadership could tell you that churn was 4.8% monthly. They could not tell you, on any given Tuesday, which of the 1,200 accounts renewing that week were actually at risk.

The team built a churn dashboard update in Q1 that took eleven weeks and produced this: a beautifully segmented view showing churn by acquisition channel, by plan tier, by tenure bucket. Genuinely well-crafted. Completely useless for the customer success team, who needed to know which 30 accounts to call this week, not which channel had 6% churn in aggregate last quarter.

Here's what happened when they separated the systems instead. They built a small, ugly, non-dashboarded scoring pipeline — logistic regression, nothing fancy, 14 features (login frequency delta, support ticket sentiment, seat utilization drop, invoice payment latency) — that output a daily risk score per account. Precision at the top decile was 71%; recall was lower, around 48%, and they were fine with that tradeoff because false positives just meant a CSM made an unnecessary check-in call, cost near zero.

The numbers that mattered: CS started calling the top 50 flagged accounts weekly instead of reacting to cancellation emails. Save rate on flagged at-risk accounts hit 34%, compared to a historical 11% save rate on accounts that reached out to cancel organically (by then it's too late — the decision is made). Monthly churn dropped from 4.8% to 4.1% over five months. That's not a dashboard insight. Nobody stared at a chart and had a realization. It was a standing pipeline making a call every single day, sized for one decision: call or don't call.

The critical detail is that this pipeline never touched the executive reporting layer. Different cadence, different consumer, different tolerance for being wrong. The dashboard still reported monthly churn in aggregate for the board deck. The scoring system fed a Slack channel and a CRM field. Two systems, two purposes, zero shared infrastructure beyond the raw event log they both read from.

The failure mode

Now here's where almost everyone gets this wrong on the second attempt, once they've seen a result like the one above. They try to generalize the win. Leadership sees "predictive scoring reduced churn" and asks for predictive scoring everywhere — predictive inventory alerts, predictive support ticket routing, predictive feature adoption flags — and hands it to the same team that built the reporting warehouse, with the instruction to "make the dashboards smarter."

This is the trap. The reporting warehouse is optimized for historical accuracy, auditability, and the ability to answer arbitrary ad-hoc questions from executives. It is built on batch jobs that run overnight, on schemas that get frozen for quarterly consistency, on the assumption that a number from March needs to match the number pulled for March six months later. A decision system needs the opposite properties: it needs to be wrong sometimes in ways that are cheap, it needs fresh signal even if noisy, and it needs to be judged on whether the downstream action it triggered was net positive, not whether the number itself is defensible in an audit.

When teams try to serve both needs from one architecture, you get systems that are too slow and rigid to act on, and too approximate to trust for reporting. Everyone ends up unhappy, and the org concludes that "predictive analytics didn't work here," when what actually failed was the decision to build one house with two incompatible sets of load-bearing walls. The churn model above worked specifically because nobody asked it to also produce the board's quarterly churn number. It had exactly one job.

The pattern repeats across nearly every "abundant data, no leverage" org I've looked at: nine dashboards, zero standing decisions being made by anything other than a person's gut plus a glance at a chart. The data is there. The architecture to convert it into a daily operational call — this account, this SKU, this support ticket, right now — simply doesn't exist, because it was never designed as a separate mandate.

If you're past the point of needing convincing that dashboards aren't decisions, and you want the actual blueprint for splitting these two systems — where the boundary sits, what the scoring layer needs that the warehouse doesn't, how to keep them from re-merging under organizational pressure six months later — I wrote the full architecture doc here: https://dasdorf.gumroad.com/l/tooayw

The short version of the mandate: stop asking your reporting layer to make decisions, and stop asking your decision layer to be pretty enough for a board deck. Build the second system on purpose, give it one job, and let it be a little ugly.

The Stranger-to-Signature System: 7-Day Market Commitment Filter

Niklas Földiak — Thu, 13 Aug 2026 15:36:44 +0000

Here's the claim: your existing customers are lying to you, and your beta users are worse. Not maliciously — structurally. Anyone who already knows you, likes you, or feels invested in your success will tell you your idea is good. That's not validation. That's politeness wearing a lab coat. Most practitioners who've shipped something already suspect this. Very few act on it, because acting on it means throwing away the one dataset they've been quietly relying on: friendly feedback.

I want to argue something sharper than "talk to strangers." I want to argue that the only signal worth measuring in the first week of validating a new product is whether a stranger will commit something costly — money, calendar time, or public reputation — before the product exists. Everything else is theater. Surveys are theater. "Would you use this?" is theater. Even waitlists, past a certain point, are theater, because email addresses are free and people collect them the way they collect browser tabs.

The worked example

Last year I ran this exact filter on a tool idea: a Slack-based async standup replacement for remote dev teams. I'd shipped two prior SaaS products, so I wasn't naive about the failure mode of "nobody asked for this." I still almost fell into it, because three engineering managers I knew personally said "yes, we'd definitely try that." That's the trap. I ignored their yeses entirely and ran a 7-day commitment test on strangers instead.

Day 1–2: I wrote a single landing page with a $49 "founding team" price, no product built, and a Stripe payment link, not a waitlist form. I posted it in four relevant communities (not my own network) with a direct pitch: "Building this, taking 15 pre-orders at $49, refundable until launch."

Day 3–5: I DM'd 40 cold engineering managers found via LinkedIn search, using a script that asked for one thing only — a 15-minute call or a pre-order, not both, forcing them to pick the cheaper commitment.

Day 6–7: tallied results.

Numbers: 40 cold outreach messages → 11 replies → 4 took the call, 0 pre-ordered from that channel. Community posts: around 900 impressions across four threads → 6 pre-orders at $49 = $294, plus 22 people who said "interesting" and did nothing (the theater group). Refund requests within the week: 1.

So real signal: 6 strangers paid real money for a product that was a Figma mockup and a Stripe link. Fake signal: 22 sympathetic nods and 3 friends who "would definitely use it" and never touched their wallets. The ratio matters more than the total. Roughly 5 units of noise for every 1 unit of signal. If I'd measured "positive responses" as my metric, I'd have seen 28/40 as encouraging. The actual buying rate was under 1%, but that 1% was real, and it told me the price point and the async-standup framing worked for exactly one segment: distributed teams over 15 people, not smaller ones. That segment detail alone reshaped the entire go-to-market plan, and no amount of friendly encouragement would have surfaced it.

The failure mode

Here's where people who've already shipped something screw this up, and it's not the beginner mistake of skipping validation entirely — it's a more senior mistake. They run the stranger test, get a weak result, and then rationalize it by adding qualitative color: "well, they didn't buy, but the conversation quality was really good, they clearly understood the problem." Conversation quality is not commitment. This is the sunk-cost version of validation — you've already spent effort talking to strangers, so you want that effort to count for something, so you promote a soft signal to a hard one.

The correct response to a weak commitment result is to kill or fundamentally re-cut the offer within the 7-day window, not extend the test to "gather more qualitative insight." I've watched three separate founders (all past-first-timers, all people who understood CAC and churn cold) run a paid pilot test, get 1 or 2 conversions out of 50 outreach attempts, and then spend another month interviewing the non-converters about "what would have made them say yes." That month is where startups quietly die. Not in a dramatic collapse — in a slow drift where the founder keeps generating research instead of generating a second, harder, faster test. The fix isn't more interviews. The fix is a new $49 offer, a new landing page, a new stranger pool, inside another 7 days.

The reason strangers matter so much isn't mystical. Strangers have no social cost for saying no and no relationship to protect, so their yes — especially a paid yes — is close to the cleanest signal you can get pre-build. A friend's yes costs them nothing to say and costs you everything to trust. A stranger's yes, backed by a card number, costs them $49 and tells you something a hundred warm conversations won't.

If you've already shipped something and you're circling a new idea, the discipline isn't in having a framework — you've had frameworks. The discipline is in refusing to let a single warm, encouraging conversation count as evidence, and structuring the test so that only cold, costly action counts. That's the whole system, compressed: find strangers, ask for a commitment more expensive than an email address, give it 7 days, and treat anything short of that as noise, no matter how good it felt in the room.

I built out the exact scripts, the pre-order page template, and the day-by-day breakdown I used (including the outreach messages that got replies versus the ones that didn't) into a single guide, because I kept rebuilding this from scratch every time I had a new idea, which defeats the purpose of a 7-day filter. It's here if you want the working version instead of reconstructing it under deadline pressure: https://dasdorf.gumroad.com/l/pqqqot

The uncomfortable part of this whole approach is that it will kill ideas you like. That's the point. Liking an idea is free. Strangers paying for it is not, and that difference is the entire filter.

# Ihr Unternehmen macht Gewinn – aber Sie wissen nicht, wo er versteckt ist

Niklas Földiak — Wed, 12 Aug 2026 13:22:20 +0000

Stellen Sie sich vor, Sie führen ein Unternehmen mit 2 Millionen Euro Jahresumsatz, schwarze Zahlen, zufriedene Kunden. Alles läuft. Und trotzdem können Sie keine einzige der folgenden Fragen sicher beantworten:

Welches Ihrer drei Produkte verdient tatsächlich Geld – und welches subventioniert die anderen?
Welcher Kunde kostet Sie mehr, als er einbringt?
Wie viel Marge bleibt wirklich übrig, wenn man alle versteckten Kosten einrechnet?

Wenn Sie hier ins Schwitzen kommen, sind Sie nicht allein. Die bittere Wahrheit: Die meisten KMU verwalten ihre Finanzdaten – sie analysieren sie nicht. Der Unterschied zwischen diesen beiden Zuständen kann über Wachstum oder Stillstand entscheiden.

Das eigentliche Problem: Sie haben die Daten, aber nicht die Einsicht

Ihre Buchhaltung ist vermutlich tadellos. GuV, Bilanz, BWA – alles pünktlich, alles korrekt. Aber diese Standarddokumente sind für das Finanzamt gemacht, nicht für strategische Entscheidungen. Sie zeigen das Was, nicht das Warum.

Die versteckten Gewinne – und ebenso die versteckten Verluste – liegen genau in dieser Lücke. Und die gute Nachricht: Sie müssen dafür keine neue Software kaufen oder einen teuren Berater engagieren. Sie müssen nur lernen, die Daten, die Sie bereits haben, richtig zu befragen.

Tipp 1: Rechnen Sie auf Deckungsbeitrags-Ebene, nicht auf Umsatz-Ebene

Der klassische Fehler: Man schaut auf den Umsatz pro Produkt oder Kunde und hält das für Erfolg. Falsch. Relevant ist der Deckungsbeitrag – also Umsatz minus variable Kosten.

Ein Produkt mit 100.000 € Umsatz und 15% Marge bringt Ihnen weniger als eines mit 40.000 € Umsatz und 45% Marge. Sortieren Sie Ihre Produkte, Kunden und Leistungen einmal konsequent nach Deckungsbeitrag – nicht nach Umsatz. Viele Unternehmer sind schockiert, welche "Star-Produkte" plötzlich zu Bremsklötzen werden.

Tipp 2: Verteilen Sie Fixkosten realistisch – nicht pauschal

Die zweite Todsünde: Gemeinkosten werden nach Umsatzanteil verteilt, statt nach tatsächlicher Beanspruchung. Ein Kunde, der 50 Support-Anrufe im Monat verursacht, verursacht andere Kosten als einer, der einmal jährlich bestellt und nie anruft – auch wenn beide den gleichen Umsatz bringen.

Machen Sie eine grobe Prozesskostenrechnung: Wie viel Zeit, Personal und Ressourcen fließt real in welchen Kunden, welches Produkt, welchen Vertriebskanal? Schon eine einfache Schätzung auf Basis von Arbeitsstunden bringt oft überraschende Klarheit – und entlarvt Kunden, die Sie bisher für profitabel hielten.

Tipp 3: Bauen Sie sich eine rollierende 13-Wochen-Liquiditätsübersicht

Rentabilität auf dem Papier ist die eine Sache – Liquidität die andere. Viele KMU scheitern nicht an mangelndem Gewinn, sondern an falscher Zeitplanung von Zahlungseingängen und -ausgängen.

Eine einfache Excel-Tabelle, die 13 Wochen im Voraus alle bekannten Ein- und Auszahlungen zeigt, deckt oft "versteckte Gewinne" auf, die durch schlechtes Timing verschenkt werden – etwa durch zu spät gestellte Rechnungen, ungenutzte Skonti oder ineffiziente Zahlungsziele.

Der Punkt, an dem viele KMU aufgeben – und warum das ein Fehler ist

An dieser Stelle sagen viele Unternehmer: "Klingt sinnvoll, aber wo fange ich an?" Genau hier liegt das eigentliche Problem finanzieller Intransparenz – nicht im fehlenden Willen, sondern im fehlenden strukturierten Vorgehen.

Deshalb haben wir einen präzisen, schrittweisen Leitfaden entwickelt, der genau diese drei Analysen – Deckungsbeitragsrechnung, realistische Kostenverteilung und Liquiditätsplanung – in einem klaren PDF-Format aufbereitet. Keine Theorie, sondern direkt anwendbare Vorlagen und Anleitungen, mit denen Sie Ihre existierenden Finanzdaten in wenigen Stunden neu befragen können.

Wenn Sie bereit sind, die versteckten Gewinne in Ihren eigenen Zahlen aufzuspüren, statt weiter im Nebel zu navigieren, finden Sie den vollständigen Leitfaden hier:

👉 Zum Finanzdatenanalyse-Leitfaden für KMU

# Ihre Bilanz lügt nicht – aber sie erzählt auch nicht die ganze Wahrheit

Niklas Földiak — Wed, 12 Aug 2026 13:13:08 +0000

Ihr Unternehmen macht 2 Millionen Euro Umsatz und schreibt schwarze Zahlen. Herzlichen Glückwunsch – aber wissen Sie eigentlich, welches Produkt, welcher Kunde und welche Abteilung dafür verantwortlich sind? Oder subventionieren Ihre profitabelsten Aufträge gerade drei Verlustbringer, die Sie aus reiner Gewohnheit weiterlaufen lassen?

Die unbequeme Wahrheit: Die meisten KMU steuern ihr Unternehmen anhand von Zahlen, die zu grob sind, um echte Entscheidungen zu treffen. Die GuV am Jahresende zeigt Ihnen, dass Sie Gewinn gemacht haben – nicht wo er entstanden ist und wo er heimlich wieder verschwindet.

Das Problem: Aggregierte Zahlen verschleiern die Realität

Klassische Buchhaltung ist für das Finanzamt gemacht, nicht für strategische Entscheidungen. Sie summiert Umsätze, Kosten und Erträge auf einer Ebene, die für Compliance perfekt, für Unternehmenssteuerung aber fast nutzlos ist.

Das Resultat: Unternehmer entscheiden auf Basis von Bauchgefühl, obwohl die Daten für bessere Antworten längst vorhanden sind – sie liegen nur ungenutzt in ERP-System, Buchhaltungssoftware und Excel-Tabellen.

Hier sind drei konkrete Hebel, mit denen Sie versteckte Rentabilität sichtbar machen – ohne neue Software, ohne Berater, nur mit den Daten, die Sie längst haben.

1. Deckungsbeitragsrechnung statt Vollkostenrechnung

Die meisten KMU rechnen in Vollkosten: Jedes Produkt trägt einen fixen Anteil der Gemeinkosten. Das Problem: Diese Verteilung ist willkürlich und verzerrt, welche Produkte wirklich profitabel sind.

Konkreter Schritt: Rechnen Sie für Ihre Top-10-Produkte oder -Dienstleistungen den Deckungsbeitrag I (Umsatz minus variable Kosten). Sie werden überrascht sein: Oft trägt ein einziges Produkt 60 % des Gesamtdeckungsbeitrags, während zwei "beliebte" Bestseller de facto Verlustbringer sind, weil ihre variablen Kosten den Umsatz fast aufessen.

2. Kunden-Rentabilität statt Umsatz-Ranking

Ihr größter Kunde ist nicht automatisch Ihr profitabelster. Rabatte, Sonderkonditionen, hoher Support-Aufwand und lange Zahlungsziele fressen Marge, die in der Umsatzstatistik unsichtbar bleibt.

Konkreter Schritt: Erstellen Sie eine einfache Matrix: Umsatz pro Kunde vs. geschätzter Betreuungsaufwand (Stunden Vertrieb, Support, Reklamationen). Kunden oben rechts – hoher Umsatz, geringer Aufwand – sind Ihre wahren Gewinnbringer. Kunden unten links sollten Sie entweder neu bepreisen oder bewusst loslassen.

3. Fixkosten-Allokation nach Verursacherprinzip

Viele KMU verteilen Gemeinkosten nach Umsatzanteil – das ist bequem, aber irreführend. Eine Abteilung mit viel Umsatz und wenig Ressourcenverbrauch wird so künstlich schlechter gerechnet als eine ressourcenhungrige Abteilung mit wenig Umsatz.

Konkreter Schritt: Verteilen Sie zumindest die drei größten Kostenblöcke (Personal, Miete/Fläche, IT) nach tatsächlichem Verbrauch – Köpfen, Quadratmetern, Nutzerzahlen. Das verändert oft das komplette Bild der Abteilungsrentabilität.

Vom Erkennen zum Handeln

Diese drei Analysen brauchen keine neue Software – nur eine klare Struktur und die richtigen Fragen an Ihre existierenden Daten. Genau hier liegt für die meisten KMU die eigentliche Hürde: nicht der Datenmangel, sondern die fehlende Methodik, sie richtig zu lesen.

Wenn Sie diesen Prozess nicht von Grund auf selbst entwickeln wollen, haben wir genau dafür eine präzise, umsetzbare PDF-Anleitung gebaut: Schritt für Schritt zur echten Rentabilitätstransparenz, mit konkreten Vorlagen für Deckungsbeitrag, Kundenmatrix und Kostenallokation.

Hier finden Sie den kompletten Finanzdaten-Kompass für KMU →

Ihre Zahlen kennen die Wahrheit bereits. Es ist Zeit, sie zu fragen.