Jeremy Thompson

Respect, I've done a bunch of these, thought you guys deserved one. Basecamp / 37signals (Project Management) The Status: Good. The Pitfall Avoided: The "Big Ball of Mud" monolith and out-of-control microservice debt. The Evidence: David Heinemeier Hansson (@DHH) & Jason Fried famously documented their approach in the book Getting Real. They have actively rejected the trend of over-engineering applications with massive microservice meshes, choosing instead to stay with highly optimized "Majestic Monoliths." How they avoid it: The "Shape Up" Methodology: Basecamp developed its own product management framework called Shape Up. Work is structured in strict 6-week cycles, followed by a mandatory 2-week "Cool-Down" period. During these two weeks, engineers are strictly forbidden from building new features. Instead, 100% of their time is spent fixing bugs, refactoring code, and eliminating debt. Deleting Dead Code: Basecamp aggressively sunsets old versions or spins off features that aren't widely used, rather than indefinitely supporting legacy technical baggage.

@DavidPerlov Plenty where that came from!

First I critique something particularly embarrassing in Basecamp 4, and then show you how we completely redesigned the same flow in Basecamp 5. We grow!

@Mike_Preston17 It's unfortunate. After Stackoverflows fall there are no forums to discuss "Errors" and socials are certainly not the place. I feel OpenAI needs to give back to the community what they ultimately used under creative commons. Not just monthly bills.

I'll be coding 'till I'm dead, so I'm happy to train the next gen on my own. My first boss/PM trained me and he wasn't exactly the best coder in the world - he just knew how to prioritize things, gather requirements, be a DBA and a QA tester - all at the same time. That's the job. There's not really training for SWE - you just jump in, get firehosed. The real ones are the ones who love coding (and have good taste in it) and stay for the long run. In fact, if you have impostor syndrome, or are concerned about AI (for the right reasons, not just for your 9-5 paycheck), then you're probably a real one, and I want to keep you around. As my old PM always told me, "it's people, not software, that is the problem". All AI's going to do is weed out who shouldn't be here.

@1Umairshaikh Here's a few🧵 x.com/meaningoflight…

What’s the fastest way to know a startup is cooked?

SaaS Failures and Successes🧵Summary The Blueprint for Fixing These Issues If you look closely at these successes, they all followed a specific playbook to fix what they neglected: Decouple the Problem: They took the messy system (like billing or logging) out of the core application code and moved it to its own isolated micro-service. Expose it to the User: They turned a back-end engineering headache into a front-end user feature (e.g., Zap History, Slack Billing Dashboard). Automate the Gatekeeping: They used automated code or data validation layers to stop bad data or bad configurations from breaking the system ever again. Zapier (Solving: The Missing Audit Logs & Visibility Trap) The Neglect: Failing to log user and system actions, leaving customers completely blind when an automation or integration fails. How They Solved It: Zapier automates workflows between thousands of apps. In their early days, if a "Zap" failed, users had no idea why, which completely overwhelmed Zapier's customer support teams with tickets asking "Why didn't my automation run?" The Fix: Zapier invested heavily in building the Zap History engine. They decoupled their automation execution engine from their logging engine using message queues (like Apache Kafka). Every single step of an automation generates an unalterable log entry. They exposed this directly to the user in a highly scannable, clean UI. Users could suddenly debug their own failed steps, instantly cutting support ticket volumes and providing enterprise-grade audit capability natively. Slack (Solving: The Rigid Billing & Seat-Licensing Trap) The Neglect: Hardcoding pricing tiers or locking users into rigid contracts that don't reflect actual product usage, causing billing disputes. How They Solved It: Traditional B2B SaaS forces companies to buy a block of 100 user seats. If only 50 people use it, the company feels ripped off. If they need 101, the system blocks them. The Fix: Slack revolutionized SaaS billing by engineering the Fair Billing Policy. They built an internal monitoring system that constantly tracks user activity. If an employee stops logging into Slack for more than 14 days, the billing system automatically drops them from the active seat count and refunds a prorated credit to the company's account. Building the real-time tracking architecture required to calculate variable, prorated billing dynamically across millions of users was incredibly difficult, but it completely eliminated customer billing friction and drove unprecedented enterprise trust. #startups #techdebt #blitzscaling

SaaS Failures and Successes🧵10/10 Figma (Design Collaboration) The Status: Good. Built a highly complex application without sacrificing performance. The Evidence: Figma successfully disrupted Adobe by building a browser-based design tool that felt as fast as a desktop application. They documented their engineering journey, specifically how they scaled their multi-player collaboration engine. How they avoid it: WebAssembly Pioneer: Instead of building a standard web app that would slow down with large design files, Figma wrote their entire editing engine in C++ and compiled it to WebAssembly. Custom Data Structures: They avoided the trap of using heavy relational databases for real-time collaboration. Instead, they built a custom live-syncing system using conflict-free replicated data types (CRDTs) that prevents data conflicts before they can ever reach a database. #startups #techdebt #blitzscaling

