Why This Matters

If you are commissioning a learning-video product, the moment that decides whether the project succeeds or quietly fails is not the launch — it is the estimate. A number that is too low gets the project funded and then strands it half-built; a number with no range behind it gives you no way to tell a careful vendor from an optimistic one. Most software projects overrun: across decades of industry data, the average cost overrun has run around 189% of the original estimate and the average schedule overrun around 222%, and only a minority of projects finish on time and on budget. This article is written for the non-engineer who has to turn an idea into a scope and a budget — an L&D director, an EdTech founder, a product manager, a training lead — and it gives you the same scoping and estimation method a good engineering team uses internally, so you can produce or pressure-test a number yourself. It stays accurate enough that the engineer and the delivery manager who build from your scope will respect it.

Scope First — You Cannot Estimate a Fog

Estimation gets all the attention, but the expensive mistakes happen one step earlier, in scoping. Scoping is the act of turning a vague intention into a bounded, written list of exactly what the product will and will not do. Until that list exists, any number attached to the project is fiction, because the people quoting it are each imagining a different product.

Consider the sentence a project usually starts with: "We want a platform where employees watch training videos and we can see who completed them." That single sentence hides a dozen forks, and each fork changes the cost by tens of thousands of dollars. Are the videos recorded once and watched on demand, or are there live classes? Is "watched" enough, or do learners answer questions inside the video? Does completion need to flow back into the company's HR system, or just show on a dashboard? Is there a phone app, or only a website? Must it pass an accessibility audit? None of these are answered by the opening sentence, and every one of them is a scope decision that must be made before a number means anything.

The most useful tool here is the in/out list: a literal two-column list of features, where every candidate feature is assigned to "in" (we are building this now) or "out" (not in this version). A feature parked in "out" is not abandoned; it is scheduled for a later phase, which keeps the first number honest. The discipline of forcing every idea into one column or the other is what converts an idea into a scope. The companion worksheet at the end of this article gives you that list as a starting grid.

Closely related is the idea of a minimum viable product, or MVP — the smallest version of the product that delivers real value and lets you learn from real users, deliberately leaving advanced features for later. For a learning-video platform an MVP might be web-only, use an off-the-shelf player, track simple completion, and skip live classes, mobile apps, and deep integrations entirely. An MVP is not a cheap version of the full product; it is a different, smaller scope chosen on purpose. Naming what is in the MVP and what waits is the single highest-impact scoping move you can make, because it lets you ship, learn, and estimate the rest with far less uncertainty.

A pipeline showing how a vague idea becomes a defensible estimate: idea, scope and in/out list, feature-to-effort map, four multipliers, and an estimate range plus timeline Figure 1. The path from idea to number. Each stage removes uncertainty: a bounded scope feeds a feature-to-effort map, four multipliers adjust it, and the output is a range and a timeline — never a single guarantee.

The Two Numbers Under Every Estimate: Effort and Time

Before any method, fix one distinction that trips up almost every first-time buyer: effort and duration are not the same thing. Effort is how much work a task takes, measured in person-time — person-days, person-weeks, or person-months. Duration is how long it takes on the calendar, which depends on how many people work in parallel and how much they wait on each other.

A task that is ten person-weeks of effort does not take ten calendar weeks if five engineers can work on independent parts at once — but it also does not take two calendar weeks, because some parts must be done in order (you cannot test the player before the player exists) and people are never 100% productive on one project. The rule of thumb good teams use is that calendar time runs longer than the naive "effort ÷ people" division, because of coordination, review, meetings, and the parts that simply cannot be parallelized.

Money follows effort, not duration. You pay for person-time. So the chain of every estimate is: scope → effort (person-weeks) → cost (effort × a blended rate) → duration (a calendar plan that respects ordering and team size). Keep these separate and you will never again be surprised that "three months" and "three engineers for three months" are wildly different prices.

A quick word on rate, because it sets the whole scale. Blended developer rates in 2026 vary by region by roughly 4×: North America and Western Europe run about $100–$200 per hour, Eastern Europe about $40–$80, and South and Southeast Asia about $25–$50. The same scope, estimated in the same person-weeks, produces a very different invoice depending on where the team sits — which is why effort (person-weeks) is the portable part of an estimate and dollars are not.

The Building Blocks: A Feature-to-Effort Map

The heart of a bottom-up estimate is a feature-to-effort map: you break the product into recognizable building blocks, attach a realistic effort and cost range to each, and add them up. A learning-video platform decomposes into the same handful of blocks almost every time. The ranges below are 2026 build figures for a professional, custom platform; they are the same blocks used in the cost model, shown here as the inputs you sum during estimation.

