From a client project to a product: when it makes sense

Before 2004, 37signals was a web design firm of three designers whose project communication with clients had become a mess. Email updates worked, as Jason Fried later put it, for about five minutes. So they built their own project tool and started running client work through it. Clients kept telling them they needed something like it for their own projects. The firm launched it as Basecamp on 4 February 2004. They had privately hoped it would make $5,000 a month after a year. It got there in six weeks.

The story is usually told as if the path were obvious: build for yourself or a client, notice the demand, become a software company. It is survivorship. Most internal tools and most client builds never become anything else, and most should not.

The question is also less settled than it was. In June 2025, Andreessen Horowitz published an essay arguing that AI software companies should embrace services, with forward deployed engineers who sit inside customer operations and do the implementation work. It said that "sometimes human-intensive services are necessary to create transformative software." Product companies are moving toward services at the same time that some service firms are moving toward products. The boundary is blurring from both sides, which makes it more important to know why you are crossing it.

Two different origins

At WAOF, a technology, product and creative studio that started in Monterrey, two of our products grew out of client work, and they came from different places. The difference matters.

Neo started inside Soriana in 2023. Soriana needed to train a national workforce that changes constantly, and we built its corporate learning system from inside the operation. Our thesis describes it as a custom corporate LMS with a streaming-style experience, built to centralize operational knowledge across a national retail network, with 58,146 registered users since 2023. It became neo.education, and we have said publicly that we are opening it to more operators. Neo is the case of a project that turned out to be more general than its brief.

Mapboard did not come from one project. For years, retail chains in Mexico told us the same thing: local-search tools are built for marketers, while the people responsible for hundreds of physical locations need something different. No single engagement would have paid to build a product for that. It only became visible across several clients over time. Mapboard is a pattern that no project owned.

Both paths can work. They fail in different ways, and they raise different questions.

Four tests

These are the questions we think need a clear answer before a client build becomes a product. They are our view, not a method we claim to have applied perfectly.

The first is whether the problem repeats, not just the solution. Basecamp's signal was that clients and colleagues asked for the tool themselves. For Neo, the condition behind the problem, frontline teams hired constantly and trained away from a desk, is shared across retail. If the second customer would need half the system rebuilt, what you have is a service with a login screen, and it should be priced and run as one.

The second is whether ownership is clear before anyone says the word product. In Mexico, the Federal Copyright Law sets two defaults that apply unless the parties agree otherwise. Under Article 103, software that employees write as part of their job belongs to the employer, so the agency usually owns what its own people write. Under Article 83, whoever commissions a work holds its economic rights, so when the work was commissioned, the default points to the client. Any transfer of those rights has to be in writing. In practice, contracts tend to separate what the agency brought to the project, such as its own tools, components and methods, from what was built for that client, and say who keeps each and what license goes the other way. Ideas and general know-how are not protected by copyright, although confidentiality clauses can still limit how they are reused. A product built from client work rests on what was signed, not on who wrote the code. Data is a separate and stricter line, governed by confidentiality and data protection rather than copyright. Nothing a client shared about its people, processes or results should travel into the product. This is a general description, not legal advice, and each case should be reviewed by a lawyer.

The third is whether someone is willing to run it. A product is an operation, not a delivery. It needs support, uptime, a roadmap and people who answer when it breaks. Our approach lists the steps in order: observe, prototype, operate, then productize. The order matters. Neo has been in production at national scale for three years, and only now are we opening it to more operators. Basecamp, for its part, ran on a single server for its first year. The willingness to operate came before any scale.

The fourth is whether the first client ends up better off. A product pulls toward the average customer, and the client behind the first version can find its specific needs competing with everyone else's on a shared roadmap. There is also a quieter conflict. Once an agency owns products, its advice is no longer neutral. When a client's problem looks like something we sell, the minimum is to say so plainly and let the client decide.

When it doesn't make sense

Sometimes the value of a build is that it fits one operation closely. Generalizing it would make it worse for the client and only average for everyone else. Sometimes the client would rightly see a product as their idea leaving the building. And sometimes nobody on the team wants to run software for years, which is a legitimate reason to stay a services company. Most of what we build for clients falls into one of these, and stays theirs.

The cases that make sense tend to have something in common: the problem was there before the project, it shows up in more than one place, ownership is settled in writing, and someone is ready to be on call for it. Our thesis puts the last part this way: products return to real operations, where we keep testing and improving them. A product that does not return to an operation is just a codebase with a sales page.