Own your code, or don't build it

Most founders don't find out they don't own their software until they try to leave. The site works, the invoice gets paid, and everyone's happy — right up until the day you want to change vendors, hire an internal team, or sell the company. Then the questions start, and the answers get uncomfortable.

We've seen this pattern too many times. A business pays five or six figures for a platform, and when they try to take it with them, there's nothing to take. No repo. No admin access. No real IP. They were renting the whole time and didn't know.

What vendor lock-in actually looks like

Lock-in is rarely advertised. It's built into defaults, hidden in contracts, and excused as "how we work." A few of the common shapes:

**Proprietary frameworks.** The vendor built your app on top of an in-house CMS or "platform" that only they know how to operate. Leaving means rebuilding from scratch.
**No repository access.** You've paid for custom code, but you've never seen it. It lives on the vendor's GitHub, under their account, behind their SSO.
**Hosting only the vendor can touch.** The app is deployed to infrastructure the vendor controls. You don't have the AWS account. You don't have the DNS. You don't have the database credentials.
**Third-party tools with no export.** Form data, customer records, and content all live inside SaaS products that make exporting deliberately painful.
**Contracts that are silent on IP.** The work-for-hire clause is missing, vague, or quietly reversed. You're not sure whether you own the code or licence it.

Each of these is survivable on its own. Stack three or four together and you have a business-critical system you genuinely can't move, maintain, or evaluate.

The questions to ask before you hire anyone

You don't need to be technical to protect yourself here. You just need to ask the questions out loud and listen for the hedging. If someone can't give you a clean answer to these, that's your answer.

Where does the code live?

The correct answer is: in a repository you own, under an account you control, with your domain on the billing. Not "we'll give you access." Not "we'll send you a zip at the end." Your account, from day one.

Who has admin on the hosting?

You should have root — or the equivalent — on every environment that runs your software. Production included. If the vendor is the only one who can deploy, rotate keys, or pull logs, they are a single point of failure for your business.

Who owns the IP, in writing?

The contract should say, plainly, that all code, designs, and assets produced for you are your property on delivery and payment. Not licensed. Not shared. Yours. If you have to squint at a clause to figure this out, rewrite the clause.

What happens if you disappear tomorrow?

Ask it exactly that way. A good partner will answer with a shrug, because the answer is straightforward: the code is in your repo, the infra is in your account, the docs are in your drive, and any other vendor can pick it up. A bad partner will get defensive.

Can another developer read and extend this?

Custom software isn't really yours if nobody else can work on it. Ask to see the repo structure, the README, and the deployment docs before you sign. If the answer is "we handle that internally," you're being locked in.

How we do it at Bluestone

We wrote our default contract around the assumption that you'll eventually work with someone else. That's not pessimism — it's how grown-up businesses operate.

In practice, that means:

**Your GitHub.** Code ships to a repo in your organisation. We're collaborators, not owners. On day one.
**Your hosting.** Vercel, Fly, Railway, AWS — whatever fits the project, billed to your account, with your email on the root credentials.
**Your IP.** The contract assigns all work product to you on payment. No licences, no carve-outs.
**Your data.** Databases, buckets, and analytics live in your accounts. We get access; we don't hold it hostage.
**Your documentation.** Every project ships with a README, an architecture note, and a runbook. Enough that any competent engineer could pick it up cold.

If we vanish tomorrow, your business keeps running. That's the bar. Anything less than that is a favour we're doing ourselves, not you.

A short checklist before you sign

Paste this into the next proposal you receive and see how the vendor responds:

Code is hosted in a repository owned by our organisation.
We have admin access to all production infrastructure.
All IP is assigned to us on payment, with no separate licence.
Credentials for every third-party service are held by us.
The project includes written documentation sufficient for handover.

If any of those come back as "we'll discuss later" or "that's not how we usually work," you have useful information. Ownership isn't a negotiation. It's the starting line.

---

If you're not sure what you actually own today, we'll take a look and tell you plainly. Contact us to start the conversation.