They look similar and are not
An internal AI tool can assume your data shapes, your vocabulary, your process and your one customer. A product can assume none of those, and unpicking those assumptions is most of the work of converting one into the other.
That is why “we will build it for ourselves and sell it later” usually produces something that serves neither well.
What a product needs that a tool does not
- Multi-tenancy, with data separation you can prove
- Self-service onboarding, because you cannot configure each customer by hand
- Configurable vocabulary and rules per customer
- Billing, usage limits and plan enforcement
- Support, documentation and a status page
- Security posture you can answer questions about
Each of those is weeks of work. Together they frequently exceed the original build, which is why the conversion decision deserves its own business case rather than being assumed.
Build internal first, deliberately
Prove the capability where the error tolerance is higher and the feedback is better. Your own staff will tell you what is wrong far more directly than customers will.
If it works and other businesses genuinely want it, you will then be building a product with a proven core rather than a hypothesis.
Signals that a product is real
- People outside your business have asked to use it, unprompted
- The problem is common rather than specific to how you operate
- You can describe the buyer without describing yourself
- Someone has offered to pay before it exists
Fewer than four and it is an internal tool, which is a perfectly good thing to be.
If you do go both ways
Build the capability as a service with a clean interface from the start, and let both the internal tool and any future product consume it. That way the expensive core is built once.
It costs a little more initially and it preserves the option properly rather than nominally.