Building block Typical build cost What moves it
Discovery & design $3,000–$25,000 Brand polish, UX research, number of screens
Interactive video player $15,000–$60,000 Quizzes, branching, per-second tracking
Tracking layer (SCORM/xAPI) $10,000–$40,000 Which standards, an LRS, reporting depth
Each integration (SSO, LMS, HR, payments) $5,000–$30,000 each Count and complexity of systems
Native mobile app $15,000–$75,000 A second client; iOS + Android
Data migration $2,000–$8,000 Volume and messiness of existing data
Admin, QA, project management 25–40% on top Wraps everything above

Two things in that table catch people out. First, integration cost is "each," not total — the word "integrations" in a brief hides a multiplier, because three integrations cost roughly three times one. Second, the last row is not a feature at all, yet it is real money: building the visible features is only part of the job, and the testing, admin tooling, and coordination that wrap them routinely add a quarter to a third again on top. An estimate that lists only the shiny features and forgets this row is low by design.

A horizontal bar chart of learning-video build blocks with cost ranges, and the four multipliers that scale the total Figure 2. The building blocks of a learning-video build, with 2026 cost ranges, and the four multipliers (live, interactivity, integration count, non-feature work) that scale the sum up or down.

The Four Multipliers That Move the Number Most

Two learning-video projects with the same one-sentence description can differ in price by 5×. The difference is almost always in four scope decisions. Treat these as the questions to settle first, because each one multiplies the building-block sum rather than adding to it.

1. Live versus on-demand — the biggest single swing

On-demand video is, in engineering terms, the cheap kind: you encode each video once, store it, and stream it through a content-delivery network. Live video — a real-time virtual classroom — is a different and far larger build. It runs on WebRTC (Web Real-Time Communication), the browser-native standard for real-time audio and video that became a W3C Recommendation in 2021, and a group class routes everyone's stream through a media server called a Selective Forwarding Unit (SFU). The hidden work is in everything around that: a signaling server to connect participants, STUN and TURN servers for network traversal, and the data-transfer bill, which is the largest and least predictable running cost of live video. Industry practitioners are blunt that configuring an SFU, STUN/TURN, and signaling, then testing across real networks, is "a multi-week effort at minimum" — before you have written a single learning feature.

The practical estimation rule: if live classes are in scope, they are not a small add-on; they are a second product wired to the first. This is also the clearest build-versus-buy fork in the whole project. Embedding a real-time video API (a CPaaS) — billed at roughly $0.004 per participant-minute in 2026 — turns weeks of infrastructure work into days of integration, at the cost of a per-minute fee forever. Building your own live stack only pays off at large, sustained scale. The deeper engineering lives in WebRTC for live learning and scaling the live class; for scoping, the only question is whether live is in or out, because the answer can double the build.

2. How interactive the video is

A video that only plays is cheap. A video the learner acts inside — answering in-player quizzes, taking branching paths, clicking hotspots — is the "interactive video player" line, and its range ($15,000–$60,000) is wide precisely because "interactive" spans a lot. A simple quiz overlay is modest; a true branching scenario, where the video changes based on choices, is among the most effort-heavy features in learning video, because every path must be authored, the player must track state, and the analytics must make sense of which paths learners took. When a brief says "interactive," your estimation job is to pin down which interactions, because the word alone can swing this block by 4×. The mechanics are detailed in what makes video interactive and branching scenarios.

3. How many systems you integrate with

Every integration is a scope line with its own cost, because each external system speaks its own language and breaks in its own way. In learning video these usually mean a standard or a system you must conform to, and each one is genuine engineering:

  • A learner sign-in that uses the company's existing accounts — single sign-on via SAML or OIDC — so people do not get a new password.
  • Tracking that an LMS can read. The fixed-data-model standard for packaging a course so any learning system can play and record it, called SCORM (ADL), tracks completion, score, and time inside an LMS launch. The richer modern standard, the Experience API (xAPI 1.0.3, ADL), records granular events as statements into a Learning Record Store (LRS) — which is itself a component you must stand up.
  • Launching your tool inside someone else's LMS. Learning Tools Interoperability (LTI 1.3, 1EdTech) does this with an OIDC-based launch and a signed token — it is a trust handshake, not a password login, and implementing it correctly is real work.

The estimation point is mechanical and easily missed: count the integrations, then multiply. A brief that says "integrates with our systems" is hiding a number. Pin the number down — two? five? — because at $5,000–$30,000 each, it is one of the largest levers in the whole estimate. The standards themselves are explained in SCORM explained, xAPI explained, and LTI explained.

