What is the real choice between build and buy?
Every AI project starts with the same question: do we buy something that exists or build something for us? Vendors will say buy. Builders will say build. Both answers are partly self-interested, so it helps to have a clear way to decide that starts from your own work and not from a product demo.
Buying is fast and cheap to start. You get a working product, support and updates, and you share the cost with other customers. But the product is built for the average customer, so you adapt your work to it, and your data, rules and integrations sit within what it allows. Building costs more at the start and needs care afterwards. In return it fits how you work, connects to the systems you already use and belongs to you. Neither is better in general. The right answer depends on the task.
What does buying give you?
A handful of criteria settle most cases. Here are the ones we use with companies.
What does building give you, and cost?
Four criteria come up again and again.
- How specific the work is to you
- How well it integrates with your tools
- Who owns the result and how easily you can leave
- The full cost over time, including usage, upkeep and the time your own team spends
None of these is a reason to build by default. A bought tool that covers most of the need and connects cleanly is often the right call. If the gap is small, adapt the process. If the gap is where your advantage lies, that is where custom work belongs. The decision is made task by task, not for the whole company.
How does integration change it?
Integration is where many projects succeed or fail. A product that sits apart from your systems creates new copying. Consider the following.
- Can it read from and write to the systems your team already uses?
- Does it respect your existing permissions, so people see only what they should?
- Can you see what it did, and undo it if it goes wrong?
Good answers here save weeks later. If a vendor cannot explain how it connects to your systems, assume the work of connecting it falls to your team.
Who owns what you end up with?
Ownership is easy to ignore at the start and expensive to fix later. With a bought product you rent access. If the price rises or the vendor changes direction, you may be unable to take your workflows with you. With a custom build, ask who holds the code, the prompts and the data.
Whichever route you take, ask how you would leave. A clear exit plan keeps the relationship honest and your options open.
What about vendor lock-in?
Lock-in and upkeep are where costs hide.
What does upkeep involve?
With a bought tool, the price is visible but usage charges, extra seats and add-ons can grow. With a custom build, the first cost is higher, and there is ongoing upkeep as models, tools and your own processes change. Either way, count training and the time your own staff spend reviewing the output. Compare the total over a few years, not the first invoice.
And the real cost?
A hybrid is often the best answer. Buy a general assistant, a meeting recorder or a ready-made support tool where the need is common. Build the connections between them and the custom steps that carry your rules: how an enquiry is classified, which approval it needs, where the result is stored. The hybrid keeps the custom part small and gives you control where it matters. Nobody has to retype anything between the parts, which is the point.
What are the risks of each?
The main risk of buying is fit. You may pay for features you do not use and still copy between screens. Check this with a real task, not a demo.
The main risk of building is upkeep and scope. A custom solution needs an owner, testing and review, and it can grow beyond what it was meant to do. Keep the first version narrow. AI supports your people and does not replace their judgement.
Where should you start?
- Pick one slow, repetitive task rather than the whole company
- Write down how long the task takes now and how often it goes wrong
- Name one person responsible for the result
What is the Embedded Week?
- We sit with your team for a week and watch how work really moves between your tools
- We map the hand-offs, copying and waiting that cost time
- We then show what to buy and what to build, and build the custom parts for your company
- We train your team to run it, so it keeps working long after the week ends
The Embedded Week is how Arclight works. We spend a week with your team, see the spreadsheets, inboxes and tools for ourselves, and map where the time goes. We then show you what to buy and what to build, create the custom parts and train your people to run them. To talk it through, book a meeting and we will tell you plainly whether it suits you.
Is a hybrid better than choosing one side?
A bought product is a good place to start. It can summarise a document or draft an email. But it does not know your templates, your approval steps or where your records live, so people end up copying between it and your real systems.
A custom layer is built around how you already work. In practice it can typically connect the following.
- Your own templates
- Policies
- Your approvals
- Your data stores
It will not replace your people. It takes the copying and chasing away from them.
For most companies that is the right balance: a solution that fits your work without a long, generic rollout. The Embedded Week is how we find out what to build and what to buy. We start from what your team actually does, not from a product demo, and finish by training your people.
Build or buy: your questions
Questions that companies ask most often when deciding whether to build or buy AI, with short answers.
Should we build or buy?
Buy when the task is common and a product fits your tools. Build when the work is particular to you or the product forces you to change how your team works. Many companies do both.
What does a hybrid approach look like?
You buy general-purpose tools for general tasks, and build a custom layer for the steps that are yours: your rules, your systems, your approvals. The two are connected, so work flows between them.
When does custom AI pay off?
When the same slow work repeats often, runs across several systems and follows rules a generic product does not know. The more hours it costs each week, the sooner a custom solution pays back. Count upkeep as well.
Who owns a custom AI solution?
It depends on what you agree. Settle in writing whether your company owns the code, prompts, data and configuration, or at least has full access and the right to move. Ask any vendor the same question, and have your own adviser check the terms.
How does Arclight help us decide?
Through the Embedded Week. We sit with your team for a week, watch how work really moves between your tools, and map where the time goes. We then show what to buy and what to build, create the custom parts and train your people to run them.
