6 MIN READ
The hobbyist project that becomes the production system is one of the more reliable patterns in technology, and the conditions that produce it are getting more common, not less. Someone has a problem on a Friday afternoon, writes a script, shares it with a couple of colleagues, forgets about it, and discovers two years later that the script is running a non trivial slice of the business. The same shape is showing up in companies that would never have approved the script as a production tool. It is also showing up in the open source world, where a single maintainer ends up quietly carrying a library that thousands of projects depend on.
The pattern is so reliable because the conditions that produce it are so reliable. The official procurement process is slow, the approved vendor is expensive, and the software that gets approved is often the wrong shape for the actual problem. The developer does not have time to wait for a procurement cycle and does not have a budget for a vendor. They have an evening, a real problem, and a team that is waiting. So they ship the script, and the script lives.
What the pattern looks like in 2026
The pattern shows up in every company that runs internal tools. A script gets written to solve a single problem, then shared, then extended, then documented, then given a name, then handed a repository. At some point the operations team starts depending on it, the on-call rotation starts including it, and nobody remembers to ask whether the thing was ever reviewed. Procurement never saw it. Security never saw it. Legal never saw it. The thing works, and that is the only review it has ever had.
The same shape shows up at a different scale in the major open source projects. The maintainer of a popular Python library is, more often than not, someone who wrote the library to solve their own problem, shared it, kept maintaining it, and ended up with a project that tens of thousands of other projects depend on. In most cases they are not getting paid for the work, and the company that depends on the library has not offered support. The maintainer is going to burn out eventually, and the projects that depend on the library are going to find out, all at once, what life looks like without them.
What the company should do when the hobbyist project amounts to the production system
Most companies already know the answer. Acknowledge the reality, give the project the operational work it needs, and accept that the project is not going to look like the other production systems. The acknowledgement starts with a conversation: engineering manager, security, compliance, whoever owns the audit. Most hobbyist projects that have become production systems are not on any of those lists, and the only way to fix that is to put them on the lists.
Then fund the ops work. The hobbyist project that has become the production system needs the same things the other production systems need, and the author usually did not have time to do any of it. On-call rotation, monitoring, backups, documentation, test coverage, and a security review, all of it. The company can pay for that, and the company should, because the alternative is the project staying in the same shape it has always been in, which is one person working evenings and hoping nothing breaks.
And accept that the project is going to be the odd one out. Different architecture, different deployment model, different test coverage, possibly a different language. Auditors will ask about it. The right answer to the auditor is to point at the support the company has put around the project, not to pretend the project is something it is not.
What the company should not do
Do not pretend the project does not exist. A production system that is not on any inventory is a production system that does not get backed up, does not get tested, and does not get a security review. It is also the production system that is going to be the source of the next breach, and the production system the company is going to have to explain to a regulator, an insurer, or a customer.
Do not rewrite the project from scratch. The rewrite is going to take two years, miss the things the author knew about the problem, and ship without the features that made the original project useful. The rewrite also requires the author to hand over all the context in their head, which is going to take longer than the rewrite itself.
Do not blame the author. They solved a problem the company had not solved, shipped a solution the company would not have approved, and ended up being the most motivated person in the building to keep the thing running. The fault sits with the company that did not fund the solution when the solution was a hobby, and the company that is now on the hook for the production system the solution has become.
What the developer should do
If the project is yours, have the conversation with your manager. That conversation brings the project into the light, which is how it gets the support it needs. The conversation is not necessarily going to land you a promotion, and it is not necessarily going to land you a raise. What it does is get the project the support the project needs, which is the part you have not had time to handle yourself.
Set the boundary while you are at it. The boundary is the line between the work the project needs and the rest of your job, and the line keeps the project from eating all your time. Without the line, the project ends up consuming nights, weekends, and the rest of your career, and nobody else learns how it works. With the line, other people pick up the support, and the project survives you eventually leaving, or simply getting tired.
The bottom line
Acknowledge the project, fund the operational work, and stop pretending the rewrite is the answer. The way to keep the hobbyist project alive is to treat the author like a real engineer with a real budget, not like someone who happened to solve a problem on a Friday night. The production system the company depends on, after all, was somebody’s hobby, and treating that as a curiosity instead of an asset is how the company ends up losing the person, the code, and the support along with it.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
