A week goes by without a reply. You open your laptop to check what's actually been built, and you find you have a login to nothing — not the repository, not the server, not the account the app was published from. The question of who owns your code was answered months ago, in a setup meeting you weren't part of.
The contract said the work was yours. Nobody mentioned that owning something and being able to reach it are two separate problems.
Ownership is a list, not a feeling
Founders talk about ownership as one thing. It isn't. It's five or six accounts, each of which is either in your name or isn't:
The repository. Whose organisation is it under? And are you listed as an owner, or as a collaborator someone can remove?
The domain and DNS. Very often registered inside the agency's registrar account, because that took four minutes instead of a call with the client.
The servers and the database. Whose cloud account, and whose card is paying for it.
The store accounts. This one catches Gulf founders constantly. If the app was published from the agency's Apple Developer and Google Play accounts, the listing, the reviews, and the users belong to a company that isn't yours. Moving an app between developer accounts is possible. Doing it without the other side's cooperation is not.
The keys. Payment gateway, SMS provider, maps, identity verification. Each one is an account with an owner.
Go down that list and mark each item honestly. Whatever you can't log into today, you don't have.
Who owns your code is not the same question as who can reach it
Most contracts handle this with an intellectual property clause. The code is assigned to the client on final payment. Founders read that sentence and stop worrying.
It's worth understanding what that clause actually buys you. It gives you a legal claim. It does not give you a password.
If the other side stops responding, the clause is not a recovery plan. It's the paperwork you hand to a lawyer.
And then you're pursuing a company that may have three employees, may have moved jurisdictions, and may not exist by the time anything is filed. Meanwhile the product isn't shipping, and the runway is still burning. Legal ownership without access isn't a product. It's a lawsuit with your product inside it.
It usually isn't sabotage — until it's leverage
On day one, someone needs to register a domain and get things moving. Doing it inside the agency's existing accounts is faster than waiting on a client who doesn't have a registrar login yet. Most of the time, nobody thinks about what happens if the relationship ends.
One client found out what happens. He came to AppWorx to rebuild a project from scratch — the prior agency's work didn't function, full stop. But the domain was registered under the old agency's account, not his, and it had years of his company's live business email running through it. Losing it wasn't losing a website. It was losing every email address his business used.
The old agency wouldn't release it without being paid in full for the broken work. Not a transfer fee — the full project price, priced against what the domain was worth to him, not against what the work was worth.
He tried to make the numbers work by asking us to reuse pieces of what already existed — cut our price, keep some of the old build, save enough on one side to cover paying off the other. We looked at what existed and said no. It didn't match his actual requirements, the design patterns underneath were wrong for the problem, and the file structure read like someone learning the stack as they went. Reusing it wasn't a discount — it was inheriting someone else's mistakes at a discount.
He ended up paying the old agency in full, for work that still didn't function, to get back a domain with his own company's email running through it.
The part nobody asks for
There's a sixth item that doesn't live in any account: why things were built the way they were.
Which payment provider was chosen and what got rejected. Why the database is shaped the way it is. What the workaround in the checkout flow is compensating for. That knowledge normally lives in one developer's head and in a WhatsApp thread, and it leaves when he does.
You can have every credential and still be stuck, because the next team has to re-derive six months of decisions from the code alone. We built our own client portal partly for this reason — documents, change requests, and project state in one place the client can open without asking anyone's permission.
Ask now, not at the end
None of this requires a lawyer. It requires four questions, before signing:
Which account will the repository live under, and will I be an owner on it from day one?
Will the domain, the Apple Developer account, and the Google Play account be registered in my company's name?
What triggers handover — a date, a milestone, or "completion" as somebody later defines it?
Can you add me to everything now, rather than at the end?
The fourth question is the one that tells you the most. An agency that's comfortable with you holding the keys throughout will say yes without thinking about it. Hesitation on that question is information, and it arrives while you can still act on it.
Who owns your code is not decided on the day the agency stops answering. It's decided in the first week, by people setting up accounts quickly so they can start working. You can be in that conversation, or you can find out how it went much later — when a Continuous Development Contract or a new team is trying to pick up a product nobody can actually log into.
