The hobbyist project that becomes the production system is one of the more reliable patterns in technology, and the pattern is going to keep repeating in 2026 because the conditions that produce it are getting more common. A developer has a problem. The developer writes a script to solve the problem. The script gets shared with a few colleagues. The colleagues tell their colleagues. The script gets a name, gets a repository, gets a contributor or two. Two years later the script becomes the production system for a non trivial fraction of the company.
The pattern is reliable because the conditions are reliable. The official procurement is slow. The approved vendor is expensive. The approved vendor produces software that does not actually solve the problem. The developer solves the problem because the developer has to, and the developer ships the solution because the developer stands as the one who is on the hook when the production system does not work.
What the pattern looks like in 2026
The pattern shows up in every company that runs internal tools. The internal tool was a script, the script was shared, the script was extended, the script was documented, the script was given a name, and the script is now the system the operations team depends on. The internal tool was not built with a procurement review, with a security review, with a legal review, with a documentation review, with a test coverage review. The internal tool was built by a developer who was trying to solve a problem, and the developer solved the problem, and the internal tool stands as the production system whether the company wants to admit it or not.
The pattern shows up at a different scale at the major open source projects. The maintainer of a popular Python library is, more often than not, a developer who wrote the library to solve a problem, shared the library, kept maintaining the library, and ended up with a project that is depended on by tens of thousands of other projects. The maintainer is not getting paid for the maintenance (in most cases), the maintainer is not getting any support from the company that depends on the library, and the maintainer is going to burn out at some point in the next few years. The pattern sits as the same at every scale: a developer solves a problem, the developer’s solution gets adopted, the solution becomes critical, the solution is not funded.
What the company should do when the hobbyist project amounts to the production system
The answer in most companies is to acknowledge the reality, to give the project the operational support it needs, and to accept that the project is not going to look like the other production systems. The project was not built like the other production systems, and the project is not going to be maintained like the other production systems. The project is going to be maintained the way the original developer maintains the project, which is to say, with the developer’s nights and weekends, until the developer burns out or leaves.
The first step is to acknowledge the project exists. The acknowledgement runs as the conversation between the engineering manager and the developer, the engineering manager and the security team, the engineering manager and the compliance team. The conversation stands as the conversation that brings the project into the light, and the conversation amounts to the conversation that lets the project get the support it needs.
The second step is to give the project the operational support. The operational support counts as the on call rotation, the monitoring, the backup, the documentation, the test coverage, the security review. The operational support is what the production system needs, and the operational support is what the developer has not had the time to do. The company can pay for the operational support, and the company should, because the project becomes the production system.
The third step is to accept that the project is not going to look like the other production systems. The project is going to have a different architecture, a different deployment model, a different test coverage. The project is going to be the production system that is different from the rest, and the project is going to be the production system that the auditors are going to ask about, and the project is going to be the production system that the auditors are going to have to accept because the project sits as the production system the company depends on.
What the company should not do
The company should not pretend the project does not exist. The project counts as the production system, and pretending the project is not the production system is going to end with the project being the production system that the company cannot talk about, and the production system that the company cannot support, and the production system that is going to be the source of the next breach.
The company should not rewrite the project from scratch. The rewrite stands as the project that is going to take two years, and the rewrite stands as the project that is going to miss the things the original developer knew about the problem, and the rewrite serves as the project that is going to ship without the features that made the original project useful. The rewrite amounts to the wrong answer for the hobbyist project that has become the production system, and the rewrite amounts to the wrong answer for the hobbyist project that runs as the production system the company depends on.
The company should not blame the developer. The developer becomes the person who solved the problem, and the developer counts as the person who shipped the solution, and the developer stands as the person who is going to be the most motivated to keep the solution working. The developer is not the problem. The developer amounts to the solution. The problem serves as the company that did not fund the solution when the solution was the hobby, and the company becomes the one that is now on the hook for the production system that the solution has become.
What the developer should do
If you are the developer whose hobby project has become the production system, the right move is to have the conversation with your manager. The conversation amounts to the conversation that brings the project into the light, and the conversation runs as the conversation that gets you the support you need. The conversation is not the conversation that gets you a promotion (necessarily), and the conversation is not the conversation that gets you a raise (necessarily), and the conversation runs as the conversation that gets the project the operational support the project needs.
The right move is also to set the boundary. The boundary stands as the line between the work the project needs and the work the rest of your job needs. The boundary runs as the line that keeps the project from consuming all your time. The boundary runs as the line that lets the project get the operational support it needs without you being the only person who maintains the project. The boundary stands as the work, and the company should be helping you set it.
The bottom line
The patterns the post covers have been showing up in production for long enough that the patterns have names, the failures, the mitigations, the gaps. The work the security team and the engineering team and the operations team are quietly doing today sits as the work that decides whether the practice the post names sits as a tool the team uses or a liability the team is paying for.
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.
