Newgas reconstructs his timeline at a former startup and argues the value of the exercise isn't reaching a verdict but cataloging the small, ordinary signals engineers can observe — customer logos that never make API calls, KPIs whose definitions shift quietly, integrations stuck in staging for over a year. Individually each has a benign explanation, but in aggregate they describe a company whose external story has decoupled from its internal reality.
Submitted the essay to Hacker News where it accumulated 652 points and 284 comments, signaling broad resonance among engineers who recognized the pattern. The reception itself functions as evidence that the forensic checklist describes a widely shared experience rather than an isolated case.
The editorial uses Wirecard as the canonical case: engineers had access to systems that should have shown €1.9 billion in escrow, but the systems were architected so that no one owned the question of whether internal balances reconciled with anything outside the company. The argument is that fraud doesn't require sophistication to hide — it just requires that the verification step never be assigned to a specific role.
Drawing on the comment thread's chorus of Theranos, Wirecard, and FTX alumni alongside anonymous Series B engineers, the editorial argues that the common failure mode isn't gullibility about complex schemes. It's the default trust that auditors, executives, or investors have already done due diligence — a trust that is rarely warranted and almost never verified by the engineers building the underlying systems.
David Newgas's essay *Did my old job only exist because of fraud?* hit 652 points on Hacker News this week — a number that says less about the writing than about how many engineers recognized themselves in it. Newgas worked at a startup that ran hot, then cold, then quiet. Years later he's reconstructing the timeline and asking the uncomfortable question: was the product real, or was I shipping infrastructure for a story being told to investors?
He doesn't land on a definitive answer, and that's the point. The essay's value isn't the verdict — it's the forensic checklist of small signals an engineer can see from inside the org that, in aggregate, suggest the business doesn't work the way leadership says it works. The comments thread reads like a support group: Theranos alumni, Wirecard contractors, FTX engineers, and a long tail of people who worked at Series B companies whose names nobody outside their VCs' Slack will ever remember.
The pattern across all of them is the same. The engineers weren't fooled by anything sophisticated. They were fooled by the same thing that fools everyone: the assumption that the adults in the room had checked.
Fraud, from inside engineering, doesn't look like fraud. It looks like a backlog. The signals are mundane: a customer logo on the homepage that has never made an API call, a KPI whose definition quietly changes between quarterly all-hands, an integration with a 'major partner' that has been in staging for fourteen months and nobody seems to care. Each item on its own has a benign explanation. Together they describe a company whose external story has decoupled from its internal reality.
The Wirecard postmortem is instructive here. Engineers there had access to the systems that should have shown €1.9 billion in escrow accounts. The accounts didn't exist. But the systems were designed in a way that the question 'does this balance reconcile with anything external?' was nobody's job. The fraud wasn't in the code — it was in the *absence* of code that would have caught it. Theranos was similar: the lab engineers knew the Edison machines couldn't do what the sales deck claimed, but the org chart was structured so that nobody owned the reconciliation between 'what we sell' and 'what we run.'
The HN thread surfaces a quieter version of this that's more common than outright fraud: companies that aren't lying to investors so much as believing their own deck. The engineering team builds for the company that exists in the pitch. The pitch describes a company that doesn't exist yet. The gap is supposed to close. Sometimes it does. Sometimes the runway closes first, and the post-mortem reads like fraud because the gap got papered over month after month with optimistic metric definitions.
The distinction between 'aspirational' and 'fraudulent' is a legal one, decided years later by people with subpoena power. From inside, the day-to-day looks identical. You ship features for a customer profile that doesn't match the actual usage logs, you instrument metrics whose names are chosen by the CRO, and you eventually stop asking why the funnel conversion rate in the board deck doesn't match the one in your Looker dashboard.
The other thing the thread surfaces is selection bias in who notices. Engineers who own the warehouse see it first. Engineers who own auth see it second — they know who actually logs in. Engineers who own billing see it third, because they know who actually pays. Frontend engineers and infra engineers can work at a fraudulent company for years and never have a reason to notice, because their work product is downstream of revenue rather than measuring it. If you've never been curious about the gap between MAU as defined in the all-hands and MAU as defined by your `SELECT COUNT(DISTINCT user_id)`, you may have been working at one of these companies and not known.
The practitioner takeaway isn't paranoia — it's instrumentation. If your company's external metrics can't be reproduced from your internal warehouse using a query you could write in an afternoon, that's a finding, not a chore for the data team.
Three concrete habits that the HN thread, taken seriously, recommends:
Reconcile the deck against the warehouse, once. Pull last quarter's board deck. Pick three numbers: ARR, active users, retention. Try to reproduce them from raw event data and the billing system. If you can't get within 10%, ask why — not aggressively, but earnestly. The answer is either 'here's the definition document' (fine, you've learned something) or vague hand-waving (also fine, you've learned something different). The companies that turn out to be fraud are the ones where the question itself is treated as hostile.
Audit your top 10 customer logos. Pick the logos on your marketing site. Check the auth logs. How many of them have a user who logged in this quarter? How many have made an API call this month? Customer logos are the cheapest part of a fraud — a logo on a site requires no relationship, and pilots-that-never-shipped are a perfectly legal way to fill a homepage. They are also a perfectly accurate signal that the GTM motion is theater.
Watch the metric definitions, not the metric values. Numbers go up and down for legitimate reasons. Definitions change for one reason: the old definition told a worse story. Every time a KPI's definition changes — especially in a way that retroactively re-baselines historical comparisons — write it down. The pattern matters more than any single change.
None of this protects you from working at a company that turns out to be a fraud. The Wirecard and Theranos employees who did notice mostly couldn't act on it, and the ones who did act paid for it. What the instrumentation gives you is something narrower and more useful: the ability to leave with intent rather than in confusion, and the ability to tell the difference, in your next role, between 'this company is early' and 'this company is a story being told to someone who isn't looking closely.'
The 2026 vintage of engineers will work through a particularly hard version of this problem. AI revenue is opaque, usage metrics are easy to inflate (a single autonomous agent loop can light up a thousand 'active users'), and the gap between 'shipped to a customer' and 'in production at a customer' has never been wider. The companies that come out clean will be the ones whose engineers were allowed to ask Newgas's question out loud, with their employer's data, in their employer's tools, before the indictment forced everyone else to ask it for them.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.