Notes

Founder decisions

The first client paid. That is not yet a product

A client paid to solve their problem, and the team delivered. It is tempting to offer the same thing to other companies. But that payment proves demand for one client project, not for an independent product.

Why I am careful with a new direction

This caution comes from experience. In a 2024 interview with ER10, I described opening new directions before securing the base of the business. Expansion moved faster than project income could pay for it. That is a story about the past, not a claim that Sailet has a proven formula for product bets today.

Sailet currently builds custom software and automates business processes. Own products may be a next stage. Between “we can build it” and “this is a separate business” lies a test that the word “scale” cannot pay for.

Similar complaints do not mean the same buyer

Imagine an industry partner introduces a company that loses customer requests. A team builds a system for it, and the company pays. That can be a good client project. But another company may use the same words while having different staff, permissions and approval steps. If half the solution must be rebuilt each time, the service is repeating, not the product.

Before building more, it helps to meet independent potential buyers: who approves the purchase, how they handle the problem now, what inaction costs them, and whether they would pay to test a shared core solution. A polite “interesting” and a paid commitment are different signals.

Count contribution, not total revenue

A hypothetical example, not Sailet figures: a first pilot brings in 10 units and costs 6 to deliver directly. It leaves 4 for the next bet, not 10. If a bounded product test costs 12 units, and each additional buyer also leaves 4 after direct costs, covering just the test takes three such buyers: 12 ÷ 4 = 3. The first does not establish that the second and third exist.

This is deliberately incomplete. It excludes overhead, time to close a sale, support and rework. Its purpose is to show why an invoiced project is not all free cash for a product, and why one sale does not prove repeatable economics.

Three honest decisions

If the problem belongs to one buyer, or every solution must be largely rebuilt, keep it as a client project. If independent buyers will pay for a similar solution, a bounded product pilot may be warranted. If there are no buyers yet, or no one can own the result, do not announce a new direction.

Before a pilot, name its owner, spending limit, deadline, observable result and stop condition. This is a proposed way to discuss a bet, not a description of Sailet’s current internal process. Without an owner, an idea can quickly become something the founder must rescue repeatedly.

What a partner can bring to the first conversation

If you know a costly problem that recurs in your industry, show one recent instance, identify who can approve a purchase and explain your access to them. If you could run the direction, tell me which result you would own. Then we can discuss whether this remains a client project, deserves a bounded product test, or is not a bet yet.

If you already need software built for your company, speak with the Sailet team. I am especially interested in the decision about whether a client problem could become a business we build together.

Seeing the same costly problem repeatedly?

Tell me who faces it, how they handle it now, who could fund a test, and which part of the outcome you would own.

Discuss an opportunity

Reasons to get in touch

Already have a defined implementation project? Talk to the Sailet team