The three shapes a project takes
Every AI initiative is one of three things, and confusing them is expensive. Each has a different cost curve, a different time to value, and a different way of going wrong.
Buy: a product that does the job
You purchase software that already does the thing — a claims-processing tool, a support-desk assistant, a document-review product with AI inside.
Fast to value, slow to fit. You get something working in weeks. It does the job the way the vendor decided, and you adapt your process to it or pay for customisation.
Cost is predictable and recurring, usually per seat or per volume, and it climbs with your success.
Risks: the fit gap between the product and your actual process, which is invisible in a demo and obvious in month two; lock-in, especially where your data now lives in their system; and dependence on a vendor whose category is consolidating fast.
Right when the task is standard across your industry and your requirements are not unusual.
Configure: assemble it from tools you have
You take general tools — an AI assistant, an automation platform, a document search product — and configure them into something that fits your process. No engineering, and a capable operations person can do it.
Slower to first value, much better fit, because you built it around your actual process rather than a generic one.
Cost is low and the effort is internal, which means it is real but does not appear in a budget line, and that has a way of hiding the true number.
Risks: it depends on the person who built it, so it walks out the door with them unless documented; it hits a ceiling; and it is easy to build something with no governance around it at all.
Right when your process is genuinely yours, volumes are moderate, and you want to learn what you actually need before committing money. For most teams of thirty this is the correct first move, and Build AI Tools Without Code is the practical version of it.
Build: engineer something
Developers build a system for your workflow, integrated with your systems, deployed and maintained.
Slowest to value, best possible fit, highest cost, and the cost is ongoing — software needs maintaining, and an AI system needs its outputs monitored for drift.
Risks: the usual project risks plus a specific one — teams routinely build the thing they specified rather than the thing they needed, because the specification was written before anyone had used a working version.
Right when volume is very high, the process is genuinely differentiated, integration is essential, or regulation demands control you cannot get otherwise.
The sequence that works
Configure first, then buy or build what proves itself.
Kavita's four tasks got exactly this treatment. Acknowledgement letters and complaint classification: configure, two weeks, almost no money. Claim file summarisation: configure a pilot, then evaluate buying, because there are products for it and the volume is enormous. Claim extraction into the system: needs integration, so it goes on the roadmap as a possible build once the configured version has proven the requirement.
The reason this order matters is that a configured version is the cheapest possible specification document. After six weeks of daily use you know what the fields should be, where it breaks, what the exceptions are, and what people actually do with the output. Buying or building against that knowledge is a different activity from buying or building against a meeting.
The question to ask about any proposal
What would we do if this vendor disappeared in eighteen months?
The category is consolidating and it is not an unreasonable scenario. If the answer is "we would export our data and use a different tool", fine. If the answer is "our process would stop", you are making a bigger decision than the invoice suggests, and it should be made deliberately.
Do this today: take your top-scoring task from lesson 2 and write one sentence for each shape — what buying it, configuring it, and building it would each look like. The one that is hardest to write is usually the one that does not fit.