4. The non-feature work: scale, platforms, accessibility, security

The fourth multiplier is everything that is not a feature on a screen but is still real effort. Supporting a phone app as well as a website is effectively a second client to build and maintain ($15,000–$75,000). Designing for a large, growing audience adds architecture work. Security and privacy hardening — necessary the moment you hold learner data — is its own line. And accessibility is not optional for many buyers: meeting WCAG 2.1 Level AA (the W3C accessibility standard, with Success Criterion 1.2.2 requiring captions for prerecorded video) is mandated by law across much of the public sector and large enterprise. Each of these is a scope decision that scales the whole estimate, and each is routinely discovered after the quote rather than before. The honest move is to decide them during scoping and price them in. (Accessibility scope is detailed in WCAG 2.1 AA for educational video.)

How to Actually Produce the Estimate

With a scope and a feature map in hand, you turn it into a number. There is no single correct method; good teams combine three, and all three reject the idea of a single guarantee.

Relative sizing (story points). Rather than guess hours for each task up front, agile teams size tasks relative to each other — "this feature is about as big as that one we built last sprint" — using an abstract unit (story points, often on a 1, 2, 3, 5, 8, 13 scale). The team estimates together, frequently with planning poker, where everyone reveals a card at once so no one anchors the group. Over a few sprints the team learns its velocity — points completed per sprint — and that converts points into a calendar. Relative sizing is powerful because humans are far better at saying "bigger or smaller than that" than at guessing absolute hours.

Three-point estimation (PERT). For any single block, do not write one number — write three: an optimistic case (O, everything goes well), a most-likely case (M), and a pessimistic case (P, things go wrong). The expected value uses the PERT (Program Evaluation and Review Technique) formula, which weights the most-likely case heavily:

Expected effort  E = (O + 4M + P) / 6
Uncertainty (SD)  ≈ (P − O) / 6

Worked example for the tracking layer: optimistic 4 person-weeks, most-likely 6, pessimistic 12.

E = (4 + 4×6 + 12) / 6 = (4 + 24 + 12) / 6 = 40 / 6 ≈ 6.7 person-weeks
SD ≈ (12 − 4) / 6 ≈ 1.3 person-weeks

So you plan around 6.7 person-weeks, and the spread (±1.3) tells you how confident to be. Three-point estimation does two jobs at once: it produces a more realistic expected value than a single guess, and it surfaces how uncertain each block is, which is exactly the information a single number throws away.

Reference-class forecasting (the outside view). The most reliable correction for human optimism is to stop looking only at your own project. People estimate by imagining the steps of this project — the "inside view" — and systematically underestimate, a bias Kahneman and Tversky named the planning fallacy. The fix, reference-class forecasting, is to look at the actual outcomes of a class of similar finished projects — the "outside view" — and start from their real distribution. In practice: ask your vendor what their last three comparable learning-video builds actually cost and took, not what they hope yours will. When a confident bottom-up number and the reference class disagree, trust the reference class; finished projects do not suffer from optimism.

Why a Single Number Is Always Wrong: The Cone of Uncertainty

Put the three methods together and you arrive at the most important idea in estimation: a responsible estimate is a range, and the range is widest at the start. This is the Cone of Uncertainty, a well-established pattern (popularized by Steve McConnell from earlier work by Barry Boehm). At the initial-concept stage — before scoping is done — estimates are realistically accurate only to within about 0.25× to 4× of the eventual actual. That is not incompetence; it is a 16-fold spread baked into how little is known at the start. As scope is locked, requirements are detailed, and design is done, the cone narrows: to roughly ±50% after the product is defined, to about ±25% once requirements are complete, and tighter still as work proceeds.

A cone-of-uncertainty chart showing the estimate range narrowing from 0.25x-4x at concept to plus or minus 25 percent at requirements complete and converging at delivery Figure 3. The Cone of Uncertainty. Early estimates carry a ~16× spread; the range narrows only as scoping, requirements, and design remove unknowns. A single number quoted before scope is locked is hiding this cone, not escaping it.

The practical consequences are concrete. First, anyone who quotes a precise single number for an unscoped project is either guessing or hiding the range — ask for the range. Second, the way to a tighter number is not pressure; it is information — invest in a paid discovery and design phase, and the cone narrows as a result. Third, a contingency buffer (commonly 15–25% on a reasonably scoped build) is not padding; it is the named, visible width of the cone at that stage. Padding is a secret cushion inside each task; contingency is an explicit line that says "this is how much the unknowns are worth right now." Show it, do not bury it.

