Why I Finally Stopped Shipping Code and Started Owning Problems

Last year, I handed off a major feature to a client and considered it "done." The code was merged, tests passed, deployment went smooth. Three weeks later, they called me at 2 AM because the feature was creating duplicate records under specific network conditions. I'd shipped code. I hadn't owned the software.

That conversation haunts me because I see it happening everywhere, developers treating delivery as the finish line when it's actually the starting gun. We optimize for sprint velocity, celebrate deployments, and disappear into the next project while customers struggle with something we technically built correctly. The problem isn't our code quality. It's our frame of reference.

Reading this article about enterprise software ownership made me realize I've been measuring success all wrong. It's not about beautiful architecture or zero bugs. It's about whether the system actually solves the business problem it was supposed to solve.

The Difference Between Shipping and Owning

Here's what stuck with me: the Northstar Logistics case study doesn't start with technology decisions. It starts with a question: "What decision becomes possible today that isn't possible tomorrow?"

That's the opposite of how most projects I've worked on begin. We usually start with "we need a dashboard" or "we need an API" and work backward from there. This approach starts with outcome, then asks if technology even helps.

The reason this matters is practical. I once spent eight weeks building a real-time sync system for a platform because someone said "we need live updates." When we shipped it, users preferred the simpler batch update we had before. We'd optimized for the solution, not the problem.

The Phase Zero That Changes Everything

This article proposes something radical: discovery as a negotiated, compensated phase with an exit option. Not a free sales call. Not a spec written in isolation. An actual investigation where engineers talk to users and systematically map where decisions break down.

I've done this exactly twice in my career, and both times it prevented disasters. Once, we discovered the "urgent" feature request was actually a data reporting problem that didn't need code at all. Another time, we found that the legacy system's interface complexity meant our "simpler" replacement needed three times more training.

The artifact list they recommend, assumptions register, baseline metrics, risk map, these aren't bureaucratic overhead. They're how you avoid building the wrong thing fast.

Scope Negotiation as a Technical Practice

The contract discussion in the article makes my architect brain happy. Phased engagement, capped pilot scope, explicit change control, exit rehearsals, these aren't just legal words. They're how you preserve the ability to make good technical decisions under uncertainty.

When everything is fixed price and fixed scope, you either compromise on quality or scope creep silently. The vendors I trust most are the ones who say, "We can fix the pilot. We can't responsibly fix the full integration before we inspect the interfaces." That's engineering integrity speaking.

I've learned this the hard way. I once took a fixed-price contract for infrastructure work at a company with a legacy system I'd never seen. Two weeks in, I discovered their database required three custom patches. Either I delivered late or delivered something fragile. Better to negotiate upfront.

Where I'd Push Back

I don't entirely agree with the "AI transcribes interviews, humans verify" model. I've seen this used as "AI does the work, we'll spot-check it" and that's how you miss context. For interviews with stakeholders, I want the human pattern-matching from day one, not post-hoc verification.

Also, this article focuses on contracts and handoff, but doesn't dig deep enough into the on-call transition. Who owns the pager when you hand over the system? What does "support" actually mean operationally? I've seen beautiful handovers fall apart because nobody defined severity levels or escalation paths.

What This Means for My Next Project

I'm changing how I approach enterprise work. Before the first architecture decision, I'm running a lightweight discovery phase with these artifacts: problem statement, current workflow map, baseline metrics, and a one-page risk register. No more writing specs based on requirement documents alone.

I'm also writing handoff contracts that include an "exit rehearsal"-actually rehearsing the client team taking over production support before we step back. Not theoretical. Actual.

What about you? How do you currently validate that the problem you're solving actually matters? And what would change if you talked to users before deciding on your tech stack?

Source: This post was inspired by "Enterprise Software in 2026: From First Conversation to Production Ownership" by Dev.to. Read the original article