SaaS Failures and Successes🧵9/10 Stripe (Payment Infrastructure) The Status: Good. The Pitfall Avoided: Hardcoded billing logic, data schema rigidity, and breaking API changes. The Evidence: Stripe manages transactions for millions of businesses worldwide. In a fast-moving fintech space, breaking a database schema or an API endpoint could crash thousands of digital economies. How they avoid it: The API Versioning Layer: Stripe avoids permanent API debt via an architectural masterpiece: an Abstract Transformation Layer. When Stripe updates its core database and code logic, it doesn't force users to rewrite their code. Instead, they write declarative "gateways" that dynamically translate old API requests into the new system architecture on the fly. This allows Stripe to refactor its internal architecture constantly while guaranteeing legacy code written in 2012 still functions perfectly today. #startups #techdebt #blitzscaling

SaaS Failures and Successes🧵8/10 HashiCorp (Infrastructure Software) The Status: Good. Maintained a strict, predictable release cycle for highly complex infrastructure tools like Terraform and Vault. The Evidence: HashiCorp’s co-founder, Mitchell Hashimoto (@mitchellh), established a culture of writing exhaustive design documents (RFCs) before a single line of code was written. This culture is heavily documented in their engineering guidelines. How they avoid it: Zero-Dependency Binaries: They chose Go as their primary language to ensure all tools compile into a single, self-contained binary file. This eliminated the dependency hell that plagues other enterprise software platforms. Extensible Plugin Architecture: Instead of hardcoding integrations into the core engine, they built a strict plugin system. If a cloud provider changes their API, it only affects an isolated plugin, ensuring the core platform remains untouched by tech debt. Success: Google GCP is rewriting their IaC based around Terraform. #startups #techdebt #blitzscaling

SaaS Failures and Successes🧵7/10 Shopify (E-commerce Platform) The Status: Medium. Allowed their core codebase to grow into an unmanageable monolith, but successfully re-architected it without tearing it down. The Evidence: Shopify’s engineering team has published extensively on how they rescued their massive Ruby on Rails codebase, which contains millions of lines of code and over a decade of historical debt. The Debt Story: As hundreds of engineers added features to Shopify, the core database became tightly coupled. A change to the shipping code would accidentally break the billing code because the boundaries between modules had completely dissolved. How they managed it: Instead of rewriting the platform from scratch - which usually kills SaaS companies - Shopify implemented a strict architectural pattern called a Componentized Monolith. They used automated code-analysis tools to draw hard boundaries around different parts of the application, physically blocking engineers from writing code that crosses those boundaries without permission. #startups #techdebt #blitzscaling

SaaS Failures and Successes🧵6/10 Uber (Ride-Hailing & Logistics) The Status: Medium. Accumulated catastrophic microservice debt but executed a massive, multi-year course correction. The Evidence: Uber's engineering blog famously detailed their transition from a monolith to microservices, and then their painful shift back to "Domain-Oriented Microservices" (DOMA) to fix the mess they created. The Debt Story: In their hyper-growth phase, Uber let engineering teams build whatever they wanted, using any language they chose. This resulted in over 4,000 independent microservices. The system became a chaotic web where nobody knew which service talked to what, causing frequent outages and making simple feature updates impossible. How they managed it: Uber had to halt major feature development to group those 4,000 chaotic services into clearly defined logical "domains." They instituted strict gateways and forced teams to drastically reduce the number of microservices, proving that too many microservices can create just as much debt as a messy monolith. #startups #techdebt #blitzscaling

SaaS Failures and Successes🧵5/10 Twitter / X (Pre-2022 Architecture) The Status: Bad. Suffered from deep, systemic architectural debt that severely restricted product development for nearly a decade. The Evidence: Following the 2022 acquisition, extensive engineering reviews and public developer debates revealed a system held together by fragile, legacy code layers. The Debt Story: In its early days, Twitter was built on a fragile Ruby on Rails setup that frequently crashed (the famous "Fail Whale"). To fix this, they rushed a migration to a complex microservices architecture. Over the years, they layered thousands of obscure internal services on top of one another. The Collapse: The tech debt became so deep that changing the character limit or adding an edit button took teams of engineers years to safely execute. Entire clusters of servers were running code that no active employee understood, requiring a brutal, chaotic teardown of the infrastructure just to make the platform nimble again. The sheer scale of the mess Elon Musk uncovered at Twitter in late 2022 was precisely why he, along with several remaining engineers, spent weeks sleeping on the office floor at Twitter HQ. The "Scream Test" Method of Paying Debt In engineering, there is a reckless concept known as the "Scream Test" - you turn off a server, and if nobody screams, you leave it off. Musk essentially applied this to Twitter's architecture at a massive scale. #startups #techdebt #blitzscaling