A Worked Example: From Idea to $180,000 and Seven Months

Let us build the number used throughout the cost model: a professional custom learning-video platform with an interactive player, xAPI tracking, two integrations (SSO and an HR system), a basic live-classroom capability, a web client, and a light mobile app. We will estimate effort per block with three points, convert to cost at a blended $100/hour (≈ $4,000 per person-week), and then lay it on a calendar.

Block O M P PERT effort (wk) Cost @ $4k/wk
Discovery & design 3 4 7 4.3 $17,200
Interactive video player 7 10 16 10.5 $42,000
Tracking layer (xAPI + LRS) 4 6 12 6.7 $26,800
Integration 1 — SSO 2 3 6 3.3 $13,200
Integration 2 — HR system 3 5 9 5.3 $21,200
Basic live classroom (embedded API) 3 5 10 5.5 $22,000
Light mobile app 4 6 11 6.5 $26,000
Feature subtotal 42.1 wk $168,400

The features sum to about 42 person-weeks and $168,000. Now the non-feature work that wraps it — call it 25% for QA, admin tooling, and project management on a tightly scoped build — but here we have already kept the per-block estimates lean, so instead of stacking a flat 25% we add a contingency buffer of about 7% to reach a defensible round figure. The result lands near $180,000, matching the cost model's worked build. Notice that no single block is the whole cost; the estimate is the sum of sized blocks, which is exactly why scoping each block matters.

Turning 42 person-weeks of effort into a calendar: with a small team of three to four engineers plus a designer working partly in parallel — design first, then player and tracking together, integrations and live and mobile overlapping, then a hardening-and-test phase that cannot be rushed — the realistic duration is about seven months, not the ten weeks a naive "42 ÷ 4" division would suggest. The gap between those two numbers is the coordination, review, and sequencing that effort-divided-by-people always ignores.

A worked estimate: feature blocks summed by three-point PERT to about 180,000 dollars, with a seven-month timeline strip showing overlapping phases Figure 4. The worked example. Each block is sized with a three-point (PERT) estimate, the blocks sum to ~$180,000, and 42 person-weeks of effort becomes about a seven-month calendar once parallel work and a test phase are laid out.

Don't Forget the Bill That Never Stops

A scope that prices only the build is incomplete, because a learning-video platform has a second cost half that grows every month you have learners: video delivery, live-session minutes, storage, captions, and hosting. For a 5,000-learner platform that recurring bill runs roughly $24,000–$55,000 a year — and over three years it can equal or exceed the entire build. Scoping must therefore include a run-cost estimate, not just a build estimate, and the build-versus-buy math depends on both. The full arithmetic, and a spreadsheet to run your own numbers, are in the learning-platform cost model; for scoping, the rule is simply that "what does it cost?" has two answers and you must give both.

Common Mistakes

Quoting a single number for an unscoped project. The most common and most damaging error. Before scope is locked, the honest output is a range (the cone is ~16× wide at concept). A precise single number that early is a guess wearing a suit. Ask for the range and the assumptions behind it.

Pricing only the build and forgetting the run. A team funds a $180,000 build, launches, and meets a video bill nobody modeled. Estimate both halves or the project runs out of money in production, not development.

Hiding padding instead of showing contingency. Padding each task secretly destroys trust and gets competed away; a visible contingency line, sized to the cone's current width, is defensible and survives scrutiny. Same money, opposite credibility.

Missing the integration multiplier. "Integrates with our systems" is not one line item. Count the systems and multiply — three integrations cost roughly three times one, and this is where briefs most often understate scope.

Estimating from the inside view only. Imagining the steps of your own project guarantees optimism (the planning fallacy). Anchor every estimate against what comparable finished projects actually cost and took.

Where Fora Soft Fits In

Scoping and estimating a learning-video product well is mostly a function of having built the same shapes before — the reference class is the asset. Fora Soft has built video conferencing, streaming, e-learning, telemedicine, OTT, and surveillance software since 2005, across 239+ shipped projects, so a learning-video estimate is grounded in what comparable builds actually took, not an optimistic inside view. On the build-versus-buy forks that move the number most — especially live video, where embedding a real-time API versus building an SFU stack can change the budget by an order of magnitude — that experience is the difference between a number you can fund and a number that strands the project. The honest deliverable is a scoped range with the assumptions visible, not a single figure that hides the cone.

What to Read Next

Call to action

