What "yours" actually means

You own the code, the infrastructure, and the IP.

When we're done, everything we built for you lives in your accounts, under your name, on your terms — no proprietary wrappers, no hostage hosting, no clauses that claw rights back on a missed payment.

Most founders don't think about software ownership until they need it. The deal goes sideways, the agency goes quiet, a cheaper developer appears, a client asks for a security review, or a buyer runs diligence on an acquisition. That's the moment the question lands: do we actually own the thing we paid for?

Too often the answer is somewhere between "sort of" and "no." The source code sits in a repository you can read but not administer. The production server lives on an AWS account billed to a stranger. The CMS is a walled garden that only one person on earth knows how to extend. The contract, buried on page nine, turns every push of the code into a license rather than a transfer.

Bluestone exists, in part, because we got tired of watching that happen. This page lays out what ownership means here, in concrete terms — what you get on the day you could, in theory, fire us — and what to check in any software contract, ours or anyone else's, before you sign.

Ownership is not a nice-to-have. It is the difference between a piece of software you can grow, sell, or hand to another developer, and a piece of software that quietly expires the moment your current relationship does. It affects your valuation if you raise money. It affects your options if you want to switch vendors. It affects your peace of mind at two in the morning when something breaks and you need to know who, exactly, has the right to fix it.

What ownership means here

"You own it" is easy to say on a sales call. We spell it out instead. When we build for you, all of the following are true by default:

The source code lives in your GitHub organization (or Bitbucket, or GitLab). Not ours. We are added as collaborators on your repo, not the other way around. When our engagement ends, we remove ourselves and you're left with a clean admin surface you already understood.
The deployed infrastructure runs in your accounts. Vercel, AWS, GCP, Supabase, Fly, Cloudflare — whatever the project calls for, the resources are provisioned under your billing, your payment method, your audit log. You never have to ask us for access to your own systems.
Your domain and DNS stay with you. Registrar of your choice, under your name, with the credentials in your password manager. We'll happily configure DNS; we won't hold it.
Third-party accounts are registered to you. Stripe, Resend, Postmark, Twilio, OpenAI, Anthropic, a Postgres provider, an error tracker — every vendor invoice, every billing email, every admin console sits with you.
Documentation stays in your repo. The README explains how to run it. An "infrastructure.md" explains how it's deployed. An "env.md" lists every environment variable and what it does. If you hire a new developer tomorrow, they can onboard themselves.
Nothing is built on a proprietary Bluestone framework. We use the same boring, well-documented stack the rest of the industry uses — Next.js, React, TypeScript, Node, Python, Postgres. Any competent engineer can pick it up.

None of that is a "premium" tier. It's the only tier. We don't have a cheaper option where we keep the keys.

A useful side effect of this arrangement is transparency. Your cloud bill shows exactly what your software costs to run. Your repo shows exactly who touched what, when. Your vendor dashboards show exactly how many emails went out, how many payments were processed, how many API calls were made. Nothing is hidden behind an agency intermediary, which means there is no intermediary to argue with when a number looks off.

Handover day, in concrete terms

Handover isn't a ceremony at the end of a project. It's the way we set things up from the first commit, so the last day of the engagement is uneventful. Here's what you actually have the day you could, in theory, fire us:

Admin on the repo. You can remove every Bluestone account from the organization with two clicks.
Admin on the cloud consoles. Vercel, AWS, Supabase, wherever your production lives — your account is owner, ours is a guest we can revoke.
A complete environment variable inventory. Every secret and config value your system needs, documented with what it does and where it comes from. No hidden constants in a forgotten.env.localon a laptop.
An infrastructure runbook as a Markdown file in the repo. How the app is deployed, how to roll back, how to restore from backups, how to rotate credentials, how to scale if traffic jumps.
A thirty-minute video walkthrough where Eric goes through the repo, the deployment, and the on-call playbook. You can send it to your next developer on day one instead of booking an onboarding call with us.
Direct access to Eric for ninety days, no questions asked. Phone and email. If your new team has a question about why something is the way it is, we'll answer it. We don't charge for that and we don't gate it behind a retainer.

The test we hold ourselves to is simple. If Bluestone vanished overnight, the software would keep working, the domain would keep resolving, the bills would keep getting paid to the right vendors, and any decent engineer could clone the repo and be productive by the end of their first afternoon.

We check that ourselves before we call a project done. A common exercise at the end of an engagement is to ask a developer outside the project to clone the repo, read the runbook, and stand the system up from scratch in a scratch account. If it takes more than an afternoon, we treat the gap as a bug and fix the documentation, not the onboarding meeting. The goal is for handover to be boring — a state, not an event.

