Build, Buy or Wait: A Decision Rule for AI Investment in a Small Market

of custom enterprise AI tools reached production in MIT's 2025 study

5%

of AI projects fail according to RAND's 2024 review, about twice the rate of other IT projects

80%+

options on the ladder: use, buy, configure, build, wait

5

Sooner or later every management team reaches the same meeting. A vendor has shown a demonstration. A young engineer in the company says he could build the same thing in two months. The finance head says the accounting software is about to release something similar. The managing director's cousin, who works in technology abroad, says to wait a year because everything will be cheaper. All four are partly right, and the company has no rule for choosing between them.

This article offers one. It is written for a small market, where the usual advice from large economies needs adjusting. Nepal has few specialist vendors, limited local-language tooling, dollar-denominated prices, restrictions and paperwork on paying foreign suppliers, and a thin pool of people who can build and maintain AI systems. Those facts change the answer.

It is the third article in our series on artificial intelligence for business in Nepal, after the board questions and where the value is.

The evidence on building

The published evidence is hard on bespoke projects. RAND's 2024 review, based on interviews with experienced practitioners, concluded that more than 80 per cent of AI projects fail, about twice the failure rate of information technology projects that do not involve AI. The leading causes were not technical: misunderstanding of the problem to be solved, lack of the data needed, a focus on the technology over the problem, weak infrastructure, and problems too hard for the technology.

The 2025 study from MIT's NANDA initiative, which should be read as preliminary because its sample is modest and self-reported, found that of the organisations that evaluated custom or vendor-built enterprise AI tools, about 20 per cent reached a pilot and 5 per cent reached production. It also reported that tools bought from specialised vendors and partnerships succeeded about twice as often as those built internally. And it described a pattern any Nepali manager will recognise: while official projects stalled, staff at the great majority of firms were already using personal subscriptions to general tools for their daily work.

BCG's finding that 70 per cent of the effort in successful programmes goes on people and processes points the same way. If most of the work is organisational, the scarce resource is management attention, and spending it on building software that could be bought is usually a poor trade.

None of this says "never build". It says the burden of proof is on building.

The ladder: five options, not two

"Build or buy" hides the choices that matter most. There are five, and they form a ladder. A use case should sit on the lowest rung that solves the problem.

Rung 1: Use what is already inside your software. Accounting packages, spreadsheet and office suites, email, banking portals and enterprise systems now ship with AI features: reading a bill from a photograph, suggesting ledger codes, matching bank lines, drafting text, writing formulas, summarising documents. The company has usually paid for them already. Cost: almost nothing beyond learning. Risk: low, because the data stays where it already was.

Rung 2: Buy a specialist tool. A product built for one job: invoice capture and payables automation, expense management, demand forecasting, document review, customer support. Cost: a subscription, set-up and integration. Risk: the vendor.

Rung 3: Configure a general model on your own material. Take a general-purpose model through a business account and give it your documents and instructions: your policies, product catalogue, standard contracts, past management reports. No model is trained. The company writes prompts, connects documents and sets rules. Cost: modest, mostly the time of one capable person. Risk: accuracy and confidentiality, which need controls.

Rung 4: Build. Develop a system around the company's own data: a credit scoring model on years of repayment history, a forecasting model tuned to the company's products, a tool integrated deep into operations. Cost: high and continuing. Risk: delivery, maintenance and dependence on a few people.

Rung 5: Wait. Decide that the use case is not yet worth doing, and say when the decision will be revisited.

Most disappointments come from starting on rung 4 with a problem that rung 1 or 2 would have solved.

Four tests for placing a use case

Test 1: Is the problem specific to us?

Reading an invoice, reconciling a bank statement, drafting a letter and forecasting demand for packaged goods are problems every company has. Thousands of firms have funded the tools. A Nepali company gains nothing by solving them again.

A problem is specific when the answer depends on knowledge the market does not have: the repayment behaviour of small borrowers in a particular district, the hydrology of a particular river, the trekking season patterns of a particular route, the way a particular grade of yarn behaves on the company's machines. Specific problems are candidates for rung 3 or 4. General problems belong on rung 1 or 2.

Test 2: Do we own data that nobody else has, in usable form?

Building needs data in volume, with history, with the outcome recorded. A lender with ten years of loan files in a core banking system has it. A manufacturer with production logs on paper does not, whatever the value of the knowledge in its supervisors' heads. A distributor with three years of daily sales by item has enough to feed a bought forecasting tool, which is a rung 2 decision, but not usually enough to justify a model of its own.

The honest question is not "do we have data?" but "could we hand a clean table of it to someone tomorrow?" If the answer is no, the first project is the data, and it is worth doing regardless (data before algorithms).

