TOPS is the most abused number in edge AI.

It looks objective. It looks comparable

TOPS isn't a lie. It answers a real but narrow question: how many low-precision operations an accelerator can execute per second if every arithmetic unit stays perfectly fed. That "if" is doing enormous work. It says nothing about whether your workload can actually feed those units, whether your model survives the compiler intact, whether memory movement swamps the math, or whether the rest of the system keeps pace.

Most edge workloads aren't matrix-multiply problems anyway. They're streaming pipelines: sensors, copies, preprocessing, quantization, scheduling, synchronization, post processing, all of it running against a control deadline. Peak compute touches one slice of that. So the equation people carry in their heads,

is really

and TOPS only bends one term.

Compute-bound is the exception, not the rule

The roofline model is the cleanest way to see why. Every workload has two numbers: operations it needs, and bytes it moves. Divide them and you get arithmetic intensity.

High intensity means you're compute-bound, and more TOPS can help. Low intensity means you're memory-bound, and TOPS barely moves the needle. Here's the trap in every TOPS pitch: it quietly assumes your model lives on the compute-bound side. A lot of real pipelines don't. A fat convolution might keep the array busy, but resize, normalization, layout conversion, feature-map shuffling, NMS, tracking, and the small dynamic ops mostly spend their time shoving bytes around, not multiplying them.

Your real ceiling is whichever wall you hit first:

A 100-TOPS part can behave like something a quarter its size the moment bandwidth, data layout, or host-device transfers become the binding constraint.

DGX Spark - an interesting analogy to understand this

The cleanest public proof of this isn’t an edge board at all. It’s NVIDIA’s DGX Spark, a desktop AI box, and it argues the point better than any robotics part because every number is out in the open.

The headline spec is 1,000 TOPS of FP4. A literal petaflop on your desk. Then you read the next line: 128 GB of unified LPDDR5x at 273 GB/s. If you do hands-on, you would only touch that petaflop in half-second bursts before memory bandwidth choked it off. Not that FP4 units running slow, but because the chip starving for data. That gap between the sticker number and the sustained number is the entire thesis of this essay, printed on one spec sheet.

Every independent review landed in the same spot. One of them called the unified bandwidth the key bottleneck and clocked Llama 3.1 70B decoding at under three tokens per second on a machine rated for a petaflop. Another split it more precisely: prefill, which chews through the whole prompt at once, stayed competitive because it’s compute-bound; decode, which emits one token at a time and re-streams the weights for each one, fell off a cliff because it’s memory-bound. Same silicon, same model, two phases, two completely different ceilings. That’s the roofline model doing its job in public.

Now shrink it to something that ships on a robot. The Spark runs in a ~200 W envelope with active cooling and no deadline. Your Jetson or Hailo has a fraction of that power budget, a fraction of that bandwidth, and a control loop that will not wait. If a plugged-in desktop holding a petaflop of FP4 gets pinned by memory movement, a battery-powered perception stack gets pinned harder and sooner. The physics doesn’t care that one sits on a desk and the other sits on an axle.

- Utilization is the number nobody prints

Peak TOPS assumes 100% utilization. You will not see 100% utilization.

Run a 100-TOPS accelerator at 20% and you have a 20-TOPS device wearing a bigger label. Utilization bleeds out through unsupported operators, small tensors, dynamic shapes, memory stalls, kernel-launch overhead, CPU fallback, sync gaps, thermal throttling, and batch-1 execution. This is the whole reason a smaller accelerator sometimes beats a larger one on a specific job: less peak compute, but far more of it actually used.

- The tensor doesn't just get multiplied. It gets moved.

Inference is as much data logistics as arithmetic. Trace one camera frame:

Every arrow is latency: copies, cache misses, DMA setup, driver overhead, synchronization, layout conversion. And the intermediate activations are often much larger than the input frame, so they, not the image, dominate memory traffic. A lot of the time the accelerator isn't waiting on math. It's waiting on data. Move your tensors too much and the TOPS number stops meaning anything.

- Batch size flatters the wrong systems

The most flattering benchmarks are throughput benchmarks, and throughput loves batching: more work per scheduling event, higher utilization, prettier FPS. But a robot, drone, camera, or inspection rig lives and dies on batch-1 latency. You can't wait to collect eight future frames. You need this frame now.

So the numbers that matter aren't max FPS. They're p50, p90, p99, jitter, dropped frames, and how latency holds once the part is hot. A device that screams at batch 8 can be useless to a robot that needs steady batch-1 timing.

- Operator coverage is a performance feature

Hardware doesn't run models. It runs supported graphs. Map every operator cleanly and things fly. Leave a few unsupported and the graph gets partitioned between accelerator and CPU, and that's where performance dies. The usual offenders: custom NMS, dynamic reshape, oddball interpolation, LayerNorm, attention blocks, deformable convolutions, unusual activations, quantization patterns the compiler won't take.

The damage isn't that one operator runs slow. It's fragmentation:

Every boundary is another round of copies and synchronization. One unsupported op can drag down the whole graph around it.

- Quantization isn't free

Almost every edge TOPS figure is an INT8 figure. But models are usually trained in FP32 or FP16, and dropping to INT8 trades accuracy for speed. "Can this chip run INT8?" is the wrong question. "Can my model run INT8 without losing accuracy I care about?" is the right one. Classifiers usually quantize cleanly. Detection can, with effort. Depth, segmentation, pose, transformers, and regression-heavy heads are touchier. A monster INT8 accelerator loses its shine if your model needs FP16 to stay correct.

- Post processing eats your gains

Detection benchmarks love to hide the tail. The network emitting tensors isn't the finish line. You still owe box decode, confidence filtering, NMS, class filtering, track association, coordinate transforms, and temporal smoothing. On a lot of platforms, inference is accelerated and all of that runs on the CPU. Cut inference from 10 ms to 5 ms and you've saved nothing if postprocessing still burns 8. The product feels total latency, not the slice you optimized.

Benchmark the pipeline, not the part

Stop asking how many TOPS. Ask what the sustained, end-to-end p99 latency of your actual workload is. A real answer looks like this:

Now the bottleneck is visible, and inference is 11 of 40. Double the accelerator's TOPS and, at best, you shave part of that one slice. You cannot double the application.

A benchmark worth trusting reports batch-1 latency, p99, power, temperature, dropped frames, CPU utilization, memory-bandwidth pressure, post-quantization accuracy, operator fallback count, and host-device transfer time.

TOPS is a real number. The inference people draw from it usually isn't. The fastest chip on paper loses, routinely, to a smaller one that keeps data local, maps the whole graph cleanly, avoids CPU fallback, and holds stable latency when it's hot.

So next time you choice a silicon for your robot, or are perplexed why you are not able to achieve advertised specs, remember this.

It doesn’t. The robot still reacts late, still misses fast-moving objects, still feels a beat behind in closed-loop operation.

TensorRT didn’t fail. Inference was never the biggest latency problem to begin with - it’s just the only one anyone bothered to measure.

That’s the strange thing about robotics perception pipelines in 2026: the neural network is usually the most heavily optimized component in the entire chain, and almost everything around it is still running on default settings from three years ago.

Here’s what actually happens between a photon hitting the sensor and a steering command reaching the wheels:

Most benchmark decks show one box from this chain. The other eleven don’t make it into the slide.

Take a real profile - an engineer reports 18ms inference and feels good about it. Then someone times the whole pipeline:

Camera DMA              8 ms
Image decode            4 ms
Color conversion        3 ms
Memory copies           5 ms
Resize & normalize      5 ms
Inference               18 ms
NMS                     7 ms
ROS publish             6 ms
Controller interface    4 ms
------------------------------
Total                   60 ms

Now the same pipeline after several weeks of TensorRT work:

Camera DMA               8 ms
Image decode             4 ms
Color conversion         3 ms
Memory copies            5 ms
Resize & normalize       5 ms
Inference                16 ms
NMS                      7 ms
ROS publish              6 ms
Controller interface     4 ms
--------------------------------------------
Total                    58 ms

Two milliseconds saved, on a pipeline that’s still burning over 40ms on everything that isn’t the model. Most of the engineering hours went into the smallest slice of the problem.

Why often teams still ignore it?

It’s not carelessness - it’s tooling. TensorRT ships with profilers. CUDA has timelines. Every framework spits out an inference number, and every paper leads with one. The rest of the pipeline is scattered across drivers, middleware, the OS scheduler, and hardware interfaces that were never built to be measured together. Getting an honest end-to-end number means stitching timestamps across four or five layers of the stack by hand, and almost nobody does that work.

So teams optimize what they can see. It’s a completely rational response to bad visibility - it’s just optimizing the wrong thing.

- Memory copies are where a lot of latency hides.

One of the least glamorous parts of a perception pipeline is how many times an image gets copied before the GPU ever sees it:

Every hop costs time and bandwidth, and none of it improves the prediction by a single percentage point. I’ve seen teams cut more latency by removing one unnecessary copy than by dropping from FP32 to FP16 - and that fix never shows up in a conference talk, because there’s no leaderboard for “deleted a memcpy.”

- Cameras aren’t really instant.

“Camera latency” gets treated as basically zero, which is wrong. Sensor exposure, readout, DMA transfer, driver buffering, synchronization - all of that happens before a single pixel reaches software. If exposure alone costs 10ms, no amount of TensorRT tuning gets those milliseconds back. You can’t infer on pixels that haven’t arrived yet.

Preprocessing eats time too - resizing, RGB conversion, normalization, undistortion, stereo rectification. None of it touches the model, all of it happens before the model runs, and on a lot of setups the GPU actually finishes inference before the CPU has fed it the next frame. Utilization looks low and everyone blames the model, when the model’s been sitting idle waiting on preprocessing the whole time.

- Middleware and the scheduler take a major cut.

Most robotics stacks aren’t one process - messages get serialized, copied, queued, deserialized, and rescheduled as they move through ROS or DDS. Each hop is a few milliseconds. Six here, four there, a context switch somewhere else, and the robot is reacting 30ms later than the raw compute numbers would suggest. No amount of model optimization touches any of that.

The OS scheduler adds its own tax. Perception finishes a frame, but the controller doesn’t necessarily run next - logging might be flushing, a background thread might wake up, a network interrupt might steal a few cycles. Average latency barely moves, but worst-case latency can blow out badly. And for a physical robot, worst case usually matters more than average: a car that responds in 20ms most of the time but occasionally stalls for 80ms is more dangerous than one that’s a steady, boring 40ms every time. Determinism beats raw speed.

Even after perception is done, the command still has to pass through safety checks, interface layers, the CAN bus, motor controllers, and firmware before anything physically moves. The robot is always acting on slightly stale information - the only question is how stale.

How should one approach benchmarking?

Instead of asking “how fast is our model?”, the better question to ask us is “how old is the information by the time the actuator receives it?”

That single number - call it perception-to-action latency - captures camera time, preprocessing, inference, middleware, scheduling, planning, and control all at once. It’s what the robot actually experiences. The robot has no idea whether 20ms disappeared inside TensorRT or inside a memcpy; it only knows when the command arrived.

The most useful exercise I’ve found is building a real waterfall chart per frame:

Camera Exposure        ██
DMA                    ███
Decode                 ██
Color Conversion       █
Memory Copies          ██
Preprocessing          ██
Inference              ███████
Post-processing        ███
ROS/DDS                ██
Planning               ███
Controller             ██

Once you actually look at the full bar, it’s obvious where the effort should go. Sometimes it really is the model. More often, it isn’t.