What other agencies actually give you

We don't want to be uncharitable, but the pattern repeats often enough that it's worth naming. The following are all real arrangements we've been asked to take over — arrangements that were sold to the client as "you own everything."

Code on the agency's Bitbucket with a read-only invite for the client. Technically the code is "yours." Practically, you can't merge a pull request or add another developer without going through the agency.
Hosting on the agency's AWS or DigitalOcean account, where your production system is a line item on their monthly bill. If the agency loses its corporate card, your SaaS goes offline. If the agency sells, your infrastructure transfers with the deal.
A proprietary "CMS" or "framework" that only the agency can maintain. Often pitched as a time-saving advantage. In practice, it's a moat around the client and a reason you can't hire anyone else.
Contract clauses that revoke rights on non-payment. Miss an invoice by a week and the copyright assignment reverses. A week after that, the agency's lawyer is emailing you about "unlicensed use." It's a leverage mechanism dressed up as payment terms.
"White-label" platforms where the agency's product technically owns your data. You pay them every month, forever, for a multi-tenant system your customers think is yours. The unit economics are great — for the agency.

Some of those arrangements make business sense for the agency. None of them make sense for you. The easy tell for any of them is a simple question on a sales call: "If we ended the engagement tomorrow, what would I actually receive, and where would the software run the day after?" A clear answer suggests a clear setup. A vague answer is itself the answer.

Six clauses to check before you sign anything

This applies whether you're signing with us or with someone else. These are the six things worth a careful read before any software engagement. If any are missing or worded evasively, ask to fix them in writing.

IP assignment. The contract should say, in plain language, that all work product is assigned to the client on payment. Not licensed, not sub-licensed — assigned. Watch for "perpetual license" language; a license isn't the same thing as ownership.
Source-code location requirement. The repository should live in the client's organization on the client's chosen platform. "We'll give you a copy at the end" is not the same thing. A copy is a snapshot; a live repo is history, branches, issues, and review comments.
Hosting and infrastructure account ownership. The cloud and hosting accounts should be opened in the client's name from the start. Running production on a vendor's account is one dispute away from an outage.
Third-party service registration. Every external service — payments, email, analytics, SMS, model providers, monitoring — should be registered to the client, billed to the client, and administered by the client. Spell this out, don't assume it.
No lock-in clause. A clear line saying the work will not be built on proprietary frameworks, platforms, or CMSes that restrict who can maintain it. If the agency has an internal "platform" they push, insist on understanding what's proprietary and what's open.
Itemized handover deliverables. The contract should list, specifically, what you get at the end: repo admin, cloud admin, env variable inventory, runbook, recorded walkthrough, and a defined post-engagement support window. Vague "we'll provide handover" language is the phrase that leads to the worst arguments months later.

You don't need a lawyer to check these. You need ten minutes and a Ctrl-F. If any clause is vague, ask the agency to rewrite it in plain English and initial it. A serious partner will. Anyone who bristles at a straightforward ownership question has told you something important about how they'll behave later.

For our own contracts, we publish these clauses on request before you sign anything. The agreement is short, written in English, and covers the six points above without hedging. If you want a copy to compare against what you have in front of you from another vendor, ask — we'll send it over.

Why we work this way

The honest answer is that it's good for both sides. We've seen founders lose weeks untangling agency code they paid for but don't control — chasing down a DNS password, trying to find out who actually has the root AWS credentials, paying a second developer to rebuild something that already exists because nobody can get access to the original. It's a bad use of a founder's time and it's a bad reflection on our industry.

Working this way puts a ceiling on our growth. There are agency models that make more money by keeping clients dependent, and we're deliberately not running one of them. We'd rather build a smaller business by doing this right than a bigger business by doing it wrong.

It also makes us better. When everything we build has to be legible enough to hand off at any moment, we write cleaner code, document as we go, and resist the temptation to invent cleverness that only we can maintain. Ownership, done honestly, turns out to be a forcing function for craft.

And it changes the shape of the relationship. Clients who know they can leave tend not to want to. We don't have to earn a retainer by being the only people who understand the codebase; we earn it by being useful. That's a healthier engagement for both sides, and in practice it's how most of our longest client relationships have lasted — not because anyone was locked in, but because the work kept being worth doing together.

Read: "Own your code, or don't build it"
See our services and how we structure engagements.
See pricing for typical ranges, deposits, and retainer terms.
Read the FAQ for short answers to the questions founders ask most.

Want to see a sample handover package?

Ask for one — we'll send a redacted version from a past project so you can see exactly what ownership looks like on the last day of an engagement.

Start a conversation Or book a 30-min call →