When you look at great startups from the outside, it’s tempting to believe they won because they moved quickly, or because their founders were unusually insightful, or because they had better luck than average. All of that helps. But if you look closer -inside the walls where no press cameras point - you find something else.
Much of the work that matters most is invisible. Founders are trained to chase visible markers of progress: growth graphs, feature launches, fundraising rounds.
But most of what makes a startup durable lies in the hidden scaffolding: the dull, continuous work beneath:
clean data, stable infrastructure, internal tools, repeatability.
Dark work is the difference between a company that grows and a company that merely accumulates velocity until it flies apart.
This is the dark work.
No customers see it. Investors rarely ask about it. But sooner or later, everyone feels it.
The Early Illusion
A strange property of dark work is that you can ignore it for a long time and nothing terrible happens.
Everyone tells you to “move fast.” Everything feels urgent at the beginning - demos, customers, shipping. They hack things together. They tell themselves they’ll “fix it later.”
And you can, because the first version of a startup is small enough that duct tape holds.
But duct tape ages. And later rarely comes. That’s what makes it dangerous.
Most teams collapse not because they lost to competitors, but because they tripped over their own early shortcuts.
You don’t pay for dark work immediately. You pay later, with interest.
Through the lens of building Minus Zero …
At Minus Zero, we learned all of this firsthand.
We started like most deep-tech founders:
thinking the hardest problems were algorithmic - making the car drive better, interpreting complex scenes, closing the perception-to-control loop.
And we made real progress. Every month the system drove better. Models improved. Demos looked promising. But underneath, we were accumulating silent debt.
Data Chaos
Our data pipeline evolved organically - not deliberately.
Each time we mounted new cameras or recorded different scenarios, small changes were made to schema, storage structure, or naming. Individually harmless, but collectively chaotic.
Nothing broke at first. So we kept going.
Months later, as we evolves, we found: inconsistent schemas, timestamp drift, unaccounted sensor transformations, unclear labeling conventions, etc.
Bad data teaches the model to be confidently wrong.
Absence of dark work cost us more time than any model bug.
We weren’t fighting the world. We were fighting ourselves.
Infra & Tooling Debt
A similar thing happened with infra.
In the beginning, running models or experiments on a single machine or ad-hoc scripts was fine.
But as the team grew, tribal workflows became bottlenecks:
Only a few people knew how to run certain experiments
Preprocessing scripts had implicit assumptions only the author understood
There was random unaccounted commits in repos found much later.
We lacked reproducibility; runs couldn’t be re-created reliably
Debugging failures took days because logs were scattered or missing
Model performance differed depending on whose machine ran it
We didn’t lack talent - we lacked internal systems.
A few engineers became single points of failure.
Velocity dropped not because people worked less, but because every step required too much re-interpretation.
We felt fast when hacking individually, but slow when moving collectively. That’s the clearest signal dark work was missing.
Internal Alignment Problems
Dark work isn’t only technical. It’s cultural.
Without common schemas and internal language:
QA reported issues differently
engineers interpreted scenarios differently
evaluation definitions drifted between teams
Even defining “model regression” became a discussion.
We spent emotional energy debating definitions instead of fixing problems.
Not because people were wrong - but because no internal scaffolding existed. Without strong systems, culture becomes dependent on individuals.
When individuals disagree, progress stalls.
The Realization
There’s a moment every founder faces when they see the startup not as a product but as a living organism - one they’ve been starving without realizing it.
For us, that moment came when adding people slowed us down. And we started observing some weird patterns -
Engineers took weeks to ship simplest of things.
Different teams report different metrics
There is only one person who knows how X works
Incidents repeat
Fixes create new failures
There’s no more humbling signal. And we started investing time in reinforcing the scaffolding: building debugging tools, standardizing processes and definitions, documenting the code, find root cause of bugs instead quick-fixes, etc.
Nothing glamorous. From an optical perspective, the company looked as if it had stalled.
No customer clapped. No investor praised.
But slowly - things changed.
Outcomes became predictable.
Debugging became rational, not archaeological.
Meetings got shorter.
Arguments got fewer.
The company felt … lighter.
Moving as a team became possible again.
Dark work isn’t about going slower. It’s about removing the drag you didn’t know was there.
Looking back, we realized the most expensive thing was the time lost fighting our own internal chaos.
And similar signs are evident in successes of companies we looked up to.
Dropbox learned this the hard way. Different teams defined “active user” differently - some counted openers, some uploads, some link-clickers. Three groups, three realities. Dashboards lie when the data beneath them is crooked (that’s a great example to imagine the compounding effect of petty things.)
Eventually, Dropbox standardized definitions and pipelines - invisible work no customer saw, but from then on, decisions got clearer.
In 2011, an AWS outage took down Reddit, Quora, and parts of Netflix. Not because they were bad engineers - they’d simply grown faster than their infrastructure discipline. Startups often treat “temporary” systems as harmless. A cron job hacked at 3 a.m. quietly becomes the backbone of billing. Teams that survive prepare early - monitoring, logging, backups, incident playbooks - long before they seem necessary.
Rule of thumb: if something runs every day, assume it will fail catastrophically one day.
Stripe looks simple: one API call and you’re accepting payments. It just works.
Its real innovation was beneath the surface -deep logging, dispute tooling, tracing, redundancy. Patrick McKenzie once said Stripe could inspect every API transaction through multiple banking networks in real time. That’s not UI polish - that’s infrastructure. No one saw it. But it made Stripe trustworthy.
Figma’s “overnight” success took years. Before launch, Dylan Field’s team spent years perfecting low-level WebGL rendering so collaboration felt instant. Investors hate this kind of invisible work - there’s nothing to demo.
But when Figma finally shipped, it felt like teleportation. Competitors cloned the interface but not the depth - and kept losing.
If your foundations are deep enough, imitation becomes useless. That’s what turns invisible work into a moat.
Uber shows the cost of neglect. Between 2014 and 2016, velocity collapsed under technical debt - fragmented infra, inconsistent metrics, microservices chaos. Even simple questions like “Why did supply drop yesterday?” had multiple answers.
Eventually, Uber built massive internal platforms like Michelangelo, uDeploy, and uMonitor just to regain coherence. It took thousands of engineers and years of re-plumbing - but once the dark work was done, the company could move again.
A Founder’s Reflection
I used to think my job was to make the product work. Now I think my job is to make the work work.
Building an autonomous car felt like the real challenge. But building an autonomous culture - one that could run without heroic effort - was harder.
You don’t really grow as a founder until you realize that the most important systems are not in the car or in the models, but within the company.
We are made to believe startups die because the world was hostile. More often, they die because they break from within - overwhelmed by their own entropy.
A startup is like a bridge that people start building while others are driving on it. You can’t stop building. The smartest founders know when to pause and strengthen the beams that will hold the weight.
Every great company has two stories:
the one it tells the world, and the one beneath the floorboards.
It’s tempting to think the first story is the important one. But the second determines how long the company lasts.
I used to think best companies are the ones that execute the fastest. But velocity is an illusion.
The real advantage is frictionless-ness - it compounds quietly, until one day it becomes indistinguishable from speed.