Your agency should push to your repo on day one
Some agencies hold source code as leverage. We push to your repo from day one. Here's what that costs us, what it gains you, and why it matters at exit.
Built on tools you trust
← swipe · 12 tools →
What most agencies actually own
Read the boilerplate of a typical agency contract and you'll find some version of this clause: "Agency retains ownership of all intellectual property, including source code, frameworks, libraries, and methodologies developed during the engagement, and grants Client a non-exclusive, perpetual license to use the deliverables for their intended purpose."
Translation: the code is theirs. You get to use it. If you want to move agencies, modify it substantially, sublicense it, or have your in-house team take it over, you may need to renegotiate.
Some agencies are fairer than this. Some are worse. The point is: "we built it for you" and "you own it" are not the same statement, and most clients don't realize that until exit.
Why it happens
Agencies hold IP for two reasons, one defensible and one not.
The defensible reason: agencies build reusable components. A login form, a payments integration, a deployment pipeline — they ship versions of these on every project. Reasonable agencies want to keep the *underlying patterns* portable across clients, which means owning the framework code that's not specific to your project.
The non-defensible reason: lock-in. If the agency owns your source, you can't easily switch providers. The cost of moving is the cost of rebuilding. That's a moat for them and a tax on you.
The two motivations get bundled into the same IP clause and you can't tell which one is driving from reading the contract.
Our policy
You own everything from day one. Specifically:
- The repository is yours. We push to a GitHub (or GitLab, or Bitbucket) repo in *your* organization, not ours. We get contributor access. You get owner.
- The code is yours, including patterns. We do reuse internal templates and libraries — we'd be slower if we didn't — but anything we ship into your repo, you own outright. No license-back clauses.
- The infra is yours. We deploy into your AWS/GCP/Vercel/Fly account, on your domain, with your billing. Not a hand-off later. From the first deploy.
- The credentials are yours. API keys, secrets, service accounts — created in your tenant, owned by you.
- The data is yours. We don't keep client data after engagement end. Production access is removed; backups (which are yours) stay in your storage.
The contract reflects all of this. We don't reserve "perpetual license" rights. We don't keep a copy of your source to use as a "reference" later.
Why we do it this way
Three reasons:
- It's right. You paid for the work. The work is yours. Anything else is a tax on the deal.
- It removes lock-in as a sales lever. We win the next engagement by being good at the next engagement. Not because you're stuck with us. That changes how we behave during a project — we're optimizing for "do they come back," not "are they trapped."
- It makes exit clean. If we stop being the right partner — for capacity, fit, price, anything — you take the source code and the deploy access and you walk. No untangling, no IP transfer fee.
At exit, this matters more
The painful version of this comes up at acquisition. If you're selling the company, the acquirer's diligence will ask for source code ownership. "Our agency owns the IP, but we have a perpetual license" is a finding, not a clean answer. It's a thing to negotiate, a delay, a discount.
We'd rather you never have to deal with that. So you don't.
Edge cases
A few honest ones:
- Open source dependencies. Your code uses MIT/Apache/BSD libraries we didn't write. Those licenses pass through to you. We document the license inventory in the repo (
THIRD_PARTY.md) so you know what you're carrying. - Internal Hayaiti utilities. We do have a small set of internal packages we reuse (build configs, ESLint presets, Tailwind helpers). Those are MIT-licensed on our public GitHub, so you effectively own them too. We don't carry private packages into client repos.
- Patterns and methodology. We can't (and don't try to) carry abstract methodology to other clients. If you ask "how would you approach X" — that knowledge is portable, on both sides.
What to ask any agency you're hiring
Before you sign:
- Whose GitHub organization is the repo in?
- Whose AWS/Vercel/etc. account does it deploy to?
- What does the IP clause in the contract say verbatim?
- At engagement end, do you keep a copy?
- If we hire a new agency in 18 months, what's the handoff process?
If the answers are "ours, ours, we own it, yes, here's the $15K transition fee" — you know what kind of relationship that is.
If the answers are "yours, yours, you own it, no, none" — that's what you're paying for.
The full Hayaiti contract template is available on request before you book. Email hello@hayaiti.com and we'll send the current version. Or if you've already decided, the pricing page has the SKUs and the IP terms are the same on every line.
The Hayaiti team
Hayaiti
Hayaiti is a productized engineering studio. We ship web, software, iOS, and cybersecurity work on fixed prices and calendar-day timelines. The team takes turns on the shipping log.
More from the shipping log
The bounded SKU model: why we don't sell time
Most engineering vendors sell hours. We sell deliverables on a calendar. The unit of accountability is different — and it changes both the vendor incentives and the buying experience.
When NOT to pick Hayaiti
Most agency homepages claim to be the right fit for everyone. We're not. Here's a concrete list of when to pick someone else — written by us, for our own site.
Why our pricing is on the page
Most agencies hide their prices. We publish every SKU. Here's why we made that bet, what we lose, and what we gain.
Want help shipping this?
We turn posts like this into production code. Fixed price. Calendar-day timelines. Source code in your repo on day one.