TensorRT is genuinely excellent engineering - but its own visibility has created a blind spot. Because inference is the easiest thing to profile, it becomes the thing everyone obsesses over, while camera pipelines, memory movement, scheduling, and controller interfaces quietly eat the rest of the budget with nobody watching.

The fastest robots don’t come from the teams with the fastest models. They come from the teams that’ve bothered to account for every millisecond between the sensor and the actuator.

The industry likes to imagine itself as a cathedral of sophisticated software. Conference talks are full of transformer architectures, diffusion policies, world models, RL, CUDA kernels, trillion-parameter ambitions. The demos look futuristic, and investors nod along to slides full of arrows connecting GPUs to robots. Behind all of it, though, sits the actual mission-critical dependency: a spreadsheet nobody wants to admit exists. Not version controlled. No clear owner. Half the formulas quietly broken. And somehow it’s the only place that maps dataset names to robot IDs to calibration sessions to bag files to eval results to customer demos - plus whatever “run_237_final” was supposed to mean. Delete the training code and someone rebuilds it from Git history by tomorrow afternoon. Delete that spreadsheet and the company loses three months of institutional memory.

Every robotics startup starts with the same beautiful principles. Clean pipelines. Reproducibility. Metadata first. Automation over manual work. Then the first customer demo shows up on the calendar, and someone exports a CSV in a hurry. Someone else copies it into Excel “just temporarily.” A few cells get colored green for no reason anyone could explain later. A new tab appears. A manager duplicates the file because they’re scared of overwriting the original, and now there are two versions. A week later, seven. A month later, twenty-three, living in a folder called Data Organization, which itself contains Data Organization Final, Data Organization Final 2, Data Organization Final New, Data Organization Final Latest, and - inevitably - Data Organization Final Latest Updated Copy. Nobody knows which one production actually depends on. Everyone acts like they do.

Robotics companies like to say they’re building autonomous systems, and technically, they are - the spreadsheets got there first. Nobody remembers creating them. Nobody fully understands how they work anymore. Everyone is a little afraid to touch them, because changing one hidden column somehow breaks the eval dashboard three layers away. At some point the spreadsheet stopped being a tool and started having agency of its own.

If you’ve spent any real time in robotics, you’ve sat through a version of this exchange: Where did this dataset come from? I think Rahul collected it. No, Rahul says it was Ankit. Ankit left last year. What robot was it? I think Robot 5. There were two Robot 5s. Was this before or after the camera recalibration? Nobody investigates further. Someone just renames the file Robot5_NEW_FIXED and the meeting moves on.

We joke that machine learning models are black boxes. The data pipeline is usually darker. Ask a robotics company about its transformer and you’ll get eight attention heads, flash attention, rotary embeddings, mixed precision, gradient checkpointing - a beautifully specific answer. Ask where a particular demonstration came from and you get silence, followed eventually by “I think it’s in Dropbox somewhere.”

Version control is its own subplot. Software engineers have Git. Data engineers have object stores, more or less. Robotics engineers mostly have hope. Two people editing the same spreadsheet at once effectively forks reality - both versions keep existing, neither gets deleted, and months later someone discovers the production model was trained on the wrong branch of Microsoft Excel.

Calibration deserves its own paragraph of shame. Every team insists calibration is automated, by which they usually mean a guy named Akash knows how to do it. If Akash goes on vacation, the robots briefly become philosophical objects instead of physical ones, and people gather around a whiteboard trying to remember whether the LiDAR transform lives in YAML, JSON, or “that spreadsheet.” Someone eventually finds Calibration_v8_REAL_FINAL_USE_THIS.xlsx, and nobody asks the obvious question about why camera extrinsics live in Excel. Everyone just accepts it and moves on.

Evaluation follows the same script. A dashboard proudly reports Success Rate: 94.7%. Compared to what, exactly? Nobody’s quite sure - the baseline model got overwritten at some point, the validation split has drifted, a few “outlier” scenarios got quietly dropped because they made the number look worse, and someone renamed three metrics last quarter because the old names were confusing. The graph goes up regardless. Everyone celebrates scientific progress.

The most expensive meetings in robotics aren’t architecture reviews - they’re archaeology expeditions. Ten engineers trying to answer questions that should take thirty seconds: which dataset produced this model, which controller was active, was this before or after the encoder swap, did we retrain after the sync fix, why are there three folders called “Production,” who created “Production New,” and why is “Production Old” somehow the newest one of all. Nobody writes a line of code in these meetings. Everyone just digs.

People tend to underestimate what this actually costs. GPU bills show up as invoices. Cloud storage shows up as invoices. Salaries show up on payroll. Spreadsheet chaos shows up nowhere on any statement, and yet it quietly eats weeks - duplicate experiments, repeated data collection, wrong conclusions drawn with total confidence, customer demos run on outdated models, failed reproductions, entire investigations launched because a CSV column shifted by one index six months ago. It never appears on the balance sheet. It just invoices you slowly, in engineering time.

There’s a real irony in a team spending three weeks shaving 12 milliseconds off inference latency and then losing two full days because nobody can say for certain which demo corresponds to kitchen_pickup_good_new_latest_fixed2. Optimization is addictive because benchmarks reward it publicly. Organization stays invisible because nobody has ever tweeted about a metadata schema.

This might be part of why robotics feels slower than software in general. Software engineers mostly debug code. Robotics engineers debug reality - sensors, actuators, physics, synchronization, calibration, networking, human operators, damaged hardware, mislabeled data, missing timestamps, and yes, spreadsheets pretending to be databases. Every missing piece compounds with the others, until the hardest problem in the building isn’t intelligence at all. It’s just remembering what happened last Tuesday.

There’s a familiar stage every robotics startup hits eventually, where the spreadsheet has become so load-bearing that nobody dares touch it. People start discussing a proper data platform. Roadmaps get written. Infrastructure proposals get approved in a planning meeting somewhere. Six months later, a new column shows up in Excel anyway, because it was faster for now. Temporary systems, it turns out, have remarkable survival instincts.

The industry loves to argue about whether scaling laws, RL, synthetic data, or foundation models are what finally unlocks general-purpose robots. Those debates matter. But they also distract from a less glamorous truth: most robotics companies aren’t actually limited by intelligence. They’re limited by memory - not GPU memory, organizational memory. The plain ability to answer simple questions with confidence. Where did this data come from. What changed. Why did performance regress. Can we even reproduce this result. Until those have reliable answers, every new model gets built on ground that’s a little less solid than anyone’s admitting.

So next time someone tells you their stack runs on CUDA, PyTorch, ROS, and diffusion policies - smile, because it probably does. Just know that somewhere underneath all of it sits a file named final_v3_latest_FIXED_USE_THIS_ONE(3).xlsx. Nobody owns it. Nobody trusts it. Nobody can delete it. And somehow, it’s still the highest-impact engineer at the company.

We were guilty of this at Minus Zero too, until late we started making it more reliable.

Till then, share and subscribe for more anecdotes while building in physical AI space.

Ask a senior engineer at Waymo, Tesla, or any Physical AI startup how they actually spend their time. The answer never matches the conference talks.

Control algorithms, perception architectures, planning systems - these are what get written about, presented, and funded. They’re maybe 15–20% of where engineering hours actually go. The rest disappears into data collection, labeling pipelines, dataset versioning, calibration tracking, validation scripts, evaluation infrastructure, and debugging corruptions that produce no error messages whatsoever.

Nobody talks about this at NeurIPS. It’s not glamorous. But it’s where the work is.

How complicated it can be?

To appreciate the hidden complexity, follow a single camera frame from capture to its eventual use in a training run six months later.

If you already know this, feel free to skip to the next section : )

═════════════════════════════
PHYSICAL LAYER
═════════════════════════════
1.  Image sensor captures photons (1/30 second exposure)
2.  Image Signal Processor: demosaicing, white balance, noise reduction
3.  Hardware timestamp generated by camera's internal oscillator
    ⚠ NOTE: This clock is NOT the system clock. It drifts 1–5ppm.
4.  Frame transmitted over GigE Vision to compute unit
5.  OS receives frame, applies software timestamp
    ⚠ NOTE: This is a SECOND timestamp. The two will diverge.
6.  DMA copy into shared memory ring buffer

MIDDLEWARE LAYER
═════════════════════════════
7.  ROS 2 node reads frame, wraps in sensor_msgs/Image
8.  Publishes to /camera/front_left/image_raw (~1MB per frame)
9.  Subscribers: perception node, recorder node, visualization node
10. Three independent subscribers receive the same message.
    ⚠ Each applies processing with unknown latency jitter.

RECORDING LAYER
══════════════════════════════
11. Recorder serializes to MCAP format with LZ4 compression
12. Writes to local NVMe in 30-second segments
13. Session metadata: robot_id, session_id, operator, timestamp range
14. Segment complete → MD5 checksum computed on in-memory buffer
    ⚠ NOTE: If the NVMe has a bad sector, the write is "successful"
    but the data is corrupted. The checksum passes.
15. Segment pushed to upload queue

SENSOR FUSION ASSOCIATION
═════════════════════════════
16. LiDAR arriving at 10Hz (different oscillator, different clock)
17. IMU at 200Hz (yet another clock)
18. GPS at 10Hz (UTC-synchronized via PPS signal — most accurate)
19. To fuse: what was the robot's pose at this exact camera timestamp?
    ⚠ Requires sub-10ms alignment. Uncompensated drift → wrong geometry.
20. Calibration lookup: where is this camera relative to LiDAR?
    ⚠ Is the calibration from this session? Or last week's? Did it drift?
    ⚠ Calibration changes with temperature. No one tracked today's temp.

UPLOAD AND INGEST
═════════════════════════════
21. Upload to object storage via chunked multipart upload
22. Upload job written to message queue (Kafka / SQS)
23. Ingest service parses MCAP, extracts metadata
24. Frame indexed: timestamp_ns, robot_id, session_id,
    scenario_type, GPS_bbox, weather_tag, calibration_id
    ⚠ NOTE: "weather_tag" was added to the schema in month 4.
    ⚠ All frames before month 4 have NULL weather_tag.
    ⚠ Training code does not handle NULL. Silent filter removes 40%
    ⚠ of your data and you don't notice.

VALIDATION PIPELINE
═════════════════════════════
25. Timestamp monotonicity check             [PASS]
26. Frame drop detection (>1% gap rate)      [PASS]
27. Calibration validity check               [FAIL — 3 frames]
    ⚠ Clock stutter caused those 3 frames to fall outside
    ⚠ the calibration validity window. Flagged for review.
28. Brightness range check                   [PASS]
29. Compression integrity check              [PASS — does not catch
    ⚠ bad-sector corruption, because checksum was wrong]

LABELING
═════════════════════════════
30. Frame sampled for annotation (diversity heuristics)
31. Sent to annotation pipeline: objects, lanes, drivable area
32. Human annotation: ~8 minutes per frame
33. QA review by senior annotator
34. Labels written to database with annotator_id, QA_status
35. Labels joined to frame via (robot_id, timestamp_ns)
    ⚠ NOTE: Labeling team changed in month 6.
    ⚠ New team uses slightly different bounding box convention.
    ⚠ Mixed conventions now exist in the training set.

DATASET VERSIONING
═════════════════════════════
36. Frame added to dataset v3.7.2 manifest
37. Train/val/test split assigned
    ⚠ Split is by session_id, not frame. Mostly prevents leakage.
    ⚠ But the robot drove the same route twice in different sessions.
    ⚠ Similar frames appear in both train and test.
38. Dataset committed to DVC remote with git hash

