Case: build our own video classroom or keep paying per minute?

Klasna pays a video vendor per minute, about 1.5 million UAH a year and growing. The engineers want to build their own classroom for 2,000,000 UAH. Leo's slide: "saves 4.6 million over five years, pays back in under three".

A make-or-buy decision compares two futures and keeps only the cash that differs between them. Each year, building means:

• no vendor bill: USD 0.45 a lesson, 18.90 UAH at 42 UAH per USD;
• own hosting: USD 0.10 a lesson, 4.20 UAH;
• upkeep: 600,000 UAH a year for engineers' time, monitoring and on-call.

Yearly saving = vendor bill − own hosting − maintenance.

Year 1 (80,000 lessons): 1,512,000 − 336,000 − 600,000 = 576,000.

Year 3 (104,000 lessons): 1,965,600 − 436,800 − 600,000 = 928,800 UAH.

Lessons grow by 12,000 a year, so the five savings rise: 576,000; 752,400; 928,800; 1,105,200; 1,281,600. They add up to 4,644,000, the "4.6 million" on the slide. The slip is to forget the upkeep: a platform you own needs people every year.

Leo's slide adds five years of savings without discounting and sets them against a build paid today: "2 million in, 4.6 million back". That comparison mixes money from different years as if it were the same money.

The build leaves now. The savings arrive one year at a time, and the biggest ones (1,105,200 and 1,281,600) come in years 4 and 5, when at 25% a hryvnia is worth about 0.41 and 0.33 of a hryvnia today.

So the right comparison is:

NPV = −2,000,000 + Σ saving in year t ÷ (1 + r)ᵗ.

At 25% the five savings are worth about 2.29 million today, not 4.6, and the build adds about 0.29 million of value, not 2.6.

The slide's other claim, "pays back in under three years", is plain payback: 2.72 years, also without discounting. In today's money the 2,000,000 is out for more than four of the five years.

Undiscounted totals are useful as a sense of scale. They are not a decision number. The slip is to put "total savings minus cost" on a slide and call it value.

Three kinds of cost appear around a business case, and each is treated differently.

• Incremental cash: changes because of the decision, such as the build, hosting and upkeep. It goes into the NPV.
• Sunk cost: already spent, whatever you decide now, such as last year's 300,000 prototype. It stays out.
• Opportunity cost: the value of the best alternative you give up. It isn't a payment at all, which is why it gets forgotten.

The four developers are on the payroll either way, so their salaries are not incremental. But their time is scarce. If they spend six months on the video classroom, the maths mock-exam mode waits, and that bet had a positive NPV of its own. The delay costs real value.

When the opportunity cost can be priced, include it. When it can't, name it in the memo as a risk or a condition: "the mock-exam mode waits a quarter; if it can't, keep paying per minute".

The slip is to treat anything already on payroll as free. Nobody's time is free; some people's next-best use just hasn't been written down.

The engineering spreadsheet also subtracts two more items: depreciation of 400,000 a year and the 300,000 prototype built last year. Neither belongs in the NPV.

Only incremental cash flows belong in a business case: cash that changes because of this decision.

In:

• the build, −2,000,000 in year 0, when it is paid;
• own hosting and maintenance, every year;
• the vendor fees Klasna no longer pays.

Out:

• Depreciation. It is the same 2,000,000 spread over five years in the P&L. NPV already counts the build as cash in year 0; subtracting depreciation pays for it twice and drags the NPV at 25% from +290,526.21 to −785,185.79.
• Sunk costs. The prototype was paid last year and stays paid whatever Klasna decides now.

Named, even if hard to price: opportunity costs, such as what the developers would otherwise build.

The test for any line: would this cash be different if we chose the other option? If not, it stays out.

Now bring the five savings to today and subtract the build. We stop at five years: after that the platform would need a rebuild anyway.

Factors at 25%: 0.8, 0.64, 0.512, 0.4096, 0.32768.

• 576,000 × 0.8 = 460,800;
• 752,400 × 0.64 = 481,536;
• 928,800 × 0.512 = 475,545.60;
• 1,105,200 × 0.4096 = 452,689.92;
• 1,281,600 × 0.32768 = 419,954.69.

Present value of the savings: 2,290,526.21. NPV = 2,290,526.21 − 2,000,000 = +290,526.21 UAH.

The "4.6 million of savings" is worth 2.29 million today, and after paying for the build the value added is about 0.29 million.

Which rate? Cutting a bill sounds like efficiency (25%). But building and running video in-house is a technical risk Klasna has never taken, which argues for 30%. At 30% the NPV is only +43,175.71, IRR 30.97%. Pick one, say why, and show what the other gives. The slip is to discount at a convenient rate, or to subtract the build from the undiscounted 4.6 million.

Leo's "pays back in under three years" is plain payback: running total of raw savings −2,000,000; −1,424,000; −671,600; then +257,200 in year 3, so 2 + 671,600 ÷ 928,800 = 2.72 years.

Discounted payback uses the savings in today's money instead. At 25%:

Year 5 needs 129,428.48 of 419,954.69, about 0.31 of the year: 4.31 years.

So in today's money the 2,000,000 is out for more than four of the platform's five years. If anything goes wrong late (a rebuild, a better vendor price, fewer lessons), there is little time left to recover. Notice the final running total equals the NPV. The slip is to quote the 2.72 years as if the money were safe after that.

When an assumption changes every year by the same amount, you don't need to rebuild the whole NPV. The change in NPV is:

yearly change × sum of the discount factors for those years.

At 25% over five years the factors add up to 0.8 + 0.64 + 0.512 + 0.4096 + 0.32768 = 2.68928. So one hryvnia a year for five years is worth about 2.69 hryvnias today.

If maintenance is 800,000 instead of 600,000, every yearly saving falls by 200,000:

change in NPV = −200,000 × 2.68928 = −537,856.

NPV = 290,526.21 − 537,856 = −247,329.79 UAH.

The same shortcut gives the break-even upkeep: the base NPV of 290,526.21 ÷ 2.68928 ≈ 108,031 a year of extra cost wipes the case out, so upkeep above about 708,000 a year turns it negative.

That makes upkeep one of the assumptions the memo must name, next to lesson growth and the build budget. The slip is to treat running costs as fixed facts: a platform's upkeep is a forecast too.

A positive NPV is only as good as the assumptions behind it. Sensitivity analysis changes one assumption at a time and watches the NPV at 25%.

• Lessons stay flat at 80,000: the saving is 576,000 every year. 576,000 × (0.8 + 0.64 + 0.512 + 0.4096 + 0.32768) = 576,000 × 2.68928 = 1,549,025.28, minus 2,000,000 = −450,974.72.
• Build runs 30% over (2,600,000): −309,473.79. The break-even build cost is the present value of the savings, 2,290,526.21: a 14.53% overrun wipes the NPV out.
• Hryvnia weakens 10%: both vendor and hosting are in dollars, but the vendor is more dollar-heavy, so the saving grows: +680,935.63.

Ranked by impact: growth (−741,501 from the base), then the build cost (−600,000 for a 30% overrun), then the currency, which helps. The prototype is sunk and moves nothing.

So the case rests on two things the memo must name: lessons growing by 12,000 a year, and the engineers holding the 2,000,000 budget. The slip is to present one NPV as if it were a fact.