[{"data":1,"prerenderedAt":700},["ShallowReactive",2],{"navigation":3,"/blog/build-small-things":143,"blog-surround-/blog/build-small-things":461,"related-posts-/blog/build-small-things":465},[4,70],{"title":5,"path":6,"stem":7,"children":8,"page":69},"Gallery","/gallery","gallery",[9,13,17,21,25,29,33,37,41,45,49,53,57,61,65],{"title":10,"path":11,"stem":12},"2013 Paintings","/gallery/2013-paintings","gallery/1.2013-paintings",{"title":14,"path":15,"stem":16},"Subway","/gallery/subway","gallery/10.subway",{"title":18,"path":19,"stem":20},"Umbrellas","/gallery/umbrellas","gallery/11.umbrellas",{"title":22,"path":23,"stem":24},"Blutac","/gallery/blutac","gallery/12.blutac",{"title":26,"path":27,"stem":28},"I Must Not Write On The Wall","/gallery/i-must-not-write-on-the-wall","gallery/14.i-must-not-write-on-the-wall",{"title":30,"path":31,"stem":32},"Lost Glove Rug","/gallery/lost-glove-rug","gallery/15.lost-glove-rug",{"title":34,"path":35,"stem":36},"Oddities","/gallery/oddities","gallery/16.oddities",{"title":38,"path":39,"stem":40},"Drawings","/gallery/drawings","gallery/2.drawings",{"title":42,"path":43,"stem":44},"Grids","/gallery/grids","gallery/3.grids",{"title":46,"path":47,"stem":48},"Marks","/gallery/marks","gallery/4.marks",{"title":50,"path":51,"stem":52},"Veils","/gallery/veils","gallery/5.veils",{"title":54,"path":55,"stem":56},"Space Above Tall Buildings","/gallery/above","gallery/6.above",{"title":58,"path":59,"stem":60},"Balloons and Shoes","/gallery/balloons-and-shoes","gallery/7.balloons-and-shoes",{"title":62,"path":63,"stem":64},"Christmas Trees","/gallery/christmas-trees","gallery/8.christmas-trees",{"title":66,"path":67,"stem":68},"Flags","/gallery/flags","gallery/9.flags",false,{"title":71,"path":72,"stem":73,"children":74,"page":69},"Blog","/blog","blog",[75,79,83,87,91,95,99,103,107,111,115,119,123,127,131,135,139],{"title":76,"path":77,"stem":78},"QWERTY Keyboard Installation","/blog/qwerty-keyboard-installation","blog/08.qwerty-keyboard-installation",{"title":80,"path":81,"stem":82},"Hyperlight - Single Bit Communication","/blog/hyperlight-single-bit-communication","blog/09.hyperlight-single-bit-communication",{"title":84,"path":85,"stem":86},"Dirty Fingerprints Screensaver","/blog/dirty-fingerprints-screensaver","blog/10.dirty-fingerprints-screensaver",{"title":88,"path":89,"stem":90},"Why it takes 2 people to design 1 UX","/blog/why-it-takes-2-people-to-design-1-ux","blog/11.why-it-takes-2-people-to-design-1-ux",{"title":92,"path":93,"stem":94},"Why half is not equal to 0.5","/blog/why-half-is-not-equal-to-point-five","blog/12.why-half-is-not-equal-to-point-five",{"title":96,"path":97,"stem":98},"Zero Tech Debt Will Kill Your Startup","/blog/zero-tech-debt-will-kill-your-startup","blog/13.zero-tech-debt-will-kill-your-startup",{"title":100,"path":101,"stem":102},"iTunes in the Browser: Building a SPA in 2004","/blog/itunes-in-the-browser-building-a-spa-in-2004","blog/14.itunes-in-the-browser-building-a-spa-in-2004",{"title":104,"path":105,"stem":106},"Spotify for the Mall: FYE's listening kiosk in 2005","/blog/spotify-for-the-mall-fye-listening-kiosk-in-2005","blog/15.spotify-for-the-mall-fye-listening-kiosk-in-2005",{"title":108,"path":109,"stem":110},"Click Where It Hurts: The WebMD Symptom Checker Story","/blog/click-where-it-hurts-the-webmd-symptom-checker-story","blog/16.click-where-it-hurts-the-webmd-symptom-checker-story",{"title":112,"path":113,"stem":114},"AI is Coming for Your APIs","/blog/ai-is-coming-for-your-apis","blog/17.ai-is-coming-for-your-apis",{"title":116,"path":117,"stem":118},"Real-Time Geometric Rendering of Web Page Architecture","/blog/real-time-geometric-rendering-web-page-architecture","blog/18.real-time-geometric-rendering-web-page-architecture",{"title":120,"path":121,"stem":122},"Amazon's AI Gamble: The Real Cost of Panic Investing","/blog/amazons-ai-gamble-the-real-cost-of-panic-investing","blog/19.amazons-ai-gamble-the-real-cost-of-panic-investing",{"title":124,"path":125,"stem":126},"Cursor's \"Trust Me Bro\" Vibes, Backed by RL Isn't Quite There Yet","/blog/cursor-s-trust-me-bro-ux-backed-by-rl-isn-t-quite-there-yet","blog/20.cursor-s-trust-me-bro-ux-backed-by-rl-isn-t-quite-there-yet",{"title":128,"path":129,"stem":130},"Building a LinkedIn ML Persona: Part 1 - The Data Harvest","/blog/building-a-linkedin-ml-persona-part-1-the-data-harvest","blog/21.building-a-linkedin-ml-persona-part-1-the-data-harvest",{"title":132,"path":133,"stem":134},"Why LLMs Can't Play Chess","/blog/why-llms-cant-play-chess","blog/22.why-llms-cant-play-chess",{"title":136,"path":137,"stem":138},"Ask Nico: Turning My Static Blog into a RAG-Powered LLM Chat","/blog/ask-nico-turning-my-static-blog-into-a-rag-powered-llm-chat","blog/23.ask-nico-turning-my-static-blog-into-a-rag-powered-llm-chat",{"title":140,"path":141,"stem":142},"Build Small Things: A Manifesto for Successful Software Development","/blog/build-small-things","blog/build-small-things",{"id":144,"title":140,"askNicoQuestion":145,"authors":146,"badge":152,"body":159,"date":453,"description":454,"extension":455,"image":456,"meta":457,"navigation":458,"path":141,"seo":459,"stem":142,"__hash__":460},"posts/blog/build-small-things.md","What is the Doom Spiral of Slowness?",[147],{"name":148,"to":149,"avatar":150},"Nico Westerdale","https://www.nicowesterdale.com",{"src":151},"https://storage.googleapis.com/nico-westerdale-images/info/headshot-new.jpg",[153,155,157],{"label":154},"Leadership",{"label":156},"Engineering",{"label":158},"Product Management",{"type":160,"value":161,"toc":441},"minimark",[162,167,171,183,186,189,192,195,198,201,204,207,210,215,218,221,224,227,230,241,244,247,250,253,257,260,263,270,273,280,309,312,319,322,325,328,332,335,340,343,363,367,370,373,376,379,382,386,389,396,399,405,408,411,415,418,421,425,432,435,438],[163,164,166],"h2",{"id":165},"build-small-things","Build Small Things",[168,169,170],"p",{},"The more complex a project is, the more likely it is to fail.",[168,172,173,174,178,179,182],{},"The data clearly confirms it, but if you've spent any time in software development you just ",[175,176,177],"em",{},"know"," this is true. We can ",[175,180,181],{},"feel"," the uncomfortable and inevitable words being spoken: \"I'm sorry but it was just a lot more complicated than we originally thought\". Let's be clear, this problem is extremely costly, it's endemic and it's not improving. The solutions we have today; the catch-all that is \"agile\", is far from perfect. AI agents are not going to save us.",[168,184,185],{},"Build Small Things is the foundational principle that explains why software development succeeds or fails. Every failure can be traced to complexity. Every success can be traced to simplicity.",[168,187,188],{},"This simple yet radical approach applies in a multiplicity of arenas. Project planning. Product iteration. Process design. Code organization. Individual work patterns. The same principle that makes a single line of code safe to deploy makes a small project succeed. The same principle that makes a simple system maintainable makes a simple process efficient.",[168,190,191],{},"Complexity fails. Simplicity wins. This is true at every level, from a hobby project to a global enterprise architecture.",[168,193,194],{},"This isn't just a theory. As a technical leader who's been in the guts of everything from seed-stage startups to hyper-growth unicorns, I've seen that the most common culprit for sluggish development, off-track projects, or projects that never see release day isn't technical debt or a lack of talent. It's the process itself. It’s the very structure we use to think about and practice our work.",[168,196,197],{},"Software empowers people, it makes their lives better. It allows us to do remarkable computational things that our brains are ill-equipped to do on their own. To work in software is to improve the lives of those around us. When we can make small improvements to the lives of those people on a daily basis the cumulative impact is profound. Results are constant, impactful and are measured in real time, not quarterly. This requires a different way of thinking. This requires embarking on simple projects with clear goals. This requires writing code that's simple to reason about. This requires full understanding on the \"why\" behind the \"how\".",[168,199,200],{},"Build Small Things is the alternative to Big Project Syndrome complexity. We don't escape complexity with more process, more ceremonies, or more management. We escape it by making today's fear-based process irrelevant. We ship constantly. We integrate consistently. We discuss continuously. We build a system so fluid and resilient that the bureaucratic rituals of \"Agile\" look as foolish and outdated as they actually are.",[168,202,203],{},"We expect problems to occur. We have the levers to fix things instantly, because we allow for a system that can often bend and sometimes break. Instead of investing in the theater of sprint planning, we invest in a resilient deployment system that makes shipping code, and fixing it, instant, safe, and above all, expected. We escape the giant, terrifying releases trapped in a sprint-first architecture by making releases so small and frequent they become non-events.",[168,205,206],{},"Build Small Things isn't just about code. It's about projects that can ship in days, not months. It's about processes that enable real organizational change, not ceremonies that create delays. It's about individual engineers committing hourly, not weekly. It's about organizations that eliminate complexity, not manage it. It's about inspiring those of us who work in software development to say \"I built something worthwhile today\" and those of us that use software to become active participants in it.",[168,208,209],{},"This manifesto shows you how.",[211,212,214],"h3",{"id":213},"the-trap-the-two-week-prison","The Trap: The Two-Week Prison",[168,216,217],{},"Your process is either generating value or it's generating overhead. There is no neutral state. As engineering teams grow, we instinctively pile on process to compensate for the natural erosion of interpersonal trust and the rising cost of failure. But every step added, every new ceremony, introduces latency. It creates task-switching costs. It turns a lean operation into a bureaucracy, one Jira ticket at a time.",[168,219,220],{},"A sprint is a time-box. A deadline. And deadlines are where good engineering goes to die. The entire structure encourages you to batch up work, creating large, complex pull requests that are hell to review and even harder to merge. The need to \"finish the sprint\" leads to cutting corners and accumulating the very technical debt the process was supposed to prevent.",[168,222,223],{},"Think about what we try and cram into that two-week box. A Product Requirements Document has to be written. The work has to be prioritized against a dozen other screaming emergencies. UX has to design it. The team has to groom it. Then, and only then, can it be built and tested. We've taken the entire, lumbering waterfall process and simply chopped it into two-week chunks, pretending it's agile. It's a theatrical performance of productivity, where the main output isn't working software, but the successful completion of the ceremony itself.",[168,225,226],{},"Worse, it creates a built-in delay machine. A simple request made on day two of a sprint gets the dreaded reply: \"We'll get it in the next sprint.\" Let's do the math on that. The current sprint has to finish (two weeks). The next sprint has to be planned and completed (another two weeks). Then the code has to be tested and deployed. A simple, one-line change can easily take over a month to reach a customer. If you're lucky. This is the opposite of agile.",[168,228,229],{},"These \"best practices\" are the very things that create a self-fulfilling prophecy of slowness. When speed drops, what do we do? We add more process—more SCRUM, more testing, more review—to compensate. This, of course, further slows the team. The sprint cycle itself trains engineers to think in large, slow batches. Why ship a one-line fix today when you can bundle it into the grand, two-week release? This inevitably leads to enormous, multi-file pull requests that are impossible to review, riddled with merge conflicts, and terrifying to deploy. It is a spiral into inefficiency and shattered morale.",[168,231,232],{},[233,234],"img",{"alt":235,"className":236,"src":240},"The Doom Spiral of Slowness",[237,238,239],"rounded-lg","mx-auto","my-6","https://storage.googleapis.com/nico-westerdale-images/blog/build-small-things/build-small-things.png",[168,242,243],{},"While SCRUM, large PRs, and lengthy UAT are all on the list of rituals you should re-evaluate, there is one structure that is almost universally misused in high-growth companies: the dedicated Staging Environment and its fixed Sprint Release cycle.",[168,245,246],{},"In a startup desperately trying to find product-market fit, a lengthy, multi-step process for releasing code is poison. The delay between code completion and user validation is pure capital risk. Holding onto finished code for a multi-day review, merging it into a complex staging environment, and subjecting it to ceremonial testing is a luxury you cannot afford. It is simply too expensive.",[168,248,249],{},"The sprint necessitates a whole ecosystem of waste. It demands a persistent staging environment where finished code sits and rots, waiting for a ceremonial release day. It creates a fixed-cadence release cycle that is completely decoupled from business needs. In a startup desperately trying to find product-market fit, this is poison. The delay between code completion and user validation is pure capital risk. Holding onto finished code for a multi-day review and a multi-week sprint cycle is a luxury you cannot afford.",[168,251,252],{},"The single most dangerous structural dependency you can have is the fixed-cadence, gate-checked Sprint Release.",[211,254,256],{"id":255},"velocity-is-a-function-of-risk-tolerance","Velocity is a Function of Risk Tolerance",[168,258,259],{},"Why did the hyper-growth teams I ran at Gopuff operate without these typical dependencies? No sprints, no tickets, code shipped directly to prod. Because our operational goals defined an entirely different Risk vs. Velocity calculation. The CTO's job is not to eliminate risk; it's to choose the right risks to take.",[168,261,262],{},"I map every organization on a Risk vs Velocity plot. Seed-stage, Sinclair in 1981, and Gopuff in 2019 sit up and to the right. Nuclear plant software sits on the floor. Gopuff in 2023 had already slid back toward enterprise.",[168,264,265],{},[233,266],{"alt":267,"className":268,"src":269},"Velocity vs Risk",[237,238,239],"https://storage.googleapis.com/nico-westerdale-images/blog/build-small-things/velocity-vs-risk.png",[168,271,272],{},"Four quadrants. Only one of them is a place you survive early.",[168,274,275],{},[233,276],{"alt":277,"className":278,"src":279},"Risk vs Velocity Matrix",[237,238,239],"https://storage.googleapis.com/nico-westerdale-images/blog/build-small-things/risk-velocity-matrix.png",[281,282,283,291,297,303],"ul",{},[284,285,286,290],"li",{},[287,288,289],"strong",{},"Fragile"," (high risk, low velocity): you take the damage and still cannot ship.",[284,292,293,296],{},[287,294,295],{},"Stagnant"," (low risk, low velocity): enterprise. Nothing breaks because nothing changes.",[284,298,299,302],{},[287,300,301],{},"Fluid"," (high risk, high velocity): seed, Sinclair, early Gopuff. Brittle systems, tests optional, shipping is immediate. This is where you survive.",[284,304,305,308],{},[287,306,307],{},"Efficient"," (low risk, high velocity): the quadrant people pretend they occupy. You earn it later, after the architecture can absorb failure.",[168,310,311],{},"The job is not to live in Efficient on day one. The job is to pick a sweet spot under your actual risk tolerance.",[168,313,314],{},[233,315],{"alt":316,"className":317,"src":318},"Risk Tolerance",[237,238,239],"https://storage.googleapis.com/nico-westerdale-images/blog/build-small-things/risk-tolerance.png",[168,320,321],{},"The dependencies you skip are the ones that yank a growth company out of Fluid and into Stagnant before the money warrants it.",[168,323,324],{},"For a company fighting for product-market fit, the financial cost of losing two days of velocity to a review/staging/sprint process far outweighs the cost of a temporary bug in production. You are trading precious Time to Market for an illusion of safety. The true strategic value in the early days is validating your assumptions faster than your burn rate depletes your cash.",[168,326,327],{},"Every Agile ritual that slows down the clock—and the sprint is the master clock—accelerates the Days Until Bankruptcy counter.",[211,329,331],{"id":330},"the-way-out-velocity-as-a-system","The Way Out: Velocity as a System",[168,333,334],{},"So you want to skip the traditional dependencies without everything catching fire? You must replace Process-based Risk Mitigation with Structural & Cultural Risk Mitigation.",[336,337,339],"h4",{"id":338},"_1-architect-for-speed-with-tiny-atomic-units","1. Architect for Speed with Tiny, Atomic Units",[168,341,342],{},"You can't ship a massive, 100-file PR straight to production. But you can eliminate the need for it.",[281,344,345,351,357],{},[284,346,347,350],{},[287,348,349],{},"Commit small and often."," Every commit should do one thing and one thing only.",[284,352,353,356],{},[287,354,355],{},"Pair on everything."," This used to mean two humans. In the age of AI, it means a human-AI pair. The \"Trust me Bro\" UX of fully autonomous agents is a trap that creates a new Doom Spiral of endless review. The real velocity comes from the \"Editor\" mode workflow: the human is the architect and navigator, holding the context, while the AI is the brilliant but naive junior partner handling syntax and boilerplate. It's still pairing, just with a new kind of partner.",[284,358,359,362],{},[287,360,361],{},"Trunk-Based Development."," Avoid long-lived feature branches. The merge conflicts alone are a symptom of the Doom Spiral. Use short-lived branches or direct-to-main development combined with feature flagging.",[336,364,366],{"id":365},"_2-choke-your-legacy-code-to-death","2. Choke Your Legacy Code to Death",[168,368,369],{},"This philosophy of small, incremental change has a name when applied to legacy systems: The Strangler Fig Pattern. It's the most effective, and frankly most satisfying, way to deal with the monolithic monsters that inevitably grow inside any successful company.",[168,371,372],{},"You don't rewrite a legacy system. That's a fantasy sold by consultants and conference speakers. A full rewrite is a multi-year, multi-million dollar death march that will probably fail. Instead, you choke it out.",[168,374,375],{},"Like the tropical vine it's named after, you grow the new system around the old one. You identify a single piece of functionality, build a new service for it, and then use a proxy or router to divert a small fraction of live traffic to your new code. The old code and the new code run in parallel. You compare the outputs, the performance, the error rates. You prove, with real production data, that your new creation is superior.",[168,377,378],{},"This is self-testing in the only environment that matters: production. Once the new code is proven, you divert all traffic and turn off the old piece. You repeat this, function by function, until the old monolith is nothing but a hollowed-out husk, and you can delete it without ceremony.",[168,380,381],{},"This is how we evolved the Gopuff stack. We didn't stop the world to rewrite \"Mixcart\" into \"Novus\". We strangled it, piece by piece, while still shipping features at a ridiculous pace. It’s not about a big bang release; it's about a thousand tiny victories that, over time, result in a complete transformation. It trades the high risk of a total rewrite for the manageable risk of small, reversible changes.",[336,383,385],{"id":384},"_3-build-a-culture-of-distributed-trust","3. Build a Culture of Distributed Trust",[168,387,388],{},"The fundamental principle that allows a startup to move at speed is federated trust. And sprints are a declaration of mistrust. They are a tool for managers to control engineers, to package work into predictable, chartable units.",[168,390,391,392,395],{},"This principle doesn't change with AI; it becomes sharper. You are not trusting a black-box AI agent to ship to production. You are trusting the ",[175,393,394],{},"human-AI pair",". The engineer, augmented by this powerful new tool, is still the one you trust. They are accountable for the code, whether they typed it with their fingers or prompted it into existence. The trust is in the human's judgment, amplified by the tool.",[168,397,398],{},"My instruction to teams in the hyper-growth phase at Gopuff was blunt:",[400,401,402],"blockquote",{},[168,403,404],{},"\"Try and break it in the morning. You will not be blamed for breaking Production. We trust you to roll things back. This is a choice I have made that allows us to have increased velocity, and the risks have been clearly communicated to leadership.\"",[168,406,407],{},"This culture is supported by high-context collaboration and rapid deployment systems—not endless meetings or staging gates. The energy spent waiting on a Jenkins job or coordinating a two-week sprint release should be reinvested into developing resilient infrastructure that enables instant rollback and deployment.",[168,409,410],{},"Skip the dependency. Embrace the fluidity. Only then can you find your true velocity.",[211,412,414],{"id":413},"process-is-a-weapon-use-it-wisely","Process is a Weapon, Use it Wisely",[168,416,417],{},"The choice is simple. You can build a system of processes, ceremonies, and gates—a bureaucracy designed to protect you from incompetence. The sprint is the cornerstone of\nthis system. It will feel safe. It will generate charts and reports. And it will slowly, inexorably, strangle your company's ability to ship. It is a system built on a\nfoundation of mistrust.",[168,419,420],{},"Or, you can build a system of people. A culture of federated trust where engineers are empowered to move fast and fix their own messes. A system where velocity is a\ndeliberate cultural and architectural choice, not an accidental outcome. This system is faster, more resilient, and infinitely more satisfying. In the age of AI, where the\nspeed of creation is accelerating, this is the only system that will win. The Doom Spiral is a choice. Choose not to enter it.",[211,422,424],{"id":423},"the-goal-build-small-things","The Goal: Build Small Things",[168,426,427],{},[233,428],{"alt":429,"className":430,"src":431},"Build small things",[237,238,239],"https://storage.googleapis.com/nico-westerdale-images/blog/build-small-things/build-small-things-callout.png",[168,433,434],{},"Imagine a world where the words \"merge conflict\" are a forgotten relic of a bygone era, a curse word from a dead language. A world where developers never spend hours untangling the Gordian knot of a long-lived feature branch. This isn't a fantasy. It's the natural, inevitable outcome of a system built on a single, ruthless principle: build small things.",[168,436,437],{},"When your engineers are shipping tiny, atomic units of work every single day, the very concept of a merge conflict becomes absurd. You can't have a conflict when you're constantly integrating. This requires a different way of thinking. It requires writing bulletproof code, not because of some corporate mandate, but because the units are so small and well-defined that they are simple to reason about and nearly impossible to break in catastrophic ways.",[168,439,440],{},"This is the alternative to the Doom Spiral. You don't escape it with more process, more ceremonies, or more managers. You escape it by making the process irrelevant. You ship constantly. You integrate constantly. And you build a system so fluid and resilient that the bureaucratic rituals of \"Agile\" look as foolish and outdated as they actually are. This is the foundation of a truly agile infrastructure. When a problem occurs, it's trivial to roll back a single, tiny change. You have the levers to fix things instantly. Instead of investing in the theater of sprint planning, you invest in a resilient deployment system that makes shipping code—and fixing it—fast, safe, and boring. You escape the giant, terrifying releases trapped in a sprint-first architecture by making releases so small and frequent they become non-events.",{"title":442,"searchDepth":443,"depth":443,"links":444},"",2,[445],{"id":165,"depth":443,"text":166,"children":446},[447,449,450,451,452],{"id":213,"depth":448,"text":214},3,{"id":255,"depth":448,"text":256},{"id":330,"depth":448,"text":331},{"id":413,"depth":448,"text":414},{"id":423,"depth":448,"text":424},"2026-09-03T00:00:00.000Z","Whether in project planning, process design, or individual work patterns, complexity creates project failure. This manifesto showcases pragmatic steps to create impactful software and a highly engaged organization capable of meaningful change.","md",{"src":240},{},true,{"title":140,"description":454},"wuJKsNYaGZwzRQjcn5FxxTSepoxv1gsXP09MLEG_59U",[462,464],{"title":136,"path":137,"stem":138,"description":463,"children":-1},"Here is how I used Nuxt, Markdown, and Vertex AI Search to turn my blog into a queryable LLM knowledge base that actually knows what I wrote.",null,[466],{"id":467,"title":96,"askNicoQuestion":468,"authors":469,"badge":472,"body":474,"date":694,"description":695,"extension":455,"image":696,"meta":697,"navigation":458,"path":97,"seo":698,"stem":98,"__hash__":699},"posts/blog/13.zero-tech-debt-will-kill-your-startup.md","When is tech debt your best friend?",[470],{"name":148,"to":149,"avatar":471},{"src":151},[473],{"label":154},{"type":160,"value":475,"toc":684},[476,479,482,485,489,492,499,502,505,511,514,518,521,528,535,538,542,545,548,551,555,558,563,583,589,595,599,602,605,608,615,619,622,636,642,648,652,655,658,661,665,668,671,674,681],[168,477,478],{},"Picture this: You're tasked with migrating the digital backbone and UX of \"the fashion bible\" WWD.com, Women's Wear Daily, a 110-year-old institution that serves 1.5 million unique users and generates over 15 billion impressions. This wasn't just any website; this was Conde Nast's biggest database migration, supporting the daily media of record for the entire global fashion industry.",[168,480,481],{},"When you're handling a platform that influential fashion executives, Wall Street analysts, and industry titans depend on for critical business decisions, there's no room for shortcuts. Every line of code had to be pristine. Every potential failure point eliminated. I spent months training the team, systematizing the UX, and ensuring our architecture could handle the massive scale. Over 10 million monthly visits from an audience that expects nothing less than perfection and the UX had to look the part; just like Conde Nast's own Anna Wintour who I did bump into in the elevator once, but that's another story.",[168,483,484],{},"In that context, technical debt wasn't just inadvisable, it was dangerous and we were there to fix it, train up the in-house team. WWD was the last of the properties that we migrated, with good reason, it was by far the biggest and most complex. Clean code, comprehensive test coverage, and minimal technical debt weren't nice-to-haves; they were the foundation that kept a century-old media empire running.",[163,486,488],{"id":487},"the-engineering-dogma-that-kills-startups","The Engineering Dogma That Kills Startups",[168,490,491],{},"However, those same engineering principles that are essential for enterprise platforms become startup killers. The literature on the subject always speaks of tech debt as bad, and never suggests that it's even acceptable.",[168,493,494],{},[233,495],{"alt":496,"className":497,"src":498},"Eliminate Tech Debt",[237],"https://storage.googleapis.com/nico-westerdale-images/blog/zero-tech-debt-will-kill-your-startup/eliminate-tech-debt.png",[168,500,501],{},"I watched a promising early-stage company spend six months building the \"perfect\" architecture while their competitor shipped a scrappy MVP and captured the entire market. The startup had beautiful, maintainable code that could theoretically scale to WWD.com's traffic levels. They also had zero customers.",[168,503,504],{},"Every engineering team I've worked with since has the same reflexive response to technical debt: eliminate it. It's treated like a disease, something shameful that needs to be cleaned up before anyone notices. But that WWD mindset, while perfect for established platforms, becomes a startup killer.",[168,506,507,508],{},"Let me state it plainly: ",[287,509,510],{},"technical debt isn't always the enemy. Sometimes it's your best friend.",[168,512,513],{},"Fast forward to my time at Gopuff during the hypergrowth phase. We didn't have a choice in building the \"right\" architecture. The business was moving too fast for even a comprehensive staging environment to be set up. Instead, we chose fast features that would unlock our next stage of growth, and it worked. We chose speed. The technical debt we accumulated (and we had bags of it piled up) didn't kill us, it funded our next round and rocketed the company to a valuation in the tens of billions.",[163,515,517],{"id":516},"what-velocity-actually-means","What Velocity Actually Means",[168,519,520],{},"Technology leaders often get the concept of Velocity wrong, as we're measuring the wrong thing. Coming from enterprise platforms where we measure system stability and code quality, we apply the same metrics to startups.",[168,522,523],{},[233,524],{"alt":525,"className":526,"src":527},"The Value of Velocity",[237],"https://storage.googleapis.com/nico-westerdale-images/blog/zero-tech-debt-will-kill-your-startup/the-value-of-velocity.png",[168,529,530,531,534],{},"Velocity isn't story points completed. ",[287,532,533],{},"Velocity is the amount of business value you create in a given time period."," That's it.",[168,536,537],{},"Sometimes creating that value means taking shortcuts that would make your engineer brain cringe. Sometimes it means building something quick and dirty that you know you'll have to rewrite in six months. And sometimes, often, that's exactly the right choice, because the simple brutal fact is that if you don't then in six months you might not have a company to rewrite code for.",[163,539,541],{"id":540},"the-real-job-of-a-startup-cto","The Real Job of a Startup CTO",[168,543,544],{},"A startup CTO isn't the same job as an enterprise technology leader. I've worn many hats, and at WWD, my job was to maintain and improve a proven system. At a startup, you're much more like the CFO of technology risk.",[168,546,547],{},"Every technical decision is a financial decision. When you choose to refactor that messy module instead of shipping the feature your sales team desperately needs to close their next deal, you're making a bet with company money. You're betting that the long-term benefits of clean code outweigh the short-term cost of potentially losing that customer.",[168,549,550],{},"At WWD, that bet made sense; we had very stable revenue, we had time, we had users who would stick around. At a startup? Often it doesn't.",[163,552,554],{"id":553},"the-three-questions-every-startup-cto-must-answer","The Three Questions Every Startup CTO Must Answer",[168,556,557],{},"When I work with startup CTOs, I teach them a simple framework. Before any technical debt discussion, you need to answer three questions:",[168,559,560],{},[287,561,562],{},"1. What stage are we actually at?",[281,564,565,571,577],{},[284,566,567,570],{},[287,568,569],{},"MVP stage:"," Maximum debt is not just acceptable, it's required. Speed to market trumps everything else.",[284,572,573,576],{},[287,574,575],{},"Product-market fit:"," Pay down only the debt that's actively blocking further velocity. Everything else can wait.",[284,578,579,582],{},[287,580,581],{},"Growth stage:"," Now you focus on stability debt that could cost you revenue or uptime.",[168,584,585,588],{},[287,586,587],{},"2. What's our actual risk tolerance?","\nA seed-stage startup burning through their last $200K has a very different risk profile than a Series B company with $50M in the bank and paying customers. Your technical debt strategy should reflect that reality, not some abstract engineering ideal.",[168,590,591,594],{},[287,592,593],{},"3. What's the real cost here?","\nNot the theoretical cost of \"bad code\" that makes engineers uncomfortable, but the measurable business impact. Is this debt actually slowing us down right now, or does it just offend our sense of what good code should look like?",[163,596,598],{"id":597},"the-contract-mindset","The Contract Mindset",[168,600,601],{},"This is the fundamental shift every startup CTO needs to make: stop thinking only as an engineer and start using engineering and technical debt as financial instruments. Technical debt isn't a mess to clean up, it's a growth lever to manage.",[168,603,604],{},"Simple example: When you take out a mortgage to buy a house, you don't throw every spare dollar at paying it off immediately. You make strategic payments while using your remaining capital for investments that might have higher returns. Maybe you invest in the stock market, maybe you start a business, maybe you just keep cash on hand for emergencies.",[168,606,607],{},"Technical debt works exactly the same way. Sometimes the highest-return investment isn't paying down that debt. It's shipping the feature that unlocks your next funding round, or building the integration that lands your biggest customer yet.",[168,609,610],{},[233,611],{"alt":612,"className":613,"src":614},"Sign Your Tech Debt Contract",[237],"https://storage.googleapis.com/nico-westerdale-images/blog/zero-tech-debt-will-kill-your-startup/sign-your-tech-debt-contract.png",[163,616,618],{"id":617},"what-every-startup-cto-needs-to-know","What Every Startup CTO Needs to Know",[168,620,621],{},"When I teach at Wharton's CTO program or work with early-stage technology leaders, these are the core principles I emphasize:",[168,623,624,627,628,635],{},[287,625,626],{},"Your engineers will default to perfectionism."," This is a good thing, and whenever I post about this topic on LinkedIn I invariably get ",[629,630,634],"a",{"href":631,"rel":632},"https://www.linkedin.com/posts/iconico_when-writing-code-im-heckin-dumb-i-perform-activity-7046236527755976704-p8o8",[633],"nofollow","flamed in the comments by engineers",". Most engineers have been trained at companies where clean code is always better. But in a startup, clean code that ships too late might just be worthless code. Or it may get thrown away a week later. You have to actively manage this instinct for perfectionism.",[168,637,638,641],{},[287,639,640],{},"Measure what actually moves the needle."," Stop tracking code coverage and start tracking time-to-market. Stop measuring technical debt and start measuring business velocity. The metrics that mattered at scale don't matter when you're burning cash and racing to product-market fit and barely trying to stay in business.",[168,643,644,647],{},[287,645,646],{},"Embrace strategic messiness."," The goal isn't to build software that will last forever, it's to build software that will get you to the next milestone alive. You can always refactor later if you're successful enough to have a \"later.\"",[163,649,651],{"id":650},"the-real-cost-of-zero-debt","The Real Cost of Zero Debt",[168,653,654],{},"I've seen this pattern repeat: startups die because they prioritize architectural purity over market reality. They have beautiful, clean codebases that nobody uses because they shipped six months after their competitor captured the market.",[168,656,657],{},"The pursuit of zero technical debt isn't just inefficient in a startup context, it's often actively dangerous. It's a luxury that early-stage companies literally can't afford, like spending your last $50K on a Herman Miller chair instead of paying your developers.",[168,659,660],{},"The startup CTO's job isn't to build perfect systems. It's to build systems that are just good enough to get you to the next stage, where you'll have more resources, more time, and more certainty about what you're actually building. At that point you'll have learned so much more about your business that you'll invariably want to rewrite big swaths of code anyway, so start with this in mind.",[163,662,664],{"id":663},"the-paradox-of-perfect-code","The Paradox of Perfect Code",[168,666,667],{},"Here's the fundamental paradox every startup CTO must understand: the pursuit of perfect code can create imperfect businesses.",[168,669,670],{},"In enterprise environments, technical debt is indeed dangerous because the system is the business. But in startups, the business is still becoming the system. Technical debt isn't a sign of failure; it's evidence of learning.",[168,672,673],{},"The most successful startups I've worked with treat their early codebase like a prototype, not a monument. They understand that premature optimization isn't just inefficient, it's a form of procrastination. You're testing constantly so optimizing for a future you can't predict is often less important than solving for the present you can measure and impact now.",[168,675,676,677,680],{},"The real insight isn't that technical debt is good or bad. It's that ",[287,678,679],{},"context determines everything",". The same engineering principles that keep century-old media empires running will kill month-old startups. The same shortcuts that would be reckless at enterprise scale become essential survival tools at startup scale.",[168,682,683],{},"Your job as a startup CTO isn't to eliminate technical debt. It's to be strategic about when you accumulate it, when you pay it down, and when you let it compound. Master that timing, and you'll build systems that don't just work, they'll be wildly successful.",{"title":442,"searchDepth":443,"depth":443,"links":685},[686,687,688,689,690,691,692,693],{"id":487,"depth":443,"text":488},{"id":516,"depth":443,"text":517},{"id":540,"depth":443,"text":541},{"id":553,"depth":443,"text":554},{"id":597,"depth":443,"text":598},{"id":617,"depth":443,"text":618},{"id":650,"depth":443,"text":651},{"id":663,"depth":443,"text":664},"2024-03-13T00:00:00.000Z","Working on large-scale platforms taught me the value of pristine engineering. But those same principles that work for enterprise platforms can kill early-stage companies.",{"src":614},{},{"title":96,"description":695},"TrIeg4nLnuzNrAS44ObFTlqJ_Bx7H5HCRz_s3B6xR_c",1788496874177]