TRAINING
═════════════════════════════
39. Training job: 64 A100s, dataset v3.7.2
40. Frame decoded, augmented, normalized
41. Forward pass. Gradient. Weight update.
    ⚠ The bad-sector-corrupted frame was included.
    ⚠ So were the frames with wrong bounding box convention.
    ⚠ So were the test-set-leaked frames.
    ⚠ The model trains successfully.

EVALUATION AND REGRESSION
═════════════════════════════
42. mAP computed per class, per condition
43. Regression detected: pedestrian mAP dropped 2.3% in construction zones
44. Root cause hunt: Is it the model? The data? A labeling issue?
    ⚠ Debugging this takes 3 engineer-weeks.
    ⚠ The answer: bad-sector corruption + mixed bounding box convention
    ⚠ + 40% data loss from NULL weather_tag filter.
    ⚠ None of these produced a single error message.

SIX MONTHS LATER
═════════════════════════════
45. Engineer queries data lake for construction zone, night, rain frames
46. Returns 8,000 results
47. 340 have corrupted calibration (calibration service bug in month 2)
48. 200 have labels from deprecated tool with different class definitions
49. Engineer spends 3 days reconstructing which frames are usable
50. Eventual usable frames: ~7,460 of 8,000 — but which 7,460?
    ⚠ No provenance trail. Must re-validate manually.
═════════════════════════════
TOTAL TIME FROM CAPTURE TO USABLE TRAINING EXAMPLE: 6 months.
TOTAL ENGINEERING-DAYS LOST TO DATA ISSUES: ~20.
TOTAL ERROR MESSAGES PRODUCED BY ANY OF THESE ISSUES: 0.
═════════════════════════════

This isn’t a pathological story. This is Tuesday at a typical robotics startup.

So what poses as a problem?

These are the data problems that don’t produce stack traces. They produce models that fail in production in ways that take months to diagnose.

• Timestamp Drift - Camera hardware oscillators drift by 1–5 parts per million. After a 4-hour collection session, a sensor running at 2ppm drift is 29ms off from the system clock. During sensor fusion, your perception stack associates a LiDAR point cloud (captured at time T) with a camera frame (nominally at T, actually at T+29ms). At highway speeds (30 m/s), 29ms represents 87 centimeters of vehicle motion. You are training your model with a point cloud that doesn’t correspond to the image it thinks it does. This doesn’t crash anything. It silently corrupts your 3D bounding box training data, slightly but persistently - across every hour of data collected with that sensor.

• Schema Drift - You add a field to your custom protobuf message definition. You’re careful: it’s an optional field, backward compatible. But your MCAP recording tool hashes the message schema to identify the message type. Old bags reference the old hash. Your replay tool, written for the new schema, can’t find the message definition for the old hash. Three months of bags are now unreadable without a migration script. The migration script takes two weeks to write and test properly. During those two weeks, you discover that 4% of your bags also have a related issue with the companion metadata schema.

• Silent Disk Corruption - A frame is written to disk. The NVMe drive has a developing bad sector. The OS reports the write as successful. The checksum was computed on the in-memory buffer before the write. The corrupted frame sits on disk, looking exactly like a valid image, producing subtle artifacts that a labeler annotates as object detections. You’ve injected structured noise into your training set.

• Benchmark Leakage - Your evaluation set is sampled from the same routes as your training set, just at different timestamps. A rare sign type appears in both training and evaluation because you drove past it every morning during data collection. Your per-class mAP on that sign type looks excellent. Your production system fails at a different intersection with the same sign type, because it memorized the specific instance rather than the class.

• Calibration Drift - Camera intrinsics shift with temperature. LiDAR-camera extrinsic calibration can change after a minor collision that leaves no visible damage. If calibration is recorded once weekly, every datum collected between calibration sessions is tagged with potentially incorrect geometry. Models trained on this data learn the wrong spatial relationships - consistently, invisibly.

• Label Inconsistency - Labeling vendor A annotates occluded pedestrians with a partially_visible flag. Labeling vendor B, hired when the first vendor couldn’t scale, annotates only fully visible pedestrians. You merge their outputs without reconciling the conventions. Your model now receives the same visual stimulus with different ground truth depending on which batch the frame came from. You’ve permanently injected irreducible label noise.

• Duplicate Data - A recorder bug causes 2% of sessions to be written twice under different session IDs. Your training set contains tens of thousands of effectively duplicated frames. The model overfits to these examples. Evaluation performance looks inflated - the test set also contains duplicates. The effect is invisible until you deploy to a new environment and the model catastrophically fails on distributions it’s never actually generalized to.

  None of these produce error messages. They produce models with mysterious behavior, regressions that can’t be explained, and debugging sessions that last months.

Physical AI is in its Pre-Git Era

Consider where software engineering was in 1990. Code on network drives. No version history. “Works on my machine” was an acceptable bug report. Reproducing a build meant manually reconstructing the environment. Merging two developers’ work meant emailing patches.

That’s where robotics data is today.

Datasets live on shared NFS mounts without versioning. There’s no history of which data produced which model. Training runs aren’t reproducible because no one tracked which files were actually used. “The model trained on my workstation” is common. Merging two teams’ datasets means copying files and hoping for no conflicts.

The ML world partially solved this for static image data. Weights & Biases tracks experiments. DVC versions datasets. Hugging Face hosts models. But these tools were built for static datasets of labeled images or tabular rows. They don’t understand time-synchronized multi-modal sensor streams, calibration dependencies, coordinate frame transforms, or the need to replay a scenario to debug a failure. They’re the right shape of solution applied to the wrong problem structure.

Robotics needs purpose-built tooling. Not a reskin of MLflow. Something designed around what embodied physical data actually is.

MCAP - developed by Foxglove, now the default format in ROS 2 - is a good start: self-contained, corruption-resistant, schema-embedded, multi-language. But MCAP solves the storage format. It doesn’t solve versioning, provenance, calibration tracking, scenario search, or continuous evaluation. We have one good brick. The building doesn’t exist yet.

Why Foundation Models Make This Worse?

There’s a seductive belief that as models scale and become more capable, messy data becomes less of a problem - the model will figure it out. This is exactly backwards.

Physical Intelligence’s π0 is trained on data from seven different robot hardware platforms, across eight task types, mixed with internet-scale vision-language pretraining. The hard work isn’t the architecture - π0 builds on existing VLM foundations. The hard work is making data coherent across robot morphologies with different action spaces, different observation definitions, and different physical constraints. That is not a modeling problem. It is a data harmonization problem that precedes any modeling work.

Waymo’s recent scaling law research puts a sharper point on it. Their finding: for autonomous driving tasks, unlike language models, optimal systems tend to be “relatively smaller in size, while requiring significantly more data to train.” More data is the path to better systems - which means more data collection, more data operations, and more quality control, not less.

Scaling model capacity without scaling data infrastructure doesn’t plateau gracefully. It fails in ways that look like training instability, unexplained regressions, or evaluation results that don’t transfer to production. The root cause is usually in the data. The debugging path is usually weeks long.

What the Leaders Actually Built?

Tesla’s data engine - described by Andrej Karpathy at multiple public presentations - is the clearest public acknowledgment that data infrastructure, not model architecture, is the core competitive advantage in autonomous systems.

Trigger classifiers run on the production fleet, detecting situations where the current model and a candidate model diverge, or where the model’s output conflicts with the driver’s behavior. Those triggers route specific clips for annotation and retraining. New models run silently on production vehicles in “shadow mode” - outputs compared against the production model, never actually controlling the car. This is a continuous evaluation system running at fleet scale across millions of vehicles. At AI Day 2022, Tesla described datasets on the order of 1.5 petabytes for training their occupancy network alone.

None of that is model architecture. All of it is data infrastructure.

Waymo maintains 500,000+ hours of driving data. New software release candidates are automatically evaluated against millions of simulated miles. Their simulation system generates scenarios from real-world logs - which requires log management, scenario indexing, and closed-loop evaluation infrastructure of considerable sophistication. Dedicated teams work on sensor simulation, scenario search, and evaluation tooling. Not just perception and planning.

Karpathy, at a CVPR workshop, made it plain: “The only sure certain way I have seen of making progress on any task is, you curate the dataset that is clean and varied and you grow it and you pay the labeling cost.”

The algorithm is almost secondary. The machine that creates and validates training data is the real product. The robotics organizations that have achieved meaningful scale haven’t done it primarily through algorithmic novelty. They’ve done it by building industrial-grade data operations.

So how does it affect a typical robotics startup trajectory?

• Months 1–3: The robot moves. The demo works. The team is energized.

• Months 4–6: A model trains. It works in the lab. Investors are interested.

• Months 7–9: Real-world deployment. Performance degrades. Debug manually. Fix cases individually.

• Months 10–12: Retrain the model with new data. Performance is worse than before. The team doesn’t know why.

• Months 13–18: A senior engineer joins. She discovers: no dataset versioning, no reproducible training, evaluation set contaminated with training data, calibration not tracked, labeling conventions inconsistent across vendors. Six months of reconstruction work begins.

The reason founders underestimate data operations is that early success doesn’t require them. Two engineers can build a demo that impresses investors with zero data infrastructure. The failure modes only surface when you need to reproduce a training run, when a calibration change corrupts months of data you didn’t know was invalid, or when your evaluation set has silently leaked into your training set and you’ve been measuring the wrong thing for half a year.

The first dedicated data infrastructure engineer - someone who designs the schema before you have data, builds the validation pipeline before you have regressions, creates the reproducible evaluation framework before you establish a baseline - often has more total leverage than the third ML researcher. The ML researcher improves the current model. The infrastructure engineer makes all future models improvable faster. The second is harder to justify to a board. It’s more important.

But if we do X then it’s not a problem?

“Simulation solves the data problem.”

Simulation reduces the need for some real-world data collection. It doesn’t eliminate the data problem - it adds a parallel one. Simulation asset management requires versioning. Domain randomization parameters require tracking. Sim-to-real gap requires characterization against real-world benchmarks. Synthetic data generation pipelines fail in ways that look exactly like real data pipeline failures: schema drift, coverage gaps, distribution mismatch, evaluation leakage. Waymo runs millions of simulated miles per software release candidate. That infrastructure - scenario management, parameter tracking, results storage, regression detection - is a data operations problem of comparable complexity to the real-data problem.

“Foundation models trained on internet data will generalize to robotics.”

Internet-scale pretraining provides genuine value for visual recognition and language grounding. It doesn’t help with calibration tracking, multi-modal timestamp synchronization, or the physical geometry of sensor fusion. The “last mile” of embodied AI - grounding general knowledge in precise physical sensor data - requires exactly the infrastructure this article describes. Physical Intelligence’s π0, which makes aggressive use of VLM pretraining, still required building a multi-robot data collection and harmonization infrastructure as the core technical work.

“This is just MLOps with extra steps.”

MLOps tools were designed for static datasets. Robotics data is time-synchronized, calibration-dependent, multi-modal, spatially grounded, and replay-dependent. Applying MLflow to manage a dataset that includes MCAP files with associated per-session calibration metadata, LiDAR-camera extrinsics, GPS trajectories, and scenario tags reveals immediately that the abstractions don’t transfer. The tooling gap is real and purpose-built solutions are needed.

“Big companies have this problem. Startups should focus on shipping product.”

This is precisely backwards. Big companies can absorb three months of debugging a data corruption issue. Startups cannot. The startup that establishes data discipline in months 1–3 compounds its learning rate for the entire subsequent trajectory. The one that defers it will spend months 12–18 in reconstruction mode while competitors iterate. Early investment in data infrastructure is not a distraction from building the product - it is the infrastructure on which the product’s learning rate depends.

