You should own your software, and here is what that means

Ask most owners where their software lives and you get a shrug. It runs, someone built it, the invoice comes monthly. That is renting, and the difference shows up on the day you want to leave.

What ownership actually consists of

Software is not one thing. It is four things, and you can own some and rent others without noticing. Here is the list we use at handoff.

1. The code, in your repository. A repository is the folder where the code lives along with its full history of changes. It should be under a GitHub account that belongs to your business, with us added as a collaborator, not the other way round. If we disappear, you remove our access and nothing else changes.
2. The database, in your account. Your leads, your customers, your inspection photos. The database project should be created under your organization, billed to you, with you as the owner. We hold a key to work on it; you hold the account.
3. The hosting and domain, on your card. The service that runs the site and the registrar that holds the domain name should both be yours. A vendor who owns your domain can hold your business hostage with a lapsed renewal, by accident or on purpose.
4. The documentation, in the repository. A plain file that says how the thing is deployed, where the secrets live, what the nightly jobs do, and what to check when something looks wrong. Not in our heads. Not in a chat thread. Next to the code, where the next person will look.

Why this matters more now

Custom software used to be rare because it was expensive, so ownership questions came up rarely. Now a painting company and a cabinet shop in Palm Beach County each have their own lead system, and small businesses are accumulating software the way they once accumulated spreadsheets. Every one of those systems is either an asset or a liability depending on who holds the keys.

Ownership also decides what a change costs. If the code is yours, any competent developer can pick it up. If it lives only inside a vendor's platform, every change goes through that vendor at that vendor's price, forever.

The handoff checklist we use

• Repository transferred to or created under the client's GitHub organization.
• Database project owned by the client, with the client's email as the owner login.
• Hosting project in the client's team, billed to the client's card.
• Domain in the client's registrar account, with renewal on auto pay.
• Every secret (API keys, email passwords, service accounts) stored in the hosting project's settings, not in the code, and listed by name in the documentation.
• A rules file in the repository that explains how the project is tested and deployed, so the next tool or person follows the same process.
• Analytics and search accounts owned by the client with us as a user.
• A written list of every third party the system depends on (email, maps, payments) and which account holds each.

Vendor red flags

These are the signs that you are renting, no matter what the invoice says:

• You cannot get a copy of the code, or the answer is "it is proprietary."
• The database lives in the vendor's account and you have a login to the app but not to the data.
• The domain was registered by the vendor "for convenience."
• Exporting your data costs extra or produces a format nothing else can read.
• There is no documentation, only a person who "knows how it works."
• The monthly fee is described as hosting but you cannot see a hosting bill.

What we keep

Nothing that matters. We keep collaborator access while we are working, and we keep the shared patterns we have learned across projects, the way any builder keeps a better way of framing a wall. The specific thing we built for you is yours, and the handoff is not finished until the checklist above is.

Every CRM, website, app and assistant we deliver, from a landscaper's lead system to a permit platform used by several companies, is set up this way from the first commit, so there is never a handoff to negotiate later.

Questions people ask