Who Owns the Code

Nobody asks this on the sales call. It shows up later, usually after something's gone wrong, or after someone in finance asks why the invoices for "your" software keep coming from a company you no longer talk to.

The line that decides whether you can leave

You've outgrown the spreadsheet everyone secretly runs the business on. Now you're signing a real contract for a dispatch tool or a CRM or a portal that's going to sit underneath how your company runs for years. Most of that contract is about scope, price, and timeline. One line, usually near the back, decides something bigger: whether you can ever leave.

That line doesn't feel urgent during a kickoff call. It gets urgent the day the relationship sours, or you just want a second opinion on the code and can't get in the door. Vendor lock-in isn't a technicality buried in an appendix. It's the whole game.

Our answer

You own the code, outright, from day one. Not at final payment. Not on request. The repos live in your organization. The infrastructure runs in your own cloud account, set up as infrastructure as code, not something we control and hand over later if you ask nicely.

What that looks like day to day

Anyone can put "client owns all deliverables" in a contract. The question is whether it's true in week six, not just in the signed PDF.

A fixed-scope project is billed on milestones — typically 30% at kickoff, the rest tied to phase acceptance. A custom web application we build deploys into an AWS account that belongs to you from the start. It isn't a black box only we understand.

Discovery week costs a flat $4,800, credited back in full if you continue. It ends in a written scope, an architecture sketch, and a fixed estimate. That paperwork tells you what you're going to own before any code exists.

There's also a named lead on the project from the scoping call through launch. The person who scoped it ships it. That's not a customer-service detail. It's who you'll be asking questions about your own architecture a year from now.

The more common setup

The alternative is code and infrastructure sitting inside the agency's own accounts — their AWS account, their GitHub organization. It gets explained as a technical convenience. Maybe it is, for them. For you it means every future negotiation happens with you holding no cards, because walking away means losing access to the thing you paid for.

This is part of why we choose boring technology on purpose. React, Node, Postgres. Established tools instead of something we invented in-house. Novelty is a cost paid every year after launch, and it's usually the client paying it, not us. Owning the account and not being dependent on our private tooling are two different disciplines. Both exist so you're never stuck with us for reasons that have nothing to do with the quality of the work.

Ownership and support are different things

Owning the code doesn't obligate you to keep paying us to maintain it. Care & Improvement starts at $4.5k a month, billed monthly in advance, cancel with 30 days' notice. No penalty clause, no re-licensing fee.

We think software is never finished — the ongoing work is part of the product, not an afterthought. But that's a position we hold about how software should be treated, not a lever to keep you paying us. If your own team wants to take over maintenance in six months, they can. They'll already have the repo and the account.

What happens when the relationship ends

You get a full handover: an architecture walkthrough, runbooks, and two weeks of support. That's separate from the 30 days of post-launch fixes that come with every fixed-scope phase — the handover is about continuity, the post-launch window is about squashing bugs.

The point isn't to make you stay. It's that leaving doesn't cost you your own software.

NDAs and security questionnaires, handled early

If you're in healthcare, fintech, or insurance, the ownership question usually arrives with a second one: can this vendor pass our security review. We work under NDA by default and complete vendor security questionnaires as part of onboarding.

We don't carry HIPAA, PCI-DSS, or SOC 2 certification, and we won't imply otherwise. We treat the questionnaire and the NDA as a standard early step, not something you discover in month three.

Questions to ask any vendor, including us

Who holds the repo — created inside the agency's own GitHub organization, or inside yours from the start? Whose cloud account does the software deploy to? What's actually written down about handover if things end, versus a vague promise to "help you transition"?

Ask before you sign.

Owning the code doesn't make it good code

Ownership answers one question: can you leave. It doesn't answer whether the thing you own is any good. You can own a repository full of tangled, undocumented architecture as easily as you can own something clean.

One decent signal is whether the estimate came after a real discovery process or before one. A fixed number handed to you on the first call, before anyone's looked at your data or your systems, isn't really an estimate. Ours comes after discovery week, once there's a written scope and an architecture sketch behind it. That's a separate conversation from ownership, but it's the one that actually predicts whether you'll be happy with what you own.

Why we don't take equity or deferred payment

We don't take equity in a client's company, and we don't do deferred payment tied to some future outcome. It muddies the relationship, and it has never once made the software better. Cash, milestones, clear scope. You know what you're paying for, and so do we.