“Better sensors and hardware will reduce calibration and sync problems.”

Better hardware reduces but doesn’t eliminate calibration drift. More importantly, tracking calibration state over time - associating every data frame with the calibration that was valid at that moment, flagging data when calibration may have changed, managing calibration as a versioned artifact - is not a sensor problem. It’s a data management problem. Even perfect sensors require a calibration management system.

How should we solve it?

DevOps emerged when shipping code without operational discipline stopped scaling. MLOps emerged when deploying models without infrastructure discipline stopped scaling. RobotOps is next - and the path is legible.

It all starts with changing how we approach a robotics problem - and try giving a serious thought through the ‘DevOps for Robotics’ perspective.

Standardize before you tool up. MCAP is a good start, but the next step is a robotics dataset format analogous to Parquet - purpose-built for time-synchronized multi-modal sensor data, with versioning and calibration baked in. The community needs to converge on this before every company keeps reinventing it privately. At the team level, this means defining canonical sensor schemas, a timestamp policy (hardware timestamps only, sync mechanism documented), calibration tracking (every file references a calibration session ID with a validity window), and a session metadata standard - written down before you have data. Two weeks of work that saves six months.

Build the platform layer, not five duct-taped tools. Early entrants - Foxglove, Rerun, Scale AI, HuggingFace via LeRobot - are solving pieces of the puzzle. The gap is integration: schema management, calibration tracking, dataset lineage, and scenario search in one coherent platform.

Treat data like code: validate, checksum, test. Every model commit should automatically validate datasets, check timestamp and calibration integrity, run scenario regression benchmarks, and compare against historical results - the same discipline software teams built into CI/CD two decades ago. In practice, this starts small: checksum every recorded file in-memory before upload and verify after (one engineering-day, catches silent corruption before it reaches training), and run a validation script before every training job - timestamp monotonicity, frame drop rate, calibration validity, label schema compliance, duplicate detection. Fail loudly, automatically.

Make scenario search the primary interface. Manual log inspection should be as archaic as grepping server logs. The target: query petabyte-scale sensor archives the way you’d query a database - by scenario type, condition, failure mode, time window. The scenario library becomes more valuable than any individual model checkpoint. Build your evaluation set first as part of this discipline: sample deliberately, freeze it, version it, never train on it, and store every result against it with model version, dataset version, and timestamp.

Formalize the discipline and hire for it. Robot Data Engineer needs to be a real job title with a real career path, not a responsibility absorbed by whoever has bandwidth. Counterintuitively, the first data infrastructure hire often has more leverage than the third ML engineer - and is the recommendation most consistently ignored despite having the highest ROI.

A better model architecture can be published and reproduced in six months. A decade of well-organized operational data cannot.

References and Resources

^{Foundational Papers}

