Most business owners assume that if they pay for software to be built, they own it. That assumption is wrong, and it's expensive to learn the hard way.
The legal default in software development is the opposite of what you'd expect. Unlike an employee, where the company owns what they produce, an independent contractor or agency retains ownership of the code they write unless a contract explicitly transfers it. Pay an outside developer to build your app and, by default, they own the intellectual property. You just have permission to use it.
This is the quiet trap underneath a lot of "custom" builds, and it's worth understanding before you commission anything.
Why "work made for hire" isn't enough on its own
The common fix people reach for is a "work made for hire" clause. It sounds airtight: the software is created as a work for hire, so your company is the original owner.
Except it often doesn't hold. Work-made-for-hire only applies cleanly to employees, or to independent contractors when the work falls into specific narrow categories defined by copyright law. A lot of custom software doesn't fit those categories, which means simply labeling it "work made for hire" in the contract may not actually transfer ownership if it's ever tested.
A properly drafted agreement uses both work-made-for-hire language and a present assignment of all IP rights. The assignment is the part that actually does the work. If your contract doesn't have it, you may not own what you think you paid for.
Vendor lock-in is the same problem wearing a different hat
Even when ownership is clear on paper, there's a second trap: lock-in. Vendor lock-in means switching providers becomes so costly or risky that staying feels safer than leaving, even when you're unhappy.
It comes from more than contracts. It comes from code you can't access, documentation that doesn't exist, and total dependency on the one shop that built the thing. If the only people who understand your software are the people you'd have to fire to leave, you don't really own it, you're renting it with extra steps.
The things that prevent lock-in are boring and specific: shared repo access, a real IP assignment, actual documentation, backups you control, and a written exit plan. If a build doesn't come with those, that's a signal.
How we do it
We took the position that ownership should be total and obvious, because the alternative is the thing everyone hates about agencies.
- We build in a repository inside your GitHub organization from day one. You watch the code get written.
- We deploy to your cloud accounts, on your infrastructure.
- At handoff you receive full IP assignment, the credentials, the runbooks, architecture diagrams, and a recorded walkthrough.
- We build with standard frameworks and readable conventions specifically so any competent engineer can maintain it after us. No proprietary black box that only we can touch.
There are no per-seat licenses to us, no monthly fee to keep the lights on, and nothing stopping you from taking the whole thing to another team tomorrow. That's the test of real ownership: could you fire us and keep running without missing a beat? With everything we build, the answer is yes by design.
The bottom line
Custom software is one of the highest-leverage investments an operator can make, but only if you actually own the asset at the end. Before you commission anything, from us or anyone else, ask three questions: Do I get a present assignment of the IP, not just a work-for-hire label? Do I get the repo and the credentials? Could my own team maintain it without the builder?
If the answer to any of those is no, you're not buying an asset. You're signing up for a landlord.