Who Owns the Accounts Behind Your Custom Software?

Imagine an independent consultancy handling this situation. A consultant wants to change developers but discovers the hosting and domain accounts are held under the previous developer's personal identity.

For an independent consultancy, the situation is illustrative rather than a customer case study. Its value lies in exposing a small operational gap: information exists, yet the person acting on it cannot safely assume it means what they expect. The question is whether a small change could make this situation easier to manage.

Operational ownership was never distinguished from the supplier's development work. Essential services depend on access the business does not control.

Account control affects continuity even when development goes well. The business needs an agreed practical route to operate services and appoint support without depending on one person.

The handover should identify who can administer each service and how another authorised maintainer can be appointed. Ownership discussions also need to distinguish accounts, data and contractual rights. Those questions are easier to resolve explicitly than during an urgent change of supplier. The problem can persist without anyone making an obvious mistake. People follow the available information, but that information does not express the full business situation. Adding reminders would only make the same ambiguous record reach people more often.

Agree ownership and authorised administration for domains, hosting, repositories and service accounts. Document handover and support responsibilities before delivery.

The current applications may support more of the requirement than the initial proposal suggests. Include the correction and support process in the evaluation, not just a successful demonstration. Compare the existing process with configuration, integration and custom options only where they address the same need. Give the business a clear way to review important decisions rather than relying on technical terminology alone. A practical written agreement about the outcome can prevent a technically complete project from remaining operationally unclear. Make assumptions, exclusions and ongoing responsibilities explicit before committing to a solution. Base the decision on a real workflow and the people who will operate it.

Contract terms and intellectual-property questions need appropriate legal advice rather than assumptions about payment alone.

For background relevant to software account ownership, see Custom Software vs Off-the-Shelf Software: Which Is Right for Your Business. The issue here is the narrower workflow described in this example.

Ask whether an authorised business representative could obtain access and appoint a replacement maintainer using the agreed process. Ask a second employee to follow the proposed process without relying on the person who designed it. Use realistic examples and note where they need clarification. Those moments help identify missing instructions, unclear labels or business decisions that the design has not yet expressed.

For software account ownership, review the proposed outcome with the staff responsible. Record the assumptions and responsibilities exposed by the example before comparing options. The proposed arrangement should include a workable response to corrections and exceptions, so the business can judge the complete operating commitment rather than a successful demonstration alone. Give unresolved cases a named owner and a sensible review point. A clearer process in the current tools may be sufficient; custom development needs a specific remaining problem to justify it.

Software Logic helps businesses investigate software and process decisions with an emphasis on clear requirements, sensible use of existing applications and manageable changes. Could your business continue operating if you needed a different developer next month?