Building software: you can, but maybe you shouldn't

Absolutely. Most believe the hard part is creating the "finished product," but that's when the real headaches begin. The cost of keeping software alive often far exceeds its initial development. It's not a toy, it's a lifelong commitment.

Jenna Pederson, in her article 'You can build it. Should you?', highlights how initial enthusiasm for software creation often leads to underestimating long-term maintenance costs. She's spent a career helping teams understand code is a living thing, not a static artifact. This is a common mistake for many.

Imagine buying a sports car: the purchase price is one thing, but then there's gas, insurance, servicing, and repairs. Software works the same way. Those with brilliant ideas focus on launching, but forget they'll need to maintain it, and it's not a small task.

Ultimately, you do. Or your team, or your company. Software is never truly "finished"; it demands constant updates, bug fixes, and adaptations to new technologies. It's an endless cycle requiring resources, time, and dedicated people, not just a single developer.

Her multi-year experience shows that many software projects fail not because of code defects, but due to a lack of a support and update strategy. Pederson, through her writings, has often shown how companies underestimate post-launch support investment. The result? Abandoned software or products riddled with issues.

Think about it: if your software starts having problems and no one fixes them, your users will leave. It's not enough for it to work on day one. You need a clear plan for the future, for every system update or API change. Otherwise, you've just built a pretty sandcastle.