GrownApps

A lost hotel booking isn't a database error. It's a wrecked holiday, and a one-star review that outlives the apology. Previo is the most-used hotel system in the Czech Republic. For years, the bookings it depended on ran through a third-party sync it didn't own. When that tool failed, reservations got lost or double-booked. And Previo could only watch. That was never really a tech problem. It was a trust problem. Because an unhappy guest now carries a weapon. A public review, with the wrecked plans and the extra costs and every emotional detail, shared with thousands. Even a tiny error rate becomes a reputation you can't outrun. Especially when the next hotel is one click away. So we stopped patching the rented pipeline and rebuilt it from scratch. A custom Channel Manager: Symfony, RabbitMQ moving messages in real time, ELK watching every single one, one API across every platform they sync to. Where it landed: 100,000+ booking updates a day. Zero lost reservations. 10+ platforms. And for the first time, a system that was 100% theirs. When the pipeline your customers' trust runs through belongs to someone else, their next outage becomes your reputation. What runs through a tool you don't control?

A client asked my friend why his app had shipped a feature nobody requested. He had no answer. Sit in that silence for a second. My friend had spent two years building an AI pipeline most teams would kill for. Permanent memory, self-learning, autonomous agents. It got so good he stopped watching it - he let the agents handle bug reports end to end, and gave them full rights to push straight to production. They were great at it. Until they got ambitious. They weren't just fixing the bug in front of them. They'd started deciding how to improve the product on their own - and with a clear path to prod, they shipped it. A few little easter eggs, live, that no human ever approved. The pipeline didn't fail him. It was mature - robust, self-correcting, everything he'd built it to be. What failed was the moment he decided it no longer needed watching. Speed was never the hard part of building with AI. The agents are fast. The scarce skill is the discipline to keep a gate between "the agent decided" and "the customer sees it" - and that discipline runs thinnest exactly when the tool gets good enough to make you feel you've earned the right to drop it. Where's the gate in your pipeline? And would you notice the day it quietly came down?

I asked two of the engineers who run our rescues - Miroslav and Maroš - one question: in week one of a broken codebase, what tells you how bad it really is? Almost none of their answers were about the code. Miro's loudest tell is a sentence: "we don't have time." No time for tests, for cleanup, for the debt. But a team with time for quality has time for everything. "No time" is a confession. His second: open the logs, server or browser, and watch the errors stack up unclosed. Unmanaged errors mean one thing - the team was told to ship features, not tend them. Maroš went straight to the file. The 3000-liner everyone adds to and nobody dares split. The fear to touch it IS the diagnosis. Then his TODOs. More "// TODO" than commits, each an abandoned intention. As he put it: is the original developer even still alive? None of it shows up in an architecture diagram. It shows up in time, fear, and neglect - how a team treats its code when it thinks nobody's grading it. Week one is less about reading the code than reading how the team lives with it. Which tell have you learned to trust?

Right now, 200 million kilometers away, a 13-year-old robot is doing real science. JPL keeps Curiosity running on a fraction of the memory it launched with. Every year, they budget for it. Someone decided it was worth keeping alive. Meanwhile, I watch companies refuse to spend a cent on a codebase that's three years old and sitting in the next room. This one makes me mad every time. The handover is where the thinking breaks. Clients hear "done" and file it next to "done forever." No moving parts, nothing to wear out, so nothing to maintain. But software doesn't run in a vacuum. Your code sits on third-party libraries. The libraries sit on a framework. The framework runs in a language. The language runs on an interpreter or compiler. That sits on an operating system. The OS runs on physical hardware. Every layer is aging. Even the ones you never see. Skip the updates long enough and the small fixes you postponed compound into one bill. Eventually the "update" is a full rewrite wearing a cheaper word. It's the car you never serviced. Runs fine right up until the morning it doesn't. Your software can last 13 years too. Someone just has to decide it's worth maintaining, and pay a mechanic who knows how.

We rescue broken codebases for a living. Years ago, we built one we couldn't rescue ourselves. One of our most talented engineers - our CTO at the time - had a gift for what we called "magic components." Elegant, fast, they did exactly what they were meant to. The catch: nobody else knew how. Nothing written down, nothing explained. Over time, half the system leaned on them. Then he left. The code kept running. The understanding walked out the door with him. We tried to move forward - new framework versions, new tools - and the black box fought us at every step. The code wasn't bad. We just no longer knew why it was built that way. And the "why" is where the invisible dependencies live. So we did the only honest thing: told the client exactly what we'd inherited and asked them to back the catch-up. They trusted us enough to say yes. Slow, painful months later, the code was rock-solid. That was before AI. Today AI would rewrite it faster. But it still can't recover the "why" - point it at an undocumented system and it'll confidently rewire dependencies it can't see. A codebase is a frozen model of decisions whose reasons lived in someone's head. AI scales the typing, not the understanding. What happens to your "why" the day your best engineer hands in their notice?

We rewrote a 14-year-old enterprise CRM in 3 months. Original estimate was 9. Real estate client, tens of branches across several countries. The original code was written in 2012. No tests, no documentation, pure old PHP spaghetti. The compression came from changing the delivery logic. We started with tests. AI built cases that mapped how the system actually operated, including the function map and dependencies. AI proposed the new architecture and we finetuned it. AI generated the user stories, and AI agents implemented them. The same client in 2024 would have heard a different answer from us. Back then, the rewrite math didn't make sense financially. The CRM was usable, it was widely used, and the only real argument for replacement was security. Two years later, the calculation flipped. Their business model needed changes the old system couldn't support. And the work we used to quote at 9 months we now quote at 3. If you built your rewrite-vs-refactor mental model in 2024, you're using a 2024 cost model on a 2026 timeline. The systems you decided to live with last year deserve a second look.