SaaS Failures and Successes🧵4/10 The 2026 "Saaspocalypse" (The Ultimate Multi-Tenant Reckoning) The Debt Type: Deliberate Code Generation & "Vibe Coding" Debt. The Current Reality: Look at what is happening to the public markets right now. In early 2026, software stocks suffered a massive $1 trillion market cap sell-off, an event Wall Street has dubbed the "Saaspocalypse." The Knowing Debt: For years, legacy B2B SaaS platforms intentionally ignored complex UX sprawl, rigid per-seat licensing models, and fragmented internal databases. They knew their products were bloated and that users hated managing hundreds of applications that didn't talk to each other. They chose not to fix it because enterprise lock-in guaranteed recurring revenue. The Flaw: Now, AI agents can bypass these massive, bloated SaaS UIs entirely. New AI-native startups are building highly consolidated platforms at a fraction of the cost, using code generation to bypass years of manual engineering. The legacy SaaS giants are trapped by their own historical architecture-they cannot pivot their codebases fast enough to inject native, low-cost AI agents because their underlying data silos are too rigid. #startups #techdebt #blitzscaling

SaaS Failures and Successes🧵3/10 Friendster (The SaaS Social Network That Tech Debt Erased) The Debt Type: Deliberate Scaling & Database Architecture Debt. The Story: Before MySpace or Facebook, Friendster was the dominant social network, raising millions and amassing tens of millions of users in the early 2000s. The Knowing Debt: Friendster’s core value proposition was showing how you were connected to others via "degrees of separation" (e.g., a friend of a friend). Calculating these relationships required traversing massive social graphs. As the user base exploded, the engineering team knew their database structure couldn't compute these graphs dynamically in real time. The Flaw: Instead of pausing feature growth to entirely re-architect the graph database, management pushed for more user acquisition to satisfy investors. The debt caught up with them: pages began taking 20 to 40 seconds to load. Users would click a profile, watch a blank screen, and log off. A young Mark Zuckerberg noticed this, built Facebook with a vastly simpler, cached data structure that loaded instantly, and Friendster bled its entire user base to Facebook purely because its technical debt made the platform unusable. #startups #techdebt #blitzscaling

SaaS Failures and Successes🧵2/10 Knight Capital Group (Algorithmic Trading SaaS) The Status: Bad. A textbook case of permanent tech debt resulting in total company liquidation. The Evidence: The SEC's official investigation report details how a piece of forgotten, dead code destroyed a multi-million-dollar financial firm in exactly 45 minutes. The Debt Story: Knight Capital used a legacy server configuration pattern. In 2012, they deployed new trading software but left a piece of dead, obsolete code inside the system from years prior. Crucially, they reused a specific software flag (a configuration setting) that used to activate the dead code. The Collapse: When the new software turned on, it accidentally triggered the unmaintained, unmonitored dead code. The system began buying and selling millions of shares erratically. Because they had no modern logging or documentation, engineers frantically tried to debug the system live, accidentally making it worse. The company lost $440 million in less than an hour and went bankrupt. #startups #techdebt #blitzscaling

SaaS Failures and Successes🧵1/10 Southwest Airlines (The 2022 Complete Operational Meltdown) The Debt Type: Deliberate Infrastructure & Process Debt. The Story: In December 2022, a winter storm grounded flights across the US. While other airlines recovered in 24-48 hours, Southwest completely collapsed for over a week, cancelling 16,700 flights and losing over $800 million in days. The Knowing Debt: This was not a surprise bug. Southwest’s pilots' and flight attendants' unions had been explicitly warning executive management for years that their scheduling software, called SkySolver, was completely obsolete. The Flaw: Management intentionally chose not to upgrade the system because it would require halting operations and massive capital expenditure. SkySolver could handle normal point-to-point operations, but when a massive disruption occurred, it had no automated capability to match displaced crews with stranded planes. Crew schedulers literally had to use paper, pens, and manual telephones to locate thousands of workers. Management actively chose the short-term savings of delaying the upgrade, resulting in a systemic failure that permanently damaged their brand. #startups #techdebt #blitzscaling

Hey @Adobe @AdobeSupport could you please give me a hand troubleshooting my Mum/Moms Mac? She's switched on & hasn't done anything to cause this. I believe its from an update, its a Mac Airbook a few years old. Should I recommend the Creative Cleaner Tool? CC @AppleSupport

@claudeai whats happening, the service is down...

@JamesNK Before jeremythompson.net/rocks/CompactJ… & after jeremythompson.net/rocks/CompactJ… 2/2

@JamesNK @JamesNK I was thinking about why we're not taught to use legends to save on space. I tested it out and there's no point with small json files, but larger json files with lists you can get a 10% saving on files as little as 11KB, the savings grow the larger the file. /1

@Ishkur23 Hi, I'd like to get in contact with you. Is it possible DM you?

The socials are telling me Pete Rose is dead, but I wouldn't bet on it.

@ErikEJ @jbogard @rest Seeing that old Server XML reference makes me shudder.

@jbogard EXEC sp_OACreate 'MSXML2.ServerXMLHTTP', @REST OUT;

Oh my god