Just Because You Can Build It Doesn't Mean You Should
The overlooked economics of homegrown enterprise software
Years ago, I had a conversation with an assistant vice president at a major bank about some software tools his team had developed internally. He explained that he occasionally allowed his engineers to work on these projects as a reward for performing well in their regular jobs.
I remember being struck by that. Not because I objected to encouraging technical curiosity or rewarding good employees. I've spent enough years around talented engineers to appreciate that some of the best ideas emerge when people have the freedom to experiment. What surprised me was that he was describing software development as an employee incentive rather than a business investment.
Some of those projects could eventually become part of the bank's operational infrastructure, bringing responsibilities for maintenance, security, and support. Yet the decisions to undertake them weren't necessarily being made with those obligations in mind.
Organizations sometimes become software companies without ever making a conscious decision to do so.
The accidental software company
Enterprise IT departments are full of clever people solving real problems. A network engineer writes a script to collect device configurations. Someone else develops a tool to compare changes. Another builds a dashboard or integrates the results into a ticketing system. Each project solves a legitimate problem, and over time the scripts become interconnected, new features are added, and other teams begin relying on them. What started as a handful of utilities gradually becomes an internal platform.
And it may be a very good one. Properly engineered internal platforms can be exceptionally capable, particularly when developed by people who understand their organization's requirements intimately. But whether the software works well isn't the only consideration. At some point, the organization has assumed responsibility for developing and maintaining an application, whether anyone formally made that decision or not.
I've encountered environments running on collections of scripts accumulated over decades, occasionally written by summer students or engineers who departed years earlier. As long as everything works, the arrangement can seem economical. Then a vendor changes its operating system, a dependency develops a vulnerability, or an authentication mechanism is deprecated. Suddenly, an application nobody remembers commissioning requires attention from people who may not understand how it was constructed.
The responsibilities of owning software exist whether or not an organization formally acknowledges them.
Free like a puppy
There's an expression I've always liked: free like a puppy. The puppy itself might cost nothing to acquire. Feeding it, training it, keeping it healthy, and looking after it for the rest of its life are another matter.
Software isn't much different. Open-source frameworks and automation tools make it possible to build sophisticated applications without conventional licensing fees. But software requires maintenance, security, testing, documentation, and updates. Its dependencies change, operating environments evolve, and new requirements emerge.
These are normal responsibilities for a software company. The question is whether a manufacturer, mining company, or energy producer should necessarily assume them.
Commercial software costs are highly visible, while internal development and maintenance costs often aren't. A subscription appears as an identifiable expense, whereas engineering hours devoted to an internal application are absorbed into salaries and operational budgets.
According to the U.S. Bureau of Labor Statistics, the median annual salary for an American software developer was $135,980 in May 2025. Three developers earning that amount represent more than $400,000 in annual salaries before benefits, payroll costs, and other overhead. Even allocating a portion of that capacity to maintaining internal applications represents a meaningful investment, whether or not anyone has assigned it a project budget.
And an accurate calculation of those costs may still overlook the largest expense of all.
The opportunity cost nobody measures
Imagine a manufacturer assigning three experienced engineers to develop and maintain an internal network management platform. Let's assume they do an excellent job. The application meets its requirements, works reliably, and costs less in direct expenditures than a commercial alternative.
Has the company made a sound investment? Perhaps, but what else might those engineers have accomplished? Could they have reduced production downtime, improved operational resilience, strengthened cybersecurity, or integrated manufacturing systems more effectively?
Every organization has finite engineering capacity and more opportunities for improvement than it can pursue. Choosing one project means deferring another, yet that trade-off rarely appears in the internal development business case. There's also a seductive accounting illusion: the engineers are already employed, their salaries are budgeted, and consequently their time can appear available at little or no incremental cost. In reality, an hour consumed by one activity is unavailable for another.
The question isn't simply whether an organization can build something more cheaply. It's whether building it represents the best use of the resources available.
For businesses outside the technology industry, that distinction is particularly important. A packaged goods company exists to produce and distribute consumer products. A mining company extracts and processes resources. An energy company produces and delivers energy. All require sophisticated infrastructure, but there's a difference between technology that is mission-critical and technology that is strategically differentiating.
A proprietary system that improves manufacturing yields or optimizes energy production might provide a competitive advantage. Developing another application to collect and archive router configurations is a harder investment to justify on those grounds.
When the people who built it are gone
The technology workforce is undergoing a generational transition, with implications extending well beyond recruitment and succession planning.
Those of us who've spent several decades in enterprise networking have watched the industry evolve from relatively isolated systems into the foundation upon which virtually every modern organization operates. We've watched generations of engineers develop the tools needed to manage those environments, and increasingly, we're watching those engineers retire.
The Alliance for Lifetime Income's Peak 65 research estimates that more than 4.1 million Americans will turn 65 annually through 2027, roughly 11,200 people reaching traditional retirement age every day. Not everyone retires at 65, of course, but the scale of the demographic transition is substantial.
Meanwhile, the Bureau of Labor Statistics projects employment among network and computer systems administrators will decline 4% between 2025 and 2035. Despite that contraction, it anticipates approximately 13,400 openings annually as existing workers change occupations or leave the workforce, including through retirement. Over the same period, software developer employment is projected to grow 10%.
These projections don't mean networking is disappearing or that younger engineers have lost interest in the profession. Traditional networking responsibilities are increasingly automated or incorporated into cloud engineering, DevOps, and other disciplines. But they illustrate how workforce requirements are evolving, and why organizations should be cautious about assuming today's expertise will remain equally accessible a decade from now.
Consider an internal application developed over fifteen years by several generations of engineers. It might be reliable and exceptionally well adapted to the organization. But how much of its continued operation depends on knowledge residing primarily in the heads of two or three people? Does anyone understand why certain architectural decisions were made, or the peculiarities of its integrations? What happens when the person who knows the answers retires?
I ask these questions as someone who's been in networking long enough to qualify as one of the greybeards. Finding someone who can write Python is one thing. Finding someone who understands your infrastructure, business requirements, and fifteen years of undocumented decisions embedded in a proprietary application is quite another.
When you build your own software, you're betting not just on your ability to develop it, but on your ability to retain or replace the expertise required to sustain it.
That's a business continuity risk, and it belongs in the investment decision.
AI makes building easier. Ownership is still a commitment.
AI-assisted development tools have dramatically reduced the time required to produce working software, sometimes compressing days or weeks into hours. Organizations should take advantage of those capabilities, but as the barriers to software creation fall, the temptation to build rather than buy becomes stronger.
Why purchase an application when an engineer can ask an AI assistant to create something similar? It's attractive, particularly when the initial demonstration looks impressive. But producing working code isn't the same as operating a dependable production system. Requirements still need defining, functionality validating, changes testing, dependencies monitoring, and security managing. AI can assist with these activities, but the organization remains accountable for the results.
And AI itself introduces costs that aren't necessarily predictable. According to Stanford University's 2025 AI Index, the cost of running AI models at a defined level of performance fell more than 280-fold between November 2022 and October 2024. That's an extraordinary improvement, but cheaper computation doesn't necessarily translate into predictable expenditure. Model selection, task complexity, context requirements, and increasingly autonomous workflows all influence actual consumption.
The industry's commercial models are evolving accordingly. In August 2025, AI coding platform Cursor explained its move toward usage-based pricing, observing that a complex agentic task could consume an order of magnitude more tokens than a simple request. More recently, Reuters reported that Uber exhausted its annual AI budget in just four months as internal adoption accelerated.
AI providers are balancing substantial infrastructure and development investments against changing consumption patterns, competitive pressures, and the need for sustainable margins. These aren't arguments against AI. They're reasons to measure its productivity gains against actual costs rather than assume that today's pricing will remain constant.
I suspect AI will also accelerate the growth of accidental software companies. Where organizations once accumulated internal tools over decades, they can now develop substantial portfolios of applications in a fraction of that time. Software creation can easily outpace an organization's ability to govern what it creates.
The generational transition compounds this concern. A senior engineer can now use AI to develop sophisticated tools remarkably quickly. But when that engineer retires, the code remains while much of the operational context that informed it may leave with them. AI can help document and maintain those systems, but it cannot automatically reconstruct every undocumented assumption or decision.
The easier software becomes to create, the more important it becomes to ask who will inherit it.
Build what differentiates you
For decades, businesses have wrestled with which capabilities to develop internally and which to obtain from specialized suppliers. Concentrating resources on core competencies isn't a new idea, and neither are the risks of getting those decisions wrong. Outsourcing the wrong activities can introduce dependencies, erode institutional knowledge, and compromise operational flexibility.
But the underlying economic logic remains sound: organizations should concentrate scarce resources where those investments create the greatest value.
That doesn't mean discouraging experimentation or abandoning internal development. Giving engineers opportunities to explore ideas is good management. A successful prototype, however, demonstrates that something can be built, not necessarily that the organization should operate it indefinitely. There's a point where experimentation becomes an ongoing business commitment, and that transition deserves an explicit decision.
Nor does it mean surrendering control of critical infrastructure. A logistics company developing proprietary optimization software may be investing directly in its competitive advantage. An energy producer developing specialized automation to improve plant performance may be doing precisely the right thing. In both cases, the investment supports capabilities that distinguish the organization from competitors.
Commercial products and internal engineering aren't mutually exclusive. Open-source tools, established platforms, and internally developed applications can complement one another. An organization can purchase mature capabilities while directing engineering talent toward the integrations, workflows, and innovations unique to its business.
Commercial software brings costs and risks of its own, including vendor dependence. Purchasing a product doesn't eliminate management responsibility, but a specialized supplier can distribute development, testing, maintenance, and technical expertise across a broader customer base. An enterprise developing comparable capabilities internally must justify bearing those costs largely on its own.
Build the technology that makes your business better than your competitors. Be selective about building the technology that merely makes your business function.
A question of management discipline
Ultimately, this isn't about Python, Ansible, open source, or any particular commercial product. It's about management discipline and the deliberate allocation of resources.
Organizations have finite capital, finite engineering capacity, and increasingly complex demands upon both. They're managing aging infrastructure, evolving security requirements, a changing workforce, and technologies that make software easier to create without necessarily making it easier to operate.
Against that backdrop, internal development deserves the same scrutiny as other business investments. Why are we building this? What advantage does it deliver? What will it cost to sustain? Who will own it five years from now? And what valuable work are we choosing not to do?
These questions don't diminish the accomplishments of engineers who develop internal solutions. They recognize that engineering talent is valuable enough to warrant deliberate investment.
For organizations whose primary business is manufacturing, energy, resources, transportation, or consumer goods, that distinction is particularly important. Their technology teams have an essential role in making the business more productive, resilient, and competitive. But they don't necessarily need to become software vendors to accomplish it.
The most valuable contribution an IT organization can make isn't always another piece of software. Sometimes it's recognizing that its engineers have more important things to do.
Final Takeaway
With LogicVein, you don’t just react to changes — you control them.
Watch our series of videos here or see all our features here.
With its combination of discovery, monitoring, compliance, and automation, LogicVein transforms how IT teams manage complex network environments.
Whether you’re looking to reduce manual work, improve network reliability, or gain better visibility into device configurations, LogicVein will provide you with the tools you need—all in a single platform.
Ready to see LogicVein in action? Request a Demo and discover how you can simplify operations, improve reliability, and gain full network visibility.
