What to keep in your company’s name, what access a software team needs and why, how third-party systems fit in, and what should happen when an engagement ends.
In short
Your company should. We keep the repository, cloud accounts, domains, important services and data under your company’s control, and the code we write for you is yours once it is paid for. We work through access you grant, and remove or hand on access when the work ends.
Ownership rarely comes up while things are going well. It comes up when a relationship ends badly and a business discovers that its own website, app or database sits in someone else’s account.
It is much easier to settle before anything goes wrong.
Whoever controls the accounts controls your options. If the code sits in a vendor’s repository, you cannot hand it to another team. If the domain is registered in someone else’s name, your email and website depend on them. If the cloud account belongs to the vendor, so does the bill, and the data.
None of this requires bad intent. It often happens because setting things up under the vendor’s accounts was quicker at the start. The fix is simple: decide at the beginning that the accounts are yours.
As a rule, anything your business could not operate without should be registered to your company:
We work the same way. Code lives in a repository your company owns, and cloud, domains, important accounts and data stay under your company’s control. The code we write for you is yours once it is paid for; tools we reuse across clients stay ours.
A team needs enough access to understand the system and change it safely. Not more, and not less.
We ask only for the access the work needs, and we keep passwords and keys for the live system to the people who need them. Changes are reviewed before release, on a test system wherever the setup allows one.
If access is missing, we say what can and cannot be concluded without it, before proposing work. Guessing about a system we cannot see is how surprises happen.
Most business systems depend on other services and sometimes on other vendors. We can coordinate with an existing vendor or your IT team when the roles are agreed, while your company keeps the commercial and access relationships.
Third-party fees, infrastructure costs and other vendors’ work are not part of our price unless the agreement includes them. It is worth listing these early, so nobody is surprised by who pays for what.
A good handover leaves you able to understand your own system and decide what happens next, with or without us. At the end of agreed work, we:
You can read more on our trust and ownership page. If you are not sure who controls your current system today, that is a good first thing to find out. The article on taking over software from another vendor covers how to check.
Founder and Managing Director, Antdragon
Rosaan started Antdragon in 2020 to be the team that stays accountable once software goes live, and works with business owners on the systems they rely on every day.
Filed under Ownership and access
Most businesses only fully understand what they need once people start using the software. Why that happens, and how the way you pay for development makes it easier or harder to handle.
Rosaan Ramasamy · · 5 min read
A worksheet for the records, owners, access, errors, reconciliation and real-world tests behind a business system integration.
Rosaan Ramasamy · · 2 min read
A copyable brief that helps a software team understand users, workflows, priorities, constraints, dependencies and how you will accept the work.
Rosaan Ramasamy · · 2 min read