Test 3: What does an error cost, and who would catch it?

Where an error is cheap and visible, a general tool with light review is fine: a draft email, a summary for internal use. Where an error is expensive or hidden, such as a credit decision, a tax computation, a medical triage message or a price, the company needs either a tool built and tested for the purpose or a firm human check, and usually both. High-stakes uses raise the cost of every rung and often tip the answer to "wait" until the controls exist (controls over AI-generated numbers).

Test 4: What does delay cost, against what waiting saves?

The price of AI capability has fallen fast and the quality has risen. A system built at great expense one year may be matched by a standard feature the next. That is the case for waiting.

The case against is that the gain forgone is real. If collections prioritisation would release a crore of working capital, a year's delay costs roughly ten lakh in interest at a 10 per cent borrowing rate. And an organisation learns by doing. A company that starts in a year will not start where today's adopters are now.

The resolution is to split the decision. Wait on anything expensive, bespoke and likely to be commoditised. Do not wait on cheap uses, on data, or on learning.

What is different in a small market

The ladder is universal. The conditions on each rung are not. Six features of the Nepali market deserve attention before any purchase.

Language and script. Much business material in Nepal is in Nepali, in Devanagari, often handwritten or stamped, and frequently mixed with English. General models handle Nepali text far better than they did, but accuracy on scanned bills, handwritten notes and legal Nepali is uneven and should be tested on the company's own documents, not assumed from an English demonstration. Ask the vendor to process fifty of your real bills and count the errors.

Calendar and statutory formats. The fiscal year runs from Shrawan to Ashadh. Dates are in Bikram Sambat. VAT invoices carry a PAN and follow prescribed formats, and large taxpayers issue them through approved billing software connected to the Central Billing Monitoring System (e-billing and CBMS requirements). A foreign tool that cannot handle a Bikram Sambat date, a PAN check or the 13 per cent VAT structure creates work instead of removing it.

The installed base. Many mid-sized Nepali companies run on desktop accounting software or locally developed systems, with operational data in separate billing tools and spreadsheets. Specialist AI tools are mostly designed to connect to cloud systems common in larger economies. Integration, which a brochure describes in one line, can be the largest cost. Ask exactly how data gets from your system to the tool and back, and who maintains that link.

Paying foreign vendors. Subscriptions to foreign software are paid in foreign currency through banking channels, subject to Nepal Rastra Bank's rules and documentation, and the limits on card payments are low relative to enterprise software prices. Payments to a non-resident raise withholding tax under the Income Tax Act and reverse-charge VAT questions that are better settled before the contract than at the audit (TDS on foreign vendor payments). A tool that the company cannot reliably pay for is not a dependable part of a process.

Vendor depth. A local vendor understands the statutory formats and will come to the office. It may also be five people, with one who understands the AI component. A foreign vendor has depth but will not prioritise a small account in a small country. Neither is wrong. Both need an exit plan.

People. Engineers who can build and maintain AI systems are in demand abroad and from exporters paying in dollars. A system built in-house by two people is hostage to their staying. The 2083/84 budget's promise of a sovereign compute centre and subsidised compute for startups addresses hardware. It does not address this constraint, which is the binding one.

The real cost of each rung

Illustrative first-year costs for a mid-sized company, to show proportions and not prices. Actual quotations vary widely.

The line most often missed is maintenance on rung 4. A model is not a machine that is installed and depreciated. The world it describes changes: customers behave differently after an interest rate move, a festival shifts, a product is replaced. A model that is not monitored and retrained degrades quietly. Budget a recurring 20 to 30 per cent of the build cost each year, or do not build.

If you buy: the contract matters more than the demonstration

When a company buys, it exchanges delivery risk for contract risk. A short checklist, to be answered in writing by the vendor before signing:

For banks, financial institutions and payment providers these are not only good practice. Nepal Rastra Bank's AI Guidelines, as reported, permit third-party and ready-made tools for internal drafting, summarising and analysis, and expect each system to be classified by risk, governed within the institution's risk framework and overseen by the board. An institution cannot outsource that accountability to a vendor.

The Individual Privacy Act 2075 applies to any tool that processes personal information, wherever the server sits. Nepal's rules on cross-border data are thin, which leaves the burden on the contract.

If you configure: the middle path most companies overlook

Rung 3 deserves more attention than it gets. For a company with good documents and an able analyst, a general model through a business account can be set up to:

No model is trained and nothing is built that cannot be abandoned. The work is in writing clear instructions, curating the documents, testing the answers against known cases, and restricting access. The MIT study's observation that staff succeed with general tools while enterprise projects stall is an argument for this rung: formalise what already works.

