Guide · Project management
What It Takes to Run Software You Own
Look beyond the code purchase and plan for hosting, providers, maintenance, backups, and the person responsible for keeping the application useful.
Buying source code changes what you can control. It also gives you work that a hosted vendor would otherwise handle. Before choosing an application you will run yourself, make a realistic plan for who will operate it and what that work includes.
Name the operating owner
Someone needs to know where the application is hosted, which services it depends on, and who can change it. That person doesn't have to do every task personally. They do need to coordinate maintenance and make sure the relevant accounts remain accessible to the business.
If the answer is "the developer who sets it up," discuss what happens after setup. Will they maintain it? How will another person take over? What documentation and account access will be handed over? These questions belong in the plan before the app becomes important to daily work.
List the services the app uses
Start with the actual architecture. A web application might depend on hosting, a database, file storage, authentication, email, and outside APIs. Some products require fewer services; others require more. Use the installation instructions and your deployment configuration to build the list.
For each service, record who owns the account, what the app uses it for, and what drives its cost. Usage may depend on storage, requests, messages, or another measure. Review the current provider terms when you need a budget rather than treating a generic estimate as a quote for your implementation.
Budget for the work around the invoice
Installation is only one part of ownership. Someone has to handle updates, troubleshoot failures, review permissions, and maintain custom changes. A team with an established technical owner will approach that work differently from a business hiring help each time something changes.
Use a simple planning exercise: list a normal month, an update month, and a month with an incident. For each, describe the work you'd expect someone to perform. The exercise can reveal missing responsibilities even before you assign hours or money to them.
Also account for your own team's attention. A recurring manual check can be perfectly reasonable if it is small and assigned. It becomes a problem when everyone assumes someone else is doing it.
Practice recovery before depending on it
Know what is backed up and how you would restore it. A copy of the code is not a backup of the live database or uploaded files. Provider recovery options, export formats, and retention settings vary, so check the services you're actually using.
Try a recovery exercise in a safe environment. Record what was restored, what remained missing, and what access the operator needed. The useful evidence is a result you inspected, not just a setting that says backups are enabled.
Decide whether the control is worth the responsibility
Ownership can be a good fit when the workflow needs meaningful customization and someone is prepared to maintain it. A managed product can be a better fit when the standard behavior is sufficient and the team wants the vendor to run it.
Compare those choices using the work your business needs, the changes you expect to make, and your operating capacity. A source-code purchase is easier to evaluate when the maintenance plan is as concrete as the feature list.