The short answer
Buy when the task is common and general tools already do it well: drafting, summarizing, transcription, search across ordinary documents. Build when the problem is specific to your firm, when your own data is the advantage, when accuracy has to be proven on your own work, when the data cannot leave the building, or when no product fits the way the work is done. Between the two sits a third option: configure an existing product with your documents and settings.
Whichever you choose, judge it on real work it has never seen, not on a demonstration, and settle before signing what you will own at the end.
When off-the-shelf AI is enough
If a task looks the same in your firm as in thousands of others, a product is usually the right answer.
- The task is common. Drafting, summarizing meetings, translation, transcription and help with code are done well by general tools.
- Mistakes are cheap. An error costs a few minutes of correction, not a wrong decision.
- The data is not sensitive, or the vendor's terms and hosting meet your rules.
- Speed matters more than fit. A tool in use next week beats a perfect system next year.
Buying also hands the maintenance to someone else: model upgrades, security fixes and hosting become the vendor's job, on the vendor's schedule.
When a custom build pays
- A specific problem. General tools give general answers. When the task depends on your own definitions, of a defect, a risky clause or a qualified lead, a product built for everyone fits no one exactly, and its output needs interpreting before it can be used.
- Proprietary data that is the advantage. A firm's edge often sits in its own records: years of cases, inspections, deals or outcomes. A system built on that material can do what no general product can, while sending it to a shared service can hand the advantage to others.
- Accuracy that must be proven. When a wrong answer has legal, financial or safety consequences, you need a measured error rate on your own work, which a general product rarely gives you.
- Data that cannot leave the building. Regulation, contracts or security may rule out outside services entirely.
- Workflows no product fits. When bending the business to the tool would cost more than shaping software to the business.
If none of these applies, buying is usually the better choice. A custom system also has to fit the systems around it; our guide on how to integrate AI into existing systems covers that part.
Buy, configure or build
Configuring sits between the two: an existing product adapted with your documents, settings and connections to your systems, sometimes with extra training the vendor offers. It is often a sensible first step, because it shows quickly whether the approach works before you pay to build.
| Buy | Configure | Build | |
|---|---|---|---|
| Upfront cost | Lowest, usually a subscription | Moderate: setup and integration work | Highest: design, development and testing |
| Time to first use | Fastest | Moderate | Slowest, though it can arrive in stages |
| Fit to the problem | General; you adapt to the tool | Closer, within what the product allows | Built around your definitions and workflow |
| Data control | Set by the vendor's terms and hosting | Mostly the vendor's, sometimes with private hosting | Yours; it can run on your own hardware |
| Ownership | None; you rent access | Your configuration, not the core | The code, and model weights where they can be handed over |
| Maintenance | The vendor's, on the vendor's schedule | Shared; vendor upgrades can break your setup | Yours, or a partner's under contract |
How to judge a custom system
A demonstration proves very little. It shows cases someone chose, often ones the system has effectively seen before. The fair test is a held-out test set: real examples of the work, with known correct answers, kept apart from everything used to build the system.
- Collect real cases, including the hard and unusual ones, in roughly the mix the work produces.
- Set them aside before development starts. Nothing in the test set, or close to it, may be used to build or tune the system.
- Agree the measure in advance: the share answered correctly, errors by type, and which errors matter most. A missed fraud and a false alarm do not cost the same.
- Compare against the alternatives, the current process and the best off-the-shelf tool, on the same cases.
- Rerun the set after every change, so accuracy is tracked over time rather than claimed once.
The test set should be delivered with the system. When accuracy is a number you can check yourself, you do not have to take anyone's word for it.
What you should own at the end
If a system cannot be maintained without the people who built it, the firm does not really own it, whatever the contract says. Ask for:
- The code, including the scripts that build, test and deploy it.
- Model weights, where they can be handed over. A model adapted from an openly licensed base can usually be handed over under that base model's license; a model reached through an outside service has no weights to give. Ask which case applies before signing.
- The data pipeline and the test set, so the system can be retrained and rechecked.
- Documentation for the next engineer: how it is built, why the main choices were made, how to retrain it and what tends to break first.
- Written terms on your data, stating that your material is not used to train anyone else's models.
Running costs and self-hosting
Over a system's life, the build price is often the smaller part of the cost. Running costs include hosting or hardware, monitoring, retraining as the work changes, and the engineering time to keep it all working.
- Self-hosted. Data never leaves your network, costs are mostly fixed, and nothing changes unless you change it. In exchange you buy and run the hardware, plan capacity for the peak, and may be limited to models small enough to run on it.
- Outside service. No hardware, and costs scale with use. But data leaves the firm, and the provider can change or retire the model underneath you.
A hypothetical comparison, not a quote: a build costs $150,000 plus $3,000 a month to run, against a subscription at $8,000 a month. The build saves $5,000 a month, so it recovers its upfront cost after 30 months ($150,000 divided by $5,000). Add a part-time engineer to maintain it and that point moves further out. Cost alone rarely settles the question; fit, data control and ownership usually do.
Red flags in a proposal
- Accuracy from a demo. Figures with no test set behind them, or a test set you cannot see or rerun.
- Your data trains their product. Terms that let your material improve models sold to others, competitors included.
- Code or weights stay with the vendor. You pay for the build but can only run it through them.
- No running costs. A build price with nothing about hosting, monitoring or retraining.
- Self-hosting without the trade-offs. A promise to run on your hardware that does not say what it limits or costs.
- A vague problem. AI everywhere, with no single task, measure or owner defined.
- Certainty. Every model makes mistakes. A proposal should say how many, of which kind, and what catches them.
How Lualdi Advisors does it
Custom Software: built for one problem
Lualdi Advisors builds around a single problem a firm actually has, using its own material and its own definitions, so the output is usable on the day it arrives rather than after a quarter of interpretation. It builds on what the firm owns, under terms that keep it the firm's, and never routes that material through anything that would teach a competitor's model on the way past.
Every system ships with the test set it was judged on, run against work the model was never shown, so its accuracy is a number you can check rather than a claim you have to accept. Where work cannot leave the building, it is built to be self-hosted on your hardware and inside your network, with a clear statement up front of what that constrains and what it costs to operate. You get the code, the weights where they are Lualdi Advisors' to give, and documentation written for the engineer who inherits it.
Questions
When should a company build custom AI instead of buying it?
When the problem is specific to the firm, its own data is the advantage, accuracy has to be proven on its own work, the data cannot leave the building, or no product fits the workflow. For common tasks that general tools already do well, buying is usually faster and cheaper.
Is custom AI development expensive?
It costs more up front than a subscription and carries running costs for hosting, monitoring and maintenance. Whether it pays depends on the value of the problem, the cost of the alternatives over several years, and what the firm gains by owning the result.
How do you know if a custom AI system works?
Test it on a held-out set of real cases with known answers that it never saw during development, using a measure agreed before the build began. A demonstration on chosen examples proves very little.
Who owns custom AI software?
That depends on the contract, so check it before signing. A sound arrangement hands over the code, the model weights where the developer has the right to give them, the test set, and documentation a new engineer can work from.
What is the difference between configuring and building AI?
Configuring adapts an existing product with your documents, settings and connections, while the vendor still owns and runs the core. Building creates a system around your problem that you own, at higher upfront cost and with the maintenance that ownership brings.
