No Split

The industry pretends there's a clean line between "building new features" and "maintaining existing software." There isn't.

What Actually Happens

The developer builds a feature. Deploys it. Users start using it. They hit edge cases nobody anticipated. The developer fixes those. The client asks for small improvements. Those get added. Performance degrades at scale. The developer optimizes. Meanwhile the next feature is being built, which connects to the first one, which requires changing how the first one works, which surfaces assumptions buried in the original implementation.

Is that "building" or "maintaining"? Both. Simultaneously.

The False Distinction

The classic split looks clean on paper: a development team builds new things, a maintenance team fixes what's broken. Different teams, different skills, clean handoffs.

What actually happens is information loss. The development team never sees how their features perform in production. The maintenance team doesn't understand the original design intent. Quality suffers. Velocity suffers. Context gets destroyed at every handoff.

No Handoffs, No Lost Context

When one person builds the feature, deploys it, watches it in production, fixes the issues, optimizes the slow parts, and integrates the next thing — there's nothing to hand off. No phase transitions. No "that's not my problem, I'm on the build team." Just continuous work on running software, informed by how it's actually being used.

That's the whole model. It's simpler and it's more honest.

Maintenance Is Development

Fixing a bug is development. Understanding why users hit an error, tracing the root cause, writing a fix, deploying it safely. That's software development.

Optimizing performance is development. Profiling the application, finding the bottleneck, refactoring for efficiency, measuring the result. That's software development.

Call it whatever. The work is the same. The skills are the same. The only thing that changes is the label people put on the ticket.