Building AI products versus using AI internally
The difference between using AI to run your business better and selling something with AI in it, and why the second is a different company.
The short answer
There are two very different things a business can do with AI. The first is use it internally: automate the repetitive work, speed up delivery, improve accuracy, and run the business you already know how to run more efficiently. The return is measured in hours and errors saved, arrives within months, and the risk is small. The second is build a product with AI in it and sell it. That means entering a software market, with software economics, software competition and a much harder test: strangers paying, and continuing to pay. It also brings obligations internal tools never have, support, reliability, security reviews, data protection for other companies’ data, onboarding, documentation, billing, a roadmap, and regulatory duties where the AI Act applies, which together usually cost several times the original build. Product ideas often do emerge from internal work, and the right sequence is to prove the thing internally, then talk to other businesses about the problem rather than the tool, and only then decide, deliberately and with separate funding, whether to become a software company as well.
Two different undertakings
| Dimension | AI used internally | An AI product you sell |
|---|---|---|
| Success measure | Hours and errors saved; delivery speed | Paying customers who renew |
| Time to value | Weeks to months | Often years |
| Risk | Low; reversible | High; most products fail |
| Fit required | Your process and data | Many strangers’ processes and data |
| Reliability | Internal tolerance | Customers’ operations depend on it |
| Support | Colleagues ask you | A support function with expectations |
| Security and compliance | Your own standards | Other companies’ data; questionnaires; AI Act duties |
| Documentation and onboarding | Minimal | Essential and continuous |
| Ongoing cost | Maintenance | Roadmap, support, sales, marketing, infrastructure |
| Skills needed | Your domain plus a partner | Product management, sales, support, marketing |
| Who should fund it | Operating budget | A deliberate investment decision |
If you are considering it
- Prove it internally first, with measured results over at least two quarters.
- Talk to ten similar businesses about the problem, not your solution, and ask what they do now and what it costs them.
- Test willingness to pay with a concrete price before building anything for them, ideally with a paid pilot.
- Cost the product obligations honestly: support, reliability, security, compliance, documentation, onboarding, sales.
- Decide deliberately, with separate funding and named people, not with the operating business’s spare capacity.
- Start with the narrowest version that solves the problem for a specific kind of customer.
- Keep the internal use running regardless, because that is where the reliable return is.
The middle option
There is a third path between keeping a tool internal and becoming a software company: productising a service. You keep selling outcomes rather than software, but the delivery is standardised and AI-assisted, sold at a fixed price with a defined scope. Clients get a predictable deliverable, you get repeatable margin, and you avoid the support, reliability and compliance obligations of a product. For a service business with a good internal tool, this captures much of the value with a fraction of the risk.
What this means for you
Using AI internally improves a business you understand, quickly and at low risk; building an AI product is a separate venture with obligations that usually cost several times the build. Prove internally, test demand with paid pilots, cost the product obligations honestly, and fund the decision deliberately if you make it. Consider productising the service instead, which captures much of the value without becoming a software company.
Frequently asked questions
We built something internally that works. Should we sell it?
Maybe, and the question to answer first is whether other businesses have the same problem badly enough to pay for a solution they did not build. Your internal tool fits your process, your data and your people; a product has to fit strangers. Before building anything, talk to ten businesses like yours about the problem, not the tool, and find out whether they would pay. An internal tool can stay internal, and that is not a failure.
What changes when it becomes a product?
Everything around the software. Support when it breaks at inconvenient times. Reliability targets that customers depend on. Security and data protection obligations for other companies' data, including the questionnaires. Onboarding for people who do not know your process. Documentation. Billing. A roadmap and the expectation of improvement. Compliance obligations, including the AI Act where relevant. Those costs typically exceed the original build several times over.
Which is the better use of our money?
For an established business, internal use, because the return is immediate, the risk is low and it improves a business you already understand. Building a product is a separate venture with venture economics and a high failure rate; it deserves a deliberate decision, its own funding and its own people, not the spare capacity of an operating business.