Your Agency Built Products That Never Took Off

Agencies are good at building software and often less good at selling their own. A product started between client projects, an internal tool that was going to become a SaaS, a white-label platform that never found a second customer: most agencies have at least one. The code is usually solid, because it was written by people who build for a living. If the agency owns it, Odys AI Labs, the research and development arm of Odys, can buy it for cash for AI training and R&D.

What your code is likely still worth

Agency products often score well on quality. They tend to follow the team’s house standards, use consistent patterns, include deployment scripts and sometimes have better tests than a startup’s first version, because the same team has shipped many projects. They may also come with tickets and designs from the agency’s own Jira or Linear and Figma workspaces, which add context about why things were built.

Suppose a twelve-person web agency spent two years building an event ticketing platform in its quiet months. It had a Laravel back end, a React admin, a payment integration and a design system in Figma, and it signed one pilot customer before the agency’s client work picked up and the product was shelved. The code was written by the agency’s own staff, in the agency’s own repositories, with tickets in its own Jira. That is a clean, complete product, and it is the kind of case that usually fits well.

Internal tools count too. A quoting engine, a time-tracking system or a client reporting dashboard that your team used daily for years is real software with real history. Both kinds qualify if they are complete, original to your team and make no money today.

We do not publish price figures. The agency typically receives a concrete cash offer after review, and the house standards and tests described above are part of what that review looks at. How we value a codebase is explained on the call.

What a buyer will check

• Separation from client work. Is the product in its own repositories, or tangled with client projects?
• Contract trail. Do your client contracts leave the agency owning reusable components?
• Contributors. Which staff, freelancers and subcontractors wrote it, and what did they sign?
• Third-party code. Open-source libraries are normal and do not stop a sale; they stay under their own licenses. See open source inside your codebase.
• Client data. Nothing from client systems, such as exports, logins or sample records, should be in the repo.

Three risks specific to this situation

1. The product grew out of a client project. A common story: the agency built something for a client, saw a wider market, copied the repository and kept going. If the client contract assigned that original code to the client, the early part of your product’s history may belong to them. Look at where the first commits came from. If the product started as a copy of client work, read that contract before anything else. Our guide on which agency code you can sell walks through the usual contract types. This is not legal advice; ask a lawyer to review the clauses.

2. Freelancers and subcontractors without assignments. Agencies scale with freelancers. In the US, code from an outside contractor is usually not work made for hire by default, because software is not one of the nine categories the law lists for commissioned works, and a transfer of copyright needs a written, signed document. If freelancers wrote part of your product without signing an assignment, a short confirmatory assignment now usually fixes it. Our guide on who owns the code explains how. This is not legal advice.

3. Shared component libraries. Agencies often keep a private library of components, starter kits and utilities that end up in both client projects and their own products. The question is what each client contract said about that library: kept by the agency and licensed to the client, or handed over. Selling the library as part of your product is usually fine when you kept ownership. It is not fine when a client owns it. There is a second catch: if your team still uses that library on client work, selling it outright could stop you using it yourself. In that case leave it out of the sale, or raise it early; the agreement sets out exactly what rights transfer. Map where the library came from and which contracts touched it.

What to do this month

1. List every agency-owned product and internal tool, separately from client repositories.
2. For each one, check where the first commits came from and whether any started as client code.
3. Pull the standard terms you used with clients and look for clauses on background IP, reusable components or pre-existing materials.
4. List freelancers and subcontractors who touched each product and what they signed.
5. Remove client data, client credentials and client names from code, fixtures and config files.
6. Export tickets and designs for the products you plan to offer.

Your options

Selling a product’s code does not take away your team’s skills or its general way of building software; what changes hands is the specific codebase. Anything you still need for client delivery should be named and kept out before the agreement is drafted. Our comparison of selling versus open-sourcing shows the trade-off in more detail.

Whatever you choose, protect your clients. We never ask anyone to install or run anything, no code changes hands before a signed written agreement, and we never take databases, user records or customer data. If anyone asks for a copy of your repositories before a contract exists, decline: client data and credentials often sit closer to the surface in agency repos than people think.

What to do next

• Separate agency-owned products from client work, repo by repo.
• Check client contracts and freelancer paperwork for each product.
• Send us a few details for a free code valuation, with no code and no obligation.