References

  1. Aalpha. LMS Development Costs — 2026. https://www.aalpha.net/articles/how-much-does-it-cost-to-develop-lms/ — Tier 4 (vendor engineering). Build tiers (MVP $8k–$15k in 2–4 months; professional $20k–$60k; enterprise $50k–$100k+; custom LMS $8k–$500k+), design $3k–$25k, migration $2k–$8k, mobile $15k–$75k, build-on-platform 25–60% cheaper, timelines 6 weeks–10 months.
  2. Steve McConnell. Software Estimation: Demystifying the Black Art (Microsoft Press / Construx). https://www.construx.com/books/software-estimation/ — Tier 3 (standards-author/practitioner). The Cone of Uncertainty: ~0.25×–4× spread at initial concept narrowing to ±25% at requirements-complete; effort vs duration; counts-as estimation discipline. Originating work: Barry Boehm, Software Engineering Economics (1981).
  3. Project Management Institute. PERT / three-point estimating. https://www.pmi.org/ — Tier 5 (professional body). Beta-PERT expected value E = (O + 4M + P)/6; standard deviation ≈ (P − O)/6; triangular mean = (O + M + P)/3.
  4. D. Lovallo & D. Kahneman. Delusions of Success: How Optimism Undermines Executives' Decisions, Harvard Business Review (2003); Kahneman & Tversky (1979), the planning fallacy and reference-class forecasting. https://hbr.org/2003/07/delusions-of-success-how-optimism-undermines-executives-decisions — Tier 5 (peer-reviewed/research). The inside vs outside view; reference-class forecasting as the correction for systematic underestimation.
  5. The Standish Group. CHAOS Report. https://www.standishgroup.com/ — Tier 5 (industry research). Software-project outcomes: a minority succeed on time and budget; historical average cost overrun ~189% and schedule overrun ~222%; large projects succeed far less often than small ones. Figures vary by edition and methodology.
  6. WebRTC.ventures (Hector Zelaya). How Much Does It Really Cost to Build and Run a WebRTC Application? (2025-10). https://webrtc.ventures/2025/10/how-much-does-it-really-cost-to-build-and-run-a-webrtc-application/ — Tier 3 (first-party engineering). Live-video build is multi-week minimum (signaling + SFU + STUN/TURN + NAT testing); data transfer is the largest variable cost; CPaaS ≈ $0.004/participant-minute; build-vs-buy guidance.
  7. W3C. WebRTC: Real-Time Communication in Browsers (W3C Recommendation, 2021; maintained 2025). https://www.w3.org/TR/webrtc/ — Tier 1 (primary standard). Browser-native real-time audio/video/data behind live virtual classrooms; group calls route via an SFU.
  8. ADL Initiative. Experience API (xAPI), Version 1.0.3. https://github.com/adlnet/xAPI-Spec — Tier 1 (primary standard). Granular learning events recorded as statements to a Learning Record Store (LRS); the LRS is a component to budget. xAPI is the standard; "Tin Can API" was the project name.
  9. ADL Initiative. SCORM (Sharable Content Object Reference Model), 1.2 and 2004 4th Edition. https://adlnet.gov/projects/scorm/ — Tier 1 (primary standard). A fixed data model (completion, score, time, limited interactions) tracked inside an LMS launch — what "tracking" scope means at the package level.
  10. 1EdTech (formerly IMS Global). Learning Tools Interoperability (LTI) 1.3 & LTI Advantage. https://www.1edtech.org/standards/lti — Tier 1 (primary standard). OIDC-based launch with a signed JWT for trusted SSO into an LMS — a trust handshake, not a password login; an integration scope line.
  11. W3C. Web Content Accessibility Guidelines (WCAG) 2.1, Level AA. https://www.w3.org/TR/WCAG21/ — Tier 1 (primary standard). Success Criterion 1.2.2 (Captions, Prerecorded) and the AA bar mandated across much of the public sector — an accessibility scope line, not an afterthought.
  12. Mountain Goat Software (Mike Cohn). Agile Estimating with Story Points; Planning Poker. https://www.mountaingoatsoftware.com/agile/agile-estimation — Tier 5 (practitioner). Relative sizing, the Fibonacci scale, planning poker to avoid anchoring, and velocity to convert points to a calendar.

Where sources disagreed, the official standard won. The standards and accessibility claims (WebRTC, xAPI 1.0.3, SCORM, LTI 1.3, WCAG 2.1 AA) are grounded in the issuing bodies' own documentation, not vendor paraphrases — notably the LTI "OIDC + signed JWT, not a password login" framing and the SCORM "fixed data model, not everything" distinction. Cost ranges are 2026 vendor/market figures and vary by region and methodology; the overrun statistics are widely cited industry research whose exact figures differ by edition — they are used directionally, to argue for ranges over single numbers.