The limits are equally clear. The model does not know Nepali tax law reliably and will state wrong rates with confidence unless the correct sources are supplied and the output checked. It should draft, not decide.

If you build: when it is the right answer

Building is right for a minority of cases, and they share features.

The data is proprietary, large and labelled. A commercial bank's repayment history. A telecom operator's network and usage data. An insurer's claims. A large retailer's basket data.

The use is central to the business. Credit decisions for a lender. Yield for a process manufacturer at scale. Dispatch for a power producer.

The stakes justify proper engineering. Testing, monitoring, documentation, a fallback and independent validation.

The company can keep the team. Or has a partner who will maintain the system under a contract that survives staff turnover.

There is one further group for whom building is the business: Nepal's IT and business process exporters. For them the question is not whether to build for internal use but how to build for clients abroad, and how to move from selling hours to selling outcomes as the tools compress the hours (Nepal's AI opportunity).

Even where building is right, build narrowly: the scoring model, not a platform. Buy everything around it.

If you wait: do it actively

Waiting is a decision with a date attached. A sound "wait" has three parts.

Keep collecting. Record the data the future use will need, in the form it will need it: outcomes, dates, reasons. A lender that starts recording why each loan was declined is building an asset. A hospital that codes diagnoses consistently is doing the same.

Keep learning. Use rungs 1 and 3 freely so that staff develop judgement about what the tools do well and badly.

Set the trigger. State what would change the decision: a price, a feature, a regulation, a competitor's move, a data milestone. Put the review in the board calendar.

A "wait" with none of these is neglect.

A worked decision

An illustration, not a client case. A company running three private hospitals considers four ideas.

*Reading and coding supplier invoices.* General problem, usable data. Rung 1 if the accounting system offers it, otherwise rung 2. Decision: use.

*A patient-facing symptom chatbot.* The error cost is severe, regulation of medical advice by software is undeveloped, and the reputational risk is high. Decision: wait, with a review when professional and regulatory guidance exists.

*Predicting insurer claim rejections before submission.* Specific problem: the rejection patterns of local insurers. The company has three years of claims with outcomes. Decision: configure first, by supplying past rejection reasons to a general model that checks each claim against them. If the gain is proven, consider building.

*A staff assistant for clinical and administrative protocols.* The documents exist. Decision: configure, with access limited to staff and a clear notice that it is a reference, not an instruction.

Four ideas, four rungs, no model built in year one. The value would come mainly from the third, which is the one that depends on data the hospitals already own (finance and tax for hospitals and clinics).

The role of consulting and advisory firms

On this decision the large firms' roles are worth understanding, because they are not all the same thing.

Strategy firms such as McKinsey and BCG publish the research that frames the choice and advise large clients on portfolios of use cases. The Big Four accounting networks combine advice with implementation and assurance, and have formed deep alliances with major technology vendors. Several announced investments of a billion dollars or more in 2023. Those alliances bring real capability. They also mean the adviser is seldom neutral between platforms, and a buyer should ask which vendors an adviser has commercial ties to. System integrators and local software houses implement. Their incentive is the size of the build.

In Nepal the supply of advice is thinner: local member firms of the international networks, a handful of technology consultancies, software vendors who advise as part of selling, and finance advisers such as ourselves. For a mid-sized company the practical question is who will tell it honestly which rung a use case belongs on.

A vendor-neutral adviser is useful at four points: sizing the gain before any vendor is called; writing requirements in business terms; testing shortlisted tools on the company's own documents and data; and reviewing the contract and the controls. The adviser should have no commission from the vendor. Ask.

Our own role is on the finance foundations and the business case: process automation using tools the company already has, data and reporting, and financial modelling of the investment. Where a use case needs specialist engineering, we say so and help the company brief and evaluate those who do it.

The next 90 days

Days 1 to 30. List the AI features in software the company already pays for and switch on the ones that apply. List candidate use cases and place each on the ladder using the four tests. Expect most to land on rungs 1 to 3.

Days 31 to 60. For any rung 2 candidate, shortlist two or three tools and test each on fifty real documents or three months of real data. Send the ten contract questions. For any rung 3 candidate, give one capable person two days a week to configure and test.

Days 61 to 90. Decide. Sign with an exit clause. For anything on rung 5, record the data to be collected and the trigger for review. Report the portfolio to the board on one page: use case, rung, owner, cost, expected gain, review date.

Frequently asked questions

*This article is general guidance, not legal, tax or procurement advice. Cost ranges are illustrative. Regulatory points are summarised from published sources and press reports as of November 2026 and should be confirmed against the original documents.*