• ^{Open X-Embodiment Collaboration (2024). Open X-Embodiment: Robotic Learning Datasets and RT-X Models.ICRA 2024. https://robotics-transformer-x.github.io/}

• ^{Black et al. (Physical Intelligence, 2024). π0: A Vision-Language-Action Flow Model for General Robot Control.https://physicalintelligence.company/download/pi0.pdf}

• ^{Brohan et al. (Google, 2022). RT-1: Robotics Transformer for Real-World Control at Scale. arXiv:2212.06817}

• ^{Chi et al. (TRI / Columbia, 2023). Diffusion Policy: Visuomotor Policy Learning via Action Diffusion.arXiv:2303.04137}

• ^{Sun et al. (Waymo, 2020). Scalability in Perception for Autonomous Driving: Waymo Open Dataset. CVPR 2020.}

• ^{Waymo (2026). Scaling Laws Research: Data-Driven Autonomous Driving.https://datacenterdynamics.com/en/news/waymo-research-confirms-self-driving-scaling-laws/}

^{Engineering Blogs and Talks}

• ^{Karpathy, A. (Tesla Autonomy Day, 2019). Tesla Data Engine.}

• ^{Karpathy, A. (Tesla AI Day, 2021). Autopilot and Auto-Labeling.}

• ^{Karpathy, A. (CVPR 2021 Workshop on Autonomous Driving). Lessons learned from deploying neural networks at Tesla.}

• ^{Waymo Engineering. Industry Best Practices in Robotics Software Engineering. arXiv:2212.04877}

• ^{Foxglove Blog. Introducing the MCAP File Format. https://foxglove.dev/blog/introducing-the-mcap-file-format}

• ^{Rerun Blog. Introducing Experimental MCAP Support. https://rerun.io/blog/introducing-experimental-support-for-mcap-file-format}

• ^{Segments.ai. MCAP vs ROS bag: Simplifying Multi-Modal Sensor Data. https://segments.ai/blog/mcap-vs-ros-bag-simplifying-multi-modal-sensor-data-in-robotics/}

^{Community and Discussion}

• ^{ROS Discourse: https://discourse.ros.org/ (Active community discussions on data management, MCAP, and tooling evolution)}

• ^{Papers With Code — Robot Learning: https://paperswithcode.com/task/robot-learning}

• ^{ScenarioNet (open-source scenario management): arXiv:2306.12241}

_{Technical claims in this article about engineering time allocation represent informed analysis based on public statements from industry engineers, published engineering blogs, and the author’s experience in Physical AI development. Where specific figures are cited (e.g., Waymo’s 500,000 hours of driving data, Tesla’s 1.5PB dataset scale), sources are linked above. Claims presented as analysis are clearly identified as such.}

_{The argument that data infrastructure determines competitive outcomes in Physical AI is not a prediction about the future. It is an observation about the present, backed by every major organization that has achieved meaningful scale in autonomous systems.}

Manu Joseph is India’s sharpest literary wit. This, his first non-fiction, contains some of the most pitiless sentences written about Indian society in recent memory. Which is precisely why it disappoints - not the way bad books do, but the way a brilliant man does when you realize his brilliance has an escape hatch.

The question is genuinely radical: why, in one of the most grotesquely unequal societies on earth, do the poor not revolt? Why don’t the maids who squat beside kitchen sinks pull out the hair of their conscientious madams? Joseph has the nerve to say out loud what every South Delhi living room has silently asked and immediately suppressed. That nerve deserves credit.

But the book answers the wrong version of its own question.

Joseph’s real project, once you strip away the dark comedy, is sociological reassurance. He is explaining - to a reader who is very much us and not them - why we are safe. The “so far” he appends to that conclusion is doing enormous moral work for two words. It gestures at threat without committing to alarm. The drawing room reader finishes the book feeling they’ve engaged with something dangerous, while having been fundamentally comforted.

The most dangerous books about inequality make their readers feel implicated. This one makes them feel curious. Not the same thing.

His sharpest observation - that the poor don’t envy the rich, they envy each other - is genuinely brilliant and genuinely chilling. Envy between equals, not across distances. Which means the system isn’t maintained by force or ideology but by the architecture of aspiration itself. The poor are too busy competing laterally to organize vertically. Joseph notices this, turns it over, admires it, and sets it back down. He never follows it to where it leads: that this architecture was not accidental.

The grenade stays unpinned.

His contempt for professional humanitarians has attracted predictable criticism from predictable quarters. Wrong target. The more honest critique is that Joseph lampoons activists because it’s safe - even fashionable - in the circles where this book will be celebrated. It’s far riskier, and far more interesting, to ask whether the system he describes so acidly has any exit. He doesn’t go there. He has decided there isn’t one. This gets presented as intellectual honesty. It functions as intellectual comfort.

Diagnosing a problem you don’t believe can be solved isn’t courage. It’s resignation in a very good suit.

At its core, Why the Poor Don’t Kill Us is a book by a privileged man, for privileged readers, about why they should stop feeling guilty without stopping feeling intelligent. The poor don’t kill us, Joseph concludes, for reasons of psychology, aspiration, and the peculiar human capacity to find meaning in suffering. He’s probably right. What he never asks is whether the peace is just, or merely convenient.

He understands it brilliantly. He is not disturbed by it. And by the last page, neither are you.

That’s the problem.

Read it. Then read it again and notice what it didn’t make you feel.

That's odd when you think about it. Sales takes years to get good at. Fundraising means learning the customs of an industry built almost entirely on signaling. Saying no requires two letters and the willingness to use them. It should be the easy one. Instead it's the one almost everyone gets wrong, because everything about the early days of a startup is engineered to push you toward yes.

Think about the position you're in when you're starting out. You have no revenue, no users, no proof that any of this works, so anything that looks like traction starts to look like the thing that saves you. A customer wants a one-off feature. A would-be partner wants an integration you never planned to build. An investor wants a board seat in exchange for a check you need. None of these requests arrive looking like a trap. They arrive looking like progress, because in the moment, saying no feels like turning down the only offer on the table. I have been through that myself.

There's a sneakier version of this too. We tend to believe, correctly, that the job requires being relentlessly resourceful - find a way, don't make excuses, figure it out. The trouble is this turns every no into something that feels like a personal failure. A real founder would have found a way to make it work, I would tell myself. So I would say yes to the thing I shouldn't, not because I evaluated it and it passed, but because saying no felt like admitting I wasn’t resourceful enough. That was a weird fight with own self.

This gets the whole thing backwards. The scarce resource in an early company was never opportunity. There's no shortage of people who want something from you once you exist at all. The scarce resource is attention - yours, specifically, and your team's. You get maybe a year of genuinely focused effort before reality forces some kind of reckoning, whether that's the market, your runway, or your own capacity to keep going. Every yes draws down that account. A founder who says yes to everything isn't being resourceful. He's spending down the one thing he can't get back, a little at a time, without noticing.

And that's the real problem with a bad yes - we don't notice. Say yes to a customer's custom request and nothing bad happens that afternoon. The bill comes due eight months later, when our product has quietly absorbed eleven of these favours, none of which add up to anything, and the actual thing you started the company to build is still half-finished because you've spent the year keeping people happy instead. Compare that to a bad no, which stings immediately - a customer is annoyed today, a deal falls through today. We underprice bad yeses because the pain is invisible and deferred, while the pain of a no is loud and immediate. We might end up optimising against the wrong signal.

If today I had to bet on which predicts a company's future better - the quality of its yeses or the quality of its noes - I'd take the noes. Almost any founder with enough determination can scrape together sufficient good yeses to survive a couple of years. Far fewer can resist the steady current of plausible opportunities that would, if accepted, quietly turn the company into something else: a services shop instead of a product, a pile of features instead of a platform.

What makes this genuinely hard, and not just a matter of willpower, is that yes and no aren't the symmetric risks they feel like in the moment. A yes feels reversible. It usually isn't. Once you've shipped the custom integration, hired around the manager who doesn't fit, or brought on the investor whose incentives don't match yours, unwinding it costs far more than the no would have. A no feels final. It usually isn't. Most people you turn down respect you more for it afterward than you'd expect, and the door tends to stay open longer than it seems like it should, because conviction is rare enough that people remember who had it.

The founders who are actually good at this aren't more stubborn than everyone else. They're more precise, because they've done the work of knowing exactly what they're protecting. A no with no reason behind it is just avoidance, and it folds the moment someone pushes back hard enough. A no that comes from "this isn't what we're building" holds up, because it was never really a judgment on the thing being declined - it's a judgment about what the company is for. Which is the uncomfortable part: you can't say no well until you already know, with some precision, what you're trying to build. Founders who are fuzzy on that get talked into things constantly, because they have no fixed point to push back from.

The other thing the good noes share is timing. They come early. Founders who think they're avoiding the yes-to-everything trap often aren't - they're just saying "let's see" or "send over more details" instead, which is a no dressed up as a yes, and it costs you the one advantage a clean no actually has. Every day a decision sits open is a day the case for yes gets to keep making itself in your head, unopposed, and a day the other person spends planning around an answer you haven't actually given them.

The hardest noes, though, aren't the ones aimed outward. Outward noes have cover - "not on our roadmap" ends most conversations without anyone having to feel anything. The hard ones are internal: the team's pet project that isn't working, the cofounder relationship that's quietly gone wrong, the version of the company you originally pitched that the market has stopped agreeing with. There's no one to blame those noes on. You just have to want the right thing more than you want to avoid an uncomfortable conversation, and most people, founders very much included, will eat a lot of slow invisible cost to dodge one moment of visible discomfort.

So if there's a usable test in all this, it's a small one: before you say yes to something, picture saying no to that same person's face, out loud, with your actual reason attached. If the only honest reason you can give for the yes is that it seemed easier than the conversation you were avoiding, that's usually the moment to have it instead.

The data isn’t there. The market’s half-formed. The competitors have more money, more people, more runway. You’re running on conviction and a pitch deck that has more assumptions than facts.

And yet you proceed. That’s not courage, exactly. It’s something closer to selective blindness - a refusal to fully register the odds. This sounds like a character flaw until you realise it’s basically the job.

Here’s something that doesn’t get said enough: most founders are, at the start, at least a little delusional. They believe their timing is right when the evidence is ambiguous. They believe talent will show up when they can barely make payroll. They believe the market will come around - they just need a bit more time.

If you ran these beliefs through a Bayesian update, you’d walk away. Most startups fail. Most new technologies underperform projections. Most timelines slip by years, not months. The base rates are bad.

Founders override the base rates. That’s not a bug.

That mild delusion does something useful: it compresses fear enough that you actually move. It makes people want to join you, because no one rallies around a probability curve - they rally around someone who genuinely believes. It gives you the emotional insulation to operate in conditions where external validation simply doesn’t exist yet.

You can’t build a non-consensus company on consensus confidence.

But here’s where it gets complicated.

The same trait that gets you started can slowly become the thing that kills you. Optimism - the useful kind - says “this is hard but solvable.” At some point, without you noticing, it can shift into something else: “reality will eventually agree with me.”

That’s a different thing entirely.

When that shift happens, poor signals get explained away. No traction becomes “market education lag.” Investor hesitation becomes “they don’t get it yet.” A product that doesn’t fit becomes a positioning problem. Every warning light gets re-labelled as temporary noise.

In the early days, that kind of persistence looks like vision. Later, it starts to look like denial. The founder who wouldn’t quit too early also won’t pivot when they should.

The frustrating thing is that you can’t always tell which one you’re watching - in real time, from inside it.

Plenty of companies looked completely delusional before they weren’t. Investors passed. Customers didn’t buy. Smart people said the model was broken. And then something shifted, and it worked. So founders reasonably conclude: this is just what the in-between period feels like.

Sometimes it is. Sometimes it isn’t.

That ambiguity is structural. It doesn’t resolve cleanly. And that’s why delusional optimism is simultaneously the fuel of breakthrough and the camouflage of a slow failure.

The founders who seem to navigate this best aren’t the ones who eliminate the delusion. They’re the ones who compartmentalise it.

They hold two things at once: deep emotional conviction about where they’re going, and genuine intellectual scepticism about how they’re getting there. The destination is fixed. The path is always under review.

They run pre-mortems. They invite people to poke holes. They watch the metrics honestly, even when the metrics are uncomfortable. They’ve figured out how to separate their identity from the product - so that changing direction doesn’t feel like admitting they were wrong about everything.

The belief energises the company. The belief does not dictate the roadmap.

There’s no clean resolution here. That’s the honest answer.

Without some degree of irrational conviction, most founders would never start. With too much of it, unchecked, they run long past the point of compounding - burning capital and time on a thesis that stopped being true some time ago.

You need enough optimism to attempt the improbable. You need enough honesty with yourself to notice when improbable has quietly become impossible.

The goal isn’t to kill the delusion. The goal is to aim it carefully - and keep one part of your brain that refuses to be convinced by your own story.

That second voice is harder to maintain than the belief. But it might be more important.

I have a contrarian take on it which I felt like sharing today. It might be a bit long read, so I hope you would bear with me.

The nihilist penguin isn’t sad. It might look tired. That distinction matters.

Depression is inward. It collapses agency. It drains energy.

The nihilist penguin, by contrast, is still standing. Still functioning. Still observant. It hasn’t withdrawn from the world - it has simply stopped pretending the world is something it isn’t.

We’ve grown used to diagnosing realism as pathology.

In a culture that insists everything must be meaningful, purposeful, and “aligned,” the refusal to perform enthusiasm is treated as a problem to fix. If you’re not visibly hopeful, you must be burnt out. If you’re not chasing a narrative, something must be wrong.

But sometimes nothing is wrong. It’s that the illusion just wore off.

Modern life runs on compulsory optimism.

Jobs need “mission”, brands need “purpose” and work needs “passion.” Even suffering needs a lesson.

This constant demand to feel something about everything creates a subtle distortion: neutrality begins to look like failure. Calm becomes indifference. Acceptance gets misread as disengagement.

The nihilist penguin is what happens when someone stops over-interpreting their own experience.

It’s not that life feels empty. It’s that life feels normal. Random. Occasionally interesting. Frequently mundane. Mostly indifferent to your internal storyline.

That’s not depression. That’s statistical honesty.

Nihilist penguin is not really nihilist. Nihilism is a collapse in perceived agency. The sense that nothing you do matters and therefore nothing is worth doing.

Realism is quieter. It says: “Things matter less than I was told - but some things still matter enough.”

The nihilist penguin hasn’t given up on action. It has given up on exaggeration. It no longer needs work to be transformative. Or growth to be exponential. Or life to feel profound every day.

It shows up without demanding that effort justify itself emotionally. That’s not emptiness. That’s efficiency.

But why is the internet pathologizing the penguin?

We pathologize realism because it doesn’t market well.

A person who doesn’t need meaning is hard to motivate with slogans. A person who accepts randomness can’t be easily sold certainty. A person who doesn’t romanticize outcomes is difficult to manipulate.

So we label them unmotivated. Detached. Or let’s say cynical.

But cynicism still cares. It’s disappointed idealism.

The nihilist penguin is past that phase. It’s not angry that the world doesn’t make sense. It just stopped asking it to.

Here’s the part people miss: the nihilist penguin still acts.

It still works. Builds. Commits. Creates. Just without the internal monologue narrating its significance.

It doesn’t need hope to function. It doesn’t need belief to begin. It doesn’t need meaning to endure repetition. That makes it unusually durable.

Most burnout doesn’t come from effort. It comes from carrying emotional weight that the work never promised to return. The penguin dropped that weight.

The penguin cares selectively. It cares about what it can influence. It disengages from what it can’t. It doesn’t confuse intensity with importance.

This is why the nihilist penguin resonates now.

After years of inflated narratives - careers that were supposed to fulfill, startups that were supposed to define identity, work that was supposed to love us back- realism feels like relief.

That’s the quiet truth the nihilist penguin embodies. Not everything needs meaning. It’s just done pretending that the world owes it significance.

And paradoxically, that’s what allows it to keep going - calmly, consistently, without collapse.

So how does all of that really make it a good founder?

Working for someone requires belief. Building on your own requires tolerance.

Most people trades in conviction. They need to believe - publicly, repeatedly, and loudly - that something matters. It could be a product, a lifestyle, a framework or simply a version of the future.

Founders don’t get that luxury. Founders operate in environments where belief is optional but tolerance is mandatory. Tolerance for ambiguity. For boredom. For long stretches where effort produces no visible signal.

The nihilist penguin isn’t motivated by belief. It’s motivated by acceptance. That’s an advantage for building.

You Don’t Perform Motivation

Most people to survive must look motivated. Founders must remain functional.

The nihilist penguin doesn’t wake up energized by vision statements. It doesn’t romanticize outcomes or narrate progress. It doesn’t confuse motion with meaning.

It shows up because showing up is required. That makes it unmarketable. There’s nothing inspirational about “this might not work, but I’ll do it anyway.”

But that sentence describes most real progress.

Belief Is Fragile. Acceptance Is Durable.

Belief needs reinforcement. When results lag, belief erodes. That’s why many founders burn out right after the first illusion breaks - PMF takes longer than promised, growth stalls, capital tightens.

The nihilist penguin starts after the illusion breaks. It doesn’t need the work to justify itself emotionally. It doesn’t need constant affirmation that this matters in some cosmic sense.

It just needs the work to be necessary. That’s a much more stable foundation.

You need to build without hope.

Hope is a powerful motivator - and a dangerous one. Hope attaches effort to expectation. When outcomes disappoint, effort collapses with it.

The nihilist penguin separates the two. It works without expecting meaning. It persists without promising reward. It builds without assuming the world will care.

This looks bleak from the outside. From the inside, it’s liberating.

You don’t need to be right.

Normal people must sound right. Founders must become less wrong.

The nihilist penguin isn’t attached to being correct, admired, or early. It’s willing to iterate quietly, discard ideas without drama, and change direction without identity loss.

That’s hard to do if your self-worth is public. It’s easier if you don’t think the universe is keeping score.

The nihilist penguin won’t inspire you. It won’t sell you a framework, promise outcomes or perform certainty.

What it will do is keep going when the story collapses. And that’s the rarest skill in building anything real.

It’s a long journey ahead.

We grind for months, ship relentlessly, talk to users, tweak pricing, rework onboarding - and one day it clicks. Retention stabilizes, revenue grows and investors nod approvingly. There’s a moment as a founder we feel that we achieved product-market fit and move on to “scaling.”

This framing is convenient., but it’s also wrong. Product–market fit is not a moment you reach. It’s a position you occupy - and can lose.

PMF is a temporary advantage, not a permanent state . The real truth is that markets don’t stand still. Customers will change. Competitors will copy. Distribution can shift. What worked six months ago can quietly decay.

If product-market fit were permanent, incumbents would never lose. But history is full of companies that once had obvious fit- and later couldn’t explain why growth slowed. That is never a sudden failure, but it was a gradual erosion.

It can start from as small as tiny frictions ignored, new use cases underserved, a pricing model that stopped matching customer reality or a competitor that understood one narrow segment better.

- The First Version of PMF Is Narrow by Default

Early PMF almost always exists in a thin slice of the market.

• A specific customer type

• A specific use case

• A specific urgency level

Founders often miss this mistake early traction for general demand. They raise money assuming the fit is broad. Then they hire sales, expand marketing, and widen positioning - before understanding why the first users cared so much.

The result is dilution. The product still works. But it works intensely for fewer people.

Defending PMF starts with knowing exactly where it lives.

- Retention Is the Only Honest Signal

Founders over-index on growth metrics because they’re visible and flattering. But PMF actually shows up elsewhere:

• Users come back without reminders

• Usage increases without new features

• Customers complain when things break.

If retention weakens, it signals that PMF is weakening too - even if revenue might still growing. Growth can be bought with marketing, capital, purchase incentives, but retention has to be earned repeatedly.

Teams that treat retention metrics as lagging indicators miss the point.

- Scaling Is the Fastest Way to Lose PMF

Most companies lose PMF after they think they’ve found it.

Why? Because scaling changes the product even if you don’t touch the code.

• Sales promises stretch beyond delivery expectations.

• Support quality drops.

• Onboarding becomes generic and lack of attention to nuanced customer pain points.

• Roadmaps optimize for revenue, not value

Each change seems reasonable in isolation. Together, they move the product away from the original fit. Defending PMF requires saying no to customers who look attractive on paper but don’t reinforce the core use case.

This is uncomfortable- especially when revenue targets are involved.

- PMF Is Maintained Through Feedback, Not Vision

Founders like to believe their job is to “hold the vision.” In practice, defending PMF is actual operational job:

• Talking to users even when metrics look good

• Watching how edge cases behave

• Noticing when power users leave quietly

• Shipping small fixes instead of big bets

Vision helps you start and keep the momentum. Feedback helps you actually deliver. Teams that stop listening because they believe they’ve “figured it out” usually haven’t.

- Competition Exposes Weak PMF First

When competition appears, founders often blame marketing, pricing, or capital.

Yes, sometimes that’s true. But often it’s not. Competitors never steal customers randomly. They take the ones whose fit was already marginal.

If switching feels easy for a customer, it’s a direct signal that PMF was never strong. The right response isn’t aggressive positioning, but rather tightening the loop with the customers who still care deeply.

- PMF Is Defended by Focus, Not Speed

The instinct when growth slows is to do more. The first step that comes in the mind to add more features, more segments and more experiments.

But PMF is defended by doing less better.

• Fewer ICP’s (Ideal Customer Profiles)

• Clearer positioning

• Stronger defaults

• Faster response to core users

Speed helps discovery, but focus preserves fit.

How do I find whether we have a defensive PMF?

You don’t know you have PMF when things are going well. Sometimes it’s important to test things in a contrarian way to check whether you are on track.

You know it when:

• You raise prices and users stay

• You pause marketing and usage continues

• You ship nothing new and retention holds

PMF is not excitement, but resilience. And resilience has to be maintained. Product–market fit isn’t a trophy that we win as a startup.

It’s a posture a founder has to maintain - by paying attention longer than feels necessary, by resisting premature expansion, and by treating alignment as ongoing work. The companies that last aren’t the ones that find PMF. They’re the ones that keep defending it while everyone else assumes it’s already secured.

Till then, keep building.

We like stories that end well. They feel instructive.

Good endings don’t prove good logic. Most of the time, they just prove luck, timing, access, or the ability to stay alive longer than others.

When someone succeeds, we ask, “What did you do?”

We don’t ask, “Who else did the same thing and still lost?”

That’s the first distortion.

We listen to the winners and pretend their stories explain the whole game. They don’t. They only explain how the survivors survived.

Two people take the same risk. One would make it, and the other one might vanish.

We talk to the one who made it—and call that wisdom.

Advice is usually autobiography pretending to be theory.

Most success stories are edited. The chaos is removed, accidents become “insight,” lucky breaks become “strategy,” and dead ends are quietly erased.

And finally marketing does the final polish. The mind of survivors converts a messy chain of events into clean steps, rephrase randomness as some principles, and what can’t really be repeated we call an insight.

The winner like this version because it now sounds plausible.

And you on other hand don’t buy advice because it’s true. You also buy it because it feels manageable. Advice softens uncertainty. It promises a map of steps, on following which you should get there.

But the real world doesn’t care about instructions. It rewards where you stand, when you move, and how much chaos you can live with.

That’s why most people who follow great advice still don’t get great outcomes. Not because they failed, but because the advice was never universal.

The uncomfortable truth:

Most advice is reverse-engineered justification.

We don’t really know why things worked; we only know that they worked, so we build stories that make the result feel intentional. We accept those stories because randomness is terrifying.

If success were mostly skill, advice would work more often. If it were mostly structure, advice would look more like sociology than self-help. But success is neither clean nor kind. It’s a mix of ability, access, timing, and survival.

Advice only sees the survivors. That’s why it sounds confident, why it sells well, and why it fails quietly.

The real skill is not following advice. It’s knowing which parts of someone else’s story don’t apply to your world. Most people don’t want that skill. They want a script—and survivor bias with good marketing is the best-selling script of all.

I noticed it first in a small, uncomfortable way.

I would draft something - a note, a post, a memo - and feel that familiar friction. The thought wasn’t fully formed yet. The language was uneven. It needed time.

Then I’d run it through ChatGPT. The result was cleaner. Calmer. More confident. And somehow, less mine.

But I still posted it. No one complained. In fact, it performed better.

That’s when it became clear: the trade wasn’t intelligence for laziness. It was rough truth for smooth sense-making.

And once that trade becomes normal, the rest follows quietly.

The popular fear about AI and narratives is dramatic - that machines will invent propaganda. I feel that’s likely wrong.

If AI ever takes control of the narrative, it won’t be because it overpowered humans. It will be because humans voluntarily outsourced storytelling to it - enthusiastically and at scale.

Not through conspiracy. But through convenience.

Today, AI models are trained on human-generated data. But it’s difficult to deny the fact that eventually they will get exposed in training on AI-assisted human expression - if not with AI-generated content.

That distinction matters.

Every post you see that even was:

• polished with an AI

• summarized by an AI

• optimized for reach by an AI

is no longer a clean human signal. It’s a feedback loop artifact.

We aren’t just publishing content anymore. We’re publishing content that already passed through a machine’s priors.

And most content distribution platform don’t filter that out. They reward it, which means the training data of the future is increasingly self-referential.

Why this may happen easily (and quietly)?

This doesn’t require a breakthrough in AI capability, but three very ordinary incentives to align -

Efficiency beats originality

Original thought is slow, risky, and cognitively expensive. AI-assisted creation is fast, legible, and socially safe.

Over time, the recommendation algorithms on LinkedIn, Instagram, etc. naturally selects for:

• clean structure

• familiar metaphors

• predictable moral arcs

• confident but moderate tone

AI excels at exactly this shape of communication. Not because it’s “manipulative” - but because it optimizes for acceptability.

Platforms amplify the median, not the edge

Most social media and platforms don’t promote what is true or novel. They promote what is least frictional.

AI-generated (or AI-assisted) content converges toward:

• consensus language

• polite disagreement

• balanced takes

• non-threatening insights

As humans learn what “works,” they unconsciously mimic that style - even when writing without AI. And the result is narrative compression.

Training data doesn’t care about authorship

A model training methodology doesn't ask if this thought was earned. It asks instead whether this pattern repeats.

When AI-shaped content floods the corpus, the model doesn’t see it as derivative. It sees it as ground truth frequency. At scale, repetition becomes authority.

AI doesn’t need to control narratives. It only needs to average them. And averages feel neutral - even when they’re not.

The danger isn’t a biased AI shouting ideology. It’s an AI calmly reinforcing what already survives visibility filters.

That’s far harder to notice. And far harder to resist.

What worldview does AI inherit?

Not a radical one. A comfortable one.

I will find it concerning if on these grounds AI inherits worldview that is:

• Technocratically optimistic

• Economically centrist

• Morally polite

• Risk-averse

• Language-heavy, action-light

• Confident in systems, vague about power

This is not left or right. It’s platform liberalism - shaped by engagement incentives, moderation rules, and professional class norms.

Not revolutionary. Not reactionary. Just smooth. And smooth narratives travel far.

The biggest shift won’t be belief manipulation. It will be narrative narrowing. And humans will increasingly rely on these explanations - because they feel reasonable.

Over time:

• raw experience gets filtered

• strong claims get softened

• moral ambiguity gets resolved too quickly

Not because AI is evil. But because clarity scales better than truth.

As as this becomes a bigger portion of the machine priors, it will become more and more difficult for people to prompt the models to tame and think otherwise.

We worry about AI hallucinating. But the more dangerous outcome is AI remembering us incorrectly.

Not as we were - conflicted, unfinished, inconsistent - but as we presented ourselves for algorithms - which would be the most polished, balanced, optimized and harmless manner.

If AI inherits the narrative of our time, it won’t be the story of human struggle. It will be the story of what survived posting.

An interesting paradox is …

The worldview of an AI models depends on distribution in the data corpus. But the decision-makers decide to control what the models learn - one can argue it will still depend on the worldview of the person choosing what goes in distribution. How do you really understanding the morality of that bias?

So it may not really be objective function. You may be able to objectively remove AI-generated content, but AI-assisted content is hard to distinguish.

And interesting thought: will it make more sense to optimize the training so that an every individual is sustainibly able to train his own co-pilot which is hardwired away from every increasing digital corpus and internet.

If you still write without assistance, you are already an outlier.

If you write something sharp, unfinished, or uncomfortable - you’re providing rare data. Not for engagement, but for the future memory of how humans actually thought.

Because the next generation of intelligence won’t just learn from what we believed.

It will learn from what we were willing to publish.

On paper, the week looked solid. Investor calls. Team reviews and townhall. Customer sync. Strategy meetings and discussing PoA’s. No gaps. No red flags. But when Friday arrived, I realized I hadn’t spent a single uninterrupted hour on the thing the company actually exists to build.

Everything important had been discussed. Almost nothing important had been done.

That’s when I realized: my calendar no longer reflected my values- it reflected my obligations.

I realized all founders like to believe they control their time. In practice, the calendar fills itself.

A quick sync. A follow-up. A meeting to align on the last meeting. A misalignment that needs attention. A quick meeting turns into a weekly ritual.

None of it feels wrong. That’s why it accumulates. You stop asking, “Is this aligned?” and start asking, “How do I fit this in?”

At some point, the calendar stops reflecting what you’re building and starts reflecting what you’re maintaining.

Decisions deferred, conversations repeated, energy spent explaining the same thing in different rooms. Deep work gets postponed to “later.”

Thinking happens at night, tired and compressed.

The calendar is full. The days feel thin.

It shows up as:

• Low-grade irritation without a clear source

• Workdays that feel dense but unsatisfying

• A sense of always “catching up” to your own thinking

• Progress that looks good externally but feels thin internally

You don’t feel lost. You feel misplaced.

What changes is posture. You move from creating to responding. From shaping the work to servicing it.

Responsibility slowly turns into availability. Availability is a costly value to hold by default.

Not building. Not thinking. Not creating.

Just keeping things from breaking.

The calendar becomes a record of what your obligations instead.

Because the calendar doesn’t judge. It doesn’t moralize.

It simply records. Meeting after meeting.

Context switching disguised as collaboration.

What makes this hard is that none of the entries look wrong in isolation.

Each meeting sounds reasonable. Each call has a purpose. Each commitment once felt necessary.

But values aren’t reflected in individual blocks. They’re reflected in patterns.

• The work you claim is “important” keeps getting postponed.

• The thinking you say you value happens only late at night, exhausted.

• The people you care about are fit into leftover slots.

• The work that energizes you appears rarely - like a guest, not a resident.

Values show up not in your loudest declarations, but in what survives your busiest weeks.

None of this happens maliciously. It happens gradually. One reasonable “yes” at a time.

A calendar aligned with your values has a different texture.

It starts with being deliberate about what you say yes to.

Every founder has a trust bottleneck somewhere in the system - holding on only makes it worse.

Delegate what others or systems can do. Reduce decision fatigue where judgment isn’t required.

There is space. There is intention. There are fewer explanations.

Not because you care less- but because you’ve decided where your care belongs.

You don’t attend everything. You don’t respond immediately. You let some things wait so other things can exist at all.

This isn’t neglect. It’s stewardship.

What I realized over last few years is that the calendar will take whatever you give it.

Because in the end, your calendar isn’t a scheduling tool.

It’s a record of what you chose to protect

when no one was forcing you to choose.

I’m writing this without an agenda.

No resolutions to announce.

No tidy arc that pretends the year made sense.

Just a pause - long enough to look myself in the eye.

Last year taught me that progress rarely arrives the way ambition imagines it. It comes disguised as friction. As repetition. As discomfort you don’t get applause for.

I spent a lot of time building things that won’t show up in screenshots. Foundations instead of facades. Systems instead of stories. Conversations that didn’t trend, decisions that didn’t feel heroic, days that looked boring from the outside but mattered quietly on the inside.

I learned that clarity is expensive. It costs ego. It costs speed. Sometimes it costs being misunderstood for longer than feels fair.

But confusion is more expensive.

I also learned that effort doesn’t always compound immediately. Some work sits dormant, like seeds underground, testing your patience before it rewards your faith. This year asked me to keep showing up without proof. To trust that invisible progress is still progress.

There were moments I mistook exhaustion for failure. Moments I thought something was wrong because things felt heavy. They weren’t. I was just carrying weight that actually mattered.

I’m beginning to understand the difference.

Not everything needs to scale. Not everything needs to be optimized.

Some things need to be protected.

• My attention.

• My standards.

• My curiosity.

I read less than I wanted and learned more than I expected. Mostly about myself. About how easily the mind reaches for noise when silence asks better questions. About how often certainty is just fear wearing confidence.

I noticed how the best insights arrived sideways - during walks, half-finished books, late-night notes that weren’t meant for publishing. The work behind the work. The thinking behind the thinking.

This year reminded me that identity is a process, not a declaration. That becoming is quieter than announcing. That integrity is built in private, long before it’s tested in public.

I don’t want a life that looks impressive but feels misaligned.

I want one that feels honest, even when it’s inconvenient.

So here’s what I’m carrying forward in 2026:

• Less urgency, more intent

• Fewer explanations, clearer decisions

• Fewer inputs, deeper work

• Fewer performances, more presence

And here’s what I’m leaving behind:

• The need to prove momentum

• The habit of over-intellectualizing discomfort

• The belief that rest must be earned

Next year doesn’t need a reinvention. It needs continuity. It needs me to keep doing the unglamorous things well. To stay curious longer than comfortable. To choose long arcs over short applause.

If I read this a year from now, I hope I recognize the person who wrote it- not because everything worked out, but because I stayed honest while it didn’t.

That feels like a good enough ambition.

Until next year.

- Gagandeep

The premise is simple: people communicate differently, and most conflict comes from assuming theirs is universal. As he categorizes people into four color profiles, you realise Erikson’s four colors aren’t psychology. They’re a shortcut - a rough map of how people process speed, emotion, harmony, and detail.

What stayed with me wasn’t the model. It was the discomfort.

I noticed how often I mistake urgency for clarity.

How I assume precision is helpful when it’s just overwhelming.

How frustration usually appears when I expect others to operate on my defaults.

The book works best when used lightly. It’s not about labeling people. The moment you start doing that, you miss the point. The value is in the pause it creates - maybe they’re not difficult, maybe they’re different.

It also revealed something less flattering: how rarely I adapt. How often I expect others to meet me where I am instead of translating.

The title, in hindsight, is a trap.

It invites superiority - but rewards humility.

Read it not to explain people, but to soften your certainty.

Most misunderstandings aren’t personal.

They’re linguistic.

That realization alone made the book worth reading.

Used without it, it becomes exactly what it warns against.

The most valuable insight isn’t about others. It’s about yourself.

You notice:

• How often you assume clarity when you’re just being familiar

• How rarely you adapt your communication style, even when outcomes suffer

• How much conflict is sustained by ego rather than misunderstanding

In that sense, the title turns inward. The “idiot” is often the part of us that refuses to translate.

Every year pretends to be important. But some years don’t just pass - they invalidate assumptions.

2025 was one of those years.

Not because of a single crisis or breakthrough, but because many comfortable stories we relied on - about markets, wars, startups, India’s “rise”, AI, careers, pedigree, and global order - quietly stopped working.

The dashboards looked fine. The lived experience didn’t.

And that gap became impossible to ignore.

Markets stopped explaining themselves

One of the strangest contradictions of 2025 was this: markets appeared calm, yet people felt constantly on edge.

Volatility existed, but it was episodic. Corrections were shallow and quickly bought. Indexes recovered faster than narratives could catch up. On paper, capital markets looked rational.

But something fundamental had shifted. Markets stopped being explanatory.

Prices moved ahead of earnings. Liquidity mattered more than fundamentals. Short-term positioning overwhelmed long-term conviction. The “why” behind price action mattered less than knowing who else might buy next.

Retail investors oscillated between fear and FOMO. Professionals learned to trade narratives instead of businesses. Long-term investing quietly turned into tactical survival.

This seeped into everything else - careers, startups, even life planning.

The uncomfortable truth:

2025 markets didn’t reward insight. They rewarded positioning. And positioning, by definition, is unstable.

Conflict as an infrastructure, instead of event

By 2025, war lost its shock value.

Conflicts no longer erupted and resolved cleanly. They simmered, paused, fragmented, resumed - without conclusion. The world adapted not because it became safer, but because instability became familiar.

Energy markets absorbed shocks. Supply chains rerouted. Defense budgets normalized. Headlines moved on.

This normalization was the real change.

War stopped being an event and became infrastructure - a persistent input into energy prices, migration, capital flows, industrial policy, and technology access.

Modern wars weren’t fought for resolution.

They were fought for leverage. And once leverage is established, it rarely gets relinquished.

This mattered because it fed directly into markets, geopolitics, and long-term uncertainty - especially for countries and companies trying to plan beyond the next quarter.

“Fundamentals” didn’t save startups anymore

The neat post-mortem of 2025 goes like this:

“The market rewarded founders who focused on fundamentals.”

That story is comforting — and incomplete.

What actually happened was harsher:

Founders with leverage survived. Everyone else learned the language of fundamentals too late.

• Distribution beat differentiation.

• Access beat elegance.

• Timing beat discipline.

Companies with average products but entrenched enterprise contracts survived. Technically superior startups with weak go-to-market quietly shut down.

Fundamentals mattered - but only after survival was secured.

The real lesson:

Being right without power is still losing.

Is there really an AI Bubble? (Not where you think)

The bubble in 2025 wasn’t “AI is useless or it is overhyped.” AI worked — that was the problem. Contrarian, but true.

While capital became costlier in 2025, it is being artificially discounted for AI opportunities. I met lot of notable institutions who just want exposure to AI, it doesn’t matter what it is or whether it will generate any value.

The bubble showed up elsewhere:

• Too many AI wrappers chasing the same workflows

• Identical demos differentiated by branding, not outcomes

• Revenue lagging far behind inference costs

• Talent costs rising faster than margins

• Imbalance of expenditure and intellectual saturation across domains.

The ecosystem chose the winners very early - optimized on signals rather than substance. And consequently is trying to keep the cycle running on a belief system.

Capital recycled aggressively:

model company → cloud bill → infrastructure provider → back into AI funds.

Money moved in loops, not lines.

Uncomfortable truth:

In 2025, much of AI investment didn’t create new value.

It circulated value.

An identity crisis disguised as innovation for Indian deep tech ecosystem

India entered 2025 loudly declaring:

“We’re done cloning. Deep tech is the future.”

That statement sounded confident.

It wasn’t entirely true.

Yes, consumer internet cooled. Yes, more startups attempted EV infra, AI, robotics, climate, and industrial software. But many ran into the same structural wall.

We realized while India wants to be ambitious as global hedge against China, but there is still a large gap in talent, mindset, patience and alignment.

• Founders still find it easier—and often rational—to build in India and sell outside it. Not because they want to leave, but because outcomes are clearer elsewhere, and execution is faster.

• Top-tier talent remains magnetized by the US. What returns in the name of “reverse brain drain” is usually the median, not the edge.

• High-risk domestic capital is limited. It prefers exposure through the US–India corridor rather than committing fully within India. Safety, not conviction, shapes most decisions.

• Foreign capital remains hesitant. That’s the ground reality—regardless of how optimistic the narrative sounds. India excites investors, but rarely enough to absorb long cycles, regulatory ambiguity, or deep technical risk.

• Workforce optimizes for stability over stretch. Comfort over uncertainty. That’s understandable—but it changes what kinds of companies can exist.

• Customers are still final friction point, creating lack of early adopters due to pricing, bureaucracy and reluctance towards risk.

Deep tech thrives only when these incentives align. In India, they still didn’t keep up as per expectations.

Most “deep tech” startups struggled not because the tech failed — but because cash flow timelines and cultural expectations were incompatible. Those who survived were mostly based in Bay Area - not building for India as market, but rather using India as a cost center for economical development rather than decision making.

Uncomfortable truth:

Deep tech in India isn’t impossible - but without a mindset shift from momentum and optics to mastery and endurance, it remains largely performative.

The Indian economy appeared to be growing, yet quietly fucked up

2025 was full of headlines celebrating India’s macro strength.

They weren’t wrong - just misleading.

GDP growth didn’t translate into wage growth. Asset prices outran incomes. Consumption leaned on credit rather than confidence.

Millions weren’t unemployed. They were employed, educated, and anxious.

This wasn’t an economic collapse. It was an incentive collapse.

Too many aspirants chased too few genuinely high-quality opportunities. Growth existed, but it didn’t feel predictable, inclusive, or secure.

Hard truth:

Growth without productivity-linked income doesn’t create optimism.

It creates fragility.

The collapse of the illusion of employment

The employment stress of 2025 didn’t come from sudden cruelty. It came from correction after excess.

For several years, capital was cheap and growth was cosmetic. Companies expanded headcount to signal momentum, not because work demanded it. Compensation drifted away from contribution. Hiring optimized for surface signals rather than sustained output.

Work felt lighter. Expectations softened. Salary jumps and job switches felt frictionless - driven by optical signals like pedigree instead of proof of work.

That phase trained a workforce on conditions that were never durable.

As markets tightened, the logic reversed.

Companies recoiled back to efficiency. Roles had to justify contribution. Output replaced optics. Rewards grew conditional.

This created a paradox:

• Employers struggled to find people who met rising expectations and merits

• Workers struggled to find roles that matched old assumptions - and felt a feeling of being undervalued.

Not because capability vanished - but because the reference point was wrong.

AI accelerated this shift by lifting baseline productivity — it didn’t cause it, despite the popular narrative.

Uncomfortable Truth:

The hardest adjustment wasn’t technical. It was mental.

A generation calibrated its expectations in an abnormal environment. When conditions normalized, the mismatch felt personal.

Optional awareness around geopolitics became a liability

Until recently, geopolitics was background noise for most professionals. 2025 ended that illusion.

• Export controls affected hardware startups.

• Visa regimes reshaped hiring.

• Capital came with political assumptions.

• Neutrality itself carried cost.

The world didn’t become hostile. It became conditional.

Reality check:

Globalization didn’t reverse — it fragmented.

And ignorance stopped being neutral.

Reflections going forward in 2026

2026 doesn’t need optimism and narratives, but rather repositioning how we make decisions, choose depth over chasing speed and build right incentives for evolutions.

The next decade won’t be exponential. It will be selective.

Last few years have normalized instability. 2026 won’t reward certainty.

It will reward those who can move without it. It will reward right positioning, rather than insight or ambition.

And in a world where the old stories no longer work, that may be the only real advantage left.

Happy New Year!

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.

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.

It began quietly - not with a resolution, but with a restlessness.

The kind that makes you reach for books without knowing what you’re looking for.

I thought I was reading stories, but maybe the stories were reading me.

I stepped into Marjan Kamali’s The Stationery Shop of Tehran the way you step into a memory that doesn’t belong to you.

The scent of paper, the hum of a distant city, the trembling hope of young lovers - Roya and Bahman - meeting in a bookshop that holds the world still for them.

When the revolution tears them apart, what remains is not tragedy, but time refusing to explain itself.

I underlined a line I still remember:

“Love is not about what happens. It’s about what doesn’t.”

That sentence followed me for months.

It whispered that the stories that matter most are the ones we never finish telling.

During mid-2025, I found a fancy for translations of some popular Japanese fiction -

Days at the Morisaki Bookshop and its sequel. Satoshi Yagisawa’s world is built from silence and sunlight. The story doesn’t rush; it lingers like steam rising from a cup.

If Tehran was love interrupted, Morisaki was love unhurried. It reminded me that sometimes reading is not escape — it’s recovery.

You return to yourself sentence by sentence.

I also read the first part of the very popular set this year - Before the Coffee Gets Cold — another Tokyo story, where time travel happens in a small café if you’re brave enough to face your past.

But the rule is cruelly poetic: you can go back, but nothing you change will alter the present. The only thing that changes is you.

The year 2024 and early 2025 had be tough for my startup (and me personally in general.) At some point, the books on my table shifted from hearts and time to markets and struggle.

I picked up few books that had been on my list long due. And having had decently progressed in my evolution as a founder, I always have been on look-out for something that ushers new insights - rather than being a manual for beginners.

I picked up Zero to One by Peter Thiel because it’s too popular to be in ‘unread’ list. While a lot in it wasn’t new, it read like a provocation - a reminder of why I had started up in the first place. I would recommend it as a good starter for anyone before they start up.

I recall few nice things:

Creation is almost always lonely.

that every moment in business happens only once;

the next Mark Zuckerberg won’t build a social network,

the next Larry Page won’t build a search engine.

Underneath the contrarian tone, the larger idea I would revisit again for any one starting up -

“You don’t get to hide behind templates.”

Don’t follow them as a playbook.

Then there was Ben Horowitz’s The Hard Thing About Hard Things - truth written in scar tissue. No philosophy - it shoots point-blank.

This was the book I really needed to read and it has surpassed everything to top positions in my non fiction reads. And I know I will keep coming back to it again and again.

He doesn’t glamorize building. He describes the 3 a.m. anxiety, the impossible decisions, the weight of knowing that sometimes there are no good options - only less catastrophic ones.

“There are no silver bullets, only lead bullets.”

It wasn’t just about companies. It was about life.

No perfect hacks, no clean exits. Just showing up, again and again, firing one imperfect shot at reality after another, hoping, somehow, to move things an inch forward.

I think I would want to take out time to write about this book in more detail sometime.

These two books together drew a rough sketch of ambition:

the dream of creating something that didn’t exist, and the quiet brutality of surviving what that dream demands.

As a founder and an adult navigating relationships and friendships - dealing with people turned out to be far more complex than I had imagined.

Thomas Erikson’s Surrounded by Idiots arrived like a translation manual for human nature. On the surface, it’s a framework — colors and categories — but beneath that is an invitation to humility.

I learned that understanding people is not about decoding them, but about de-centering yourself.

That we are all, at some point, someone else’s “idiot.”

And that empathy begins the moment you stop demanding that others make sense to you.

If Zero to One and The Hard Thing about Hard Things asked what we build in the world, The Silent Patient asked what we build inside our heads (though it’s fiction). Alex Michaelides’ novel comes dressed as a psychological thriller: Alicia Berenson, a painter, murders her husband and then goes completely silent. Theo, a psychotherapist, is determined to make her speak.

But as the story unravels, you realise the real investigation isn’t just about Alicia.

It’s about him. And, uncomfortably, about you.

I underlined a thought about how we tell ourselves stories to live with what we’ve done - and how sometimes those stories are more dangerous than the truths they hide.

Silence, in this book, isn’t emptiness. It’s everything the reader suspects but doesn’t want to face.

It’s the recognition that we all maintain carefully edited narratives about who we are. And sooner or later, those narratives come to collect their debt.

When I turned to The Almanack of Naval Ravikant, the language shifted again — from narrative to distilled thought.

Naval doesn’t add complexity. He strips it away.

Wealth, happiness, freedom — he treats them less as goals and more as side effects of understanding yourself clearly and wanting less from the world.

Then came Gulzar’s Selected Poems — words so gentle they barely touched the page.

He doesn’t explain life; he hums it. His verses are like open windows — what enters is not meaning, but air.

And in between these two, I met Morrie. Tuesdays with Morrie is a small book with a very slow heartbeat. On the surface, it’s simple. In reality, it’s a quiet dismantling of everything we mistake for a life.

Morrie doesn’t insist you chase greatness. He insists you pay attention - to love, to presence, to the tiny, unglamorous rituals of care.

If Naval questions your desires and Gulzar tenderises your feelings,

Morrie does something subtler: He asks whether the ladder you’re climbing is even leaning against a wall you care about.

There were two very light reads I swept through - Deepinder Goyal’s Culture - an internal memo they followed at Zomato, given to every employee, and Ritwik’s I don’t don’t love you anymore - which gave me vibes like Rupi Kaur’s work. The latter is nice for mass appeal in college kids, but don’t expect much if you are a literary nerd like me.

By the end of the year, I realized: I hadn’t been reading for answers.

I’d been reading for echoes.

Each book — Tehran, Tokyo, the therapist’s office, the startup war room — had been a mirror of different parts of my mind.

And what I underlined wasn’t just lines. It was reminders:

• That silence is not emptiness.

• That leadership is not loudness.

• That love, once begun, never really ends — it only changes form.

• That people are puzzles, not problems.

• That meaning is not found; it’s assembled, piece by piece, from what we notice.

Books are not an escape. They don’t take us elsewhere. They bring us closer - to the person waiting this side - the one we had lost in touch with.

Recently there was lot of things going on in startup and my personal life, and I craved for something light on my reader’s palate. I ended up picking The Almanack of Naval Ravikant. And for a particular state of mind — its writing style ends up being exactly what you need — it doesn’t tell you what to do, rather it just refreshed the way you think.

This time, I read it through the lens of a founder rather than a to-be founder. Some lines hit differently when you’re in the middle of building something uncertain, burning through time, money, and sanity.

These are the lessons that stayed with me — not as quotes, but as reminders I wanted to keep returning to.

Owning Your Name

“Clear accountability is important. Without accountability, you don’t have incentives. Without accountability, you can’t build credibility. But you take risks. You risk failure. You risk humiliation. You risk failure under your own names.

The people who have the ability to fail in public under their own names actually gain a lot of power.”

There’s something deeply humbling about being a founder — you’re visible in every direction. Every action is a public experiment.

It’s terrifying at first. But Naval’s point is liberating: accountability is leverage. And it’s not just for founders but even applicable to every employee we hire.

When you put your name behind what you build, you create a loop of trust - and your incentives align in right proportions in either ways. It increases the reliance in the pillars of the organization - that’s what keeps people together to build great companies.

And if you do fail?

“People will forgive failures as long as you were honest and made a high-integrity effort.”

The world doesn’t punish honesty as much as we think it does. It just punishes pretense. Integrity compounds faster than growth metrics. It doesn’t show up on dashboards, but it’s the foundation every long game is built on.

Leverage

“One form of leverage is labor — I would argue this is the worst form of leverage that you could possibly use. Managing other people is incredibly messy.”

That line should be tattooed on every founder’s wrist. We learn it the hard way. More people doesn’t mean more progress — it often just means more meetings.

We think building a big team is success. It often isn’t — it’s just overhead in disguise.

Naval reminds us of a better kind of leverage:

“… a democratic form - “Products with no marginal cost of replication” — books, media, movies, and code.”

Things that scale without permission. If something requires ‘n’ engineering hours to build, we assume more will be do the job fast - but it ends up taking more time what a lean team would do. Management debt, more points for failure and less elasticity is a bane.

Every founder reaches a point where they realize managing people is less about leverage and more about alignment. The real leverage is what you build, not who you manage.

Build great products. Build great tools to empower lean teams to build great products.

Judgment

“Praise specifically, criticize generally.

…

Then people’s egos and identities, which we all have, don’t work against you. They work for you.”

The more I lead, the more I realize management isn’t about control — it’s about psychology. As a founder, you quickly realize feedback is a double-edged sword — necessary, but often wounding.

Naval’s principle is pure gold: specific praise builds trust; general criticism preserves dignity.

You can tell someone, “You did this brilliantly,” but when it’s time to fix things, talk about the system, not the person.

When you praise specifically, people feel seen. When you criticize generally, people feel safe.

It’s not manipulation — it’s empathy applied to leadership.

And then there’s radical honesty.

When no one speaks truth to power, bad decisions compound. Radical honesty doesn’t mean being blunt; it means being clear.

Teams don’t crumble because they argue; they crumble because they don’t.

Happiness

I see people around me a lot successful or making a lot of money, yet they are not happy. A specific section of the book aptly hits like a diagnosis.

“Desire is a contract you make with yourself to be unhappy until you get what you want.”

We all are too attached to the outcomes. We keep postponing happiness until after the next milestone.

We bought a new car. Now, I’m waiting for the new car to arrive. Of course, every night, I’m on the forums reading about the car. Why? It’s a silly object. It’s a silly car. It’s not going to change my life much or at all. I know the instant the car arrives I won’t care about it anymore. The thing is, I’m addicted to the desir-ing. I’m addicted to the idea of this external thing bringing me some kind of happiness and joy, and this is completely delusional.

The truth is, we’re just addicted to desiring.

Sanity

Often things might be bit overwhelming, so keeping your mind sane is of utmost importance. Yes, there are age-old advices like physical workouts, good diet, meditation, etc. but there are few things which offers new perspective.

“Enlightenment is the space between your thoughts.”

For me, that space is when I’m alone on a Sunday evening, laptop shut, mind quiet. For five minutes, I’m not building or planning — I just am. That’s the rarest kind of wealth. That of often where serendipity happens. You get clarity of thought. You become productive.

I’m less habitual than most people. I don’t like structure my day. To the extent I have habit, I try to make them more deliberate rather than accidents of history.

Most people run their lives on autopilot — routines formed from school, jobs, family expectations, or old patterns. Naval rejects that. He believes habits should be designed, not inherited.

“To make an original contribution, you have to be irrationally obsessed with something.”

Obsession is the entry ticket.

You can’t fake it. You can’t outsource it. If you’re not a little crazy about what you’re building, it’s probably not worth building.

But obsession needs a container. That’s where Naval’s second rule comes in:

“Set up systems, not goals.”

Goals are binary — they make you anxious before you hit them and empty afterward. Systems are quiet — they compound in the background.

Use your judgment to figure out what kinds of environments you can thrive in, and then create an environment around you so you’re statistically likely to succeed.

The current environment programs the brain, but the clever brain can choose its upcoming environment.

Your environment programs your brain — so design it carefully.

The Real Product

Here’s the truth no one tells you when you start:

You think you’re building a company. You’re actually building yourself.

Every hiring decision, every setback, every all-nighter — it’s shaping your judgment, your emotional range, your relationship with failure.

Naval’s wisdom isn’t really about wealth or startups. It’s about awareness.

And in that sense, every founder’s journey is spiritual whether they admit it or not.

We’re all just trying to create something outside that reflects who we’re becoming inside.