What "you own the code" actually means

Every studio says you own what they build. Then the project ends and you find the repository is on someone else's GitHub org, the servers are on the agency's cloud account, the domain was registered to a project manager who left, and the Figma files are in a workspace you can't log into.

None of that is malice, usually. It's just what happens when nobody decided up front where things live. So we decide up front. Here's what "you own the code" means on a Web2Droid project, concretely.

The repository is yours from the first commit

We don't build in our own repo and transfer it at the end. On day one you create a repository — or an organization — and add us to it. Every commit lands there. If our engagement stopped tomorrow, you'd have the complete history and could hand it to any other team without asking us for anything.

This also means you can see progress whenever you want, not just at the weekly demo.

The accounts are in your name

Hosting, the database, error monitoring, analytics, the app store developer accounts — all created under your billing, with you as owner. We get invited as collaborators with the access we need, and that access can be revoked the moment the work is done.

The practical test: after we're gone, can you deploy a change, read your logs, and pull your data without contacting us? If the answer is no, something is set up wrong.

The design files are in your workspace

Same principle. The Figma project lives in your team. The design system, the components, the prototypes — you can open them, export them, and hand them to another designer.

There's no license-back clause

Some contracts grant you ownership and then license the "reusable components" or "framework" back from the agency, which quietly means you can't leave. Ours don't. If we build something generic enough to reuse — a form component, a deploy script — you own your copy outright, and so do we own ours. Neither depends on the other.

Why we work this way

Partly it's fair. Mostly it's that lock-in is a bad business to be in. We'd rather clients stay because the work is good and the next project is worth doing together — not because leaving is a migration project.