Digital Services ROI: What a Product Actually Costs to Build, Run, and Improve

Digital Services ROI: What a Product Actually Costs to Build, Run, and Improve

A founder asks, "What will this digital product cost?" and receives a number that answers only the easiest part of the question.

The quote may cover design and development. It may even include a launch. It usually does not tell you how much time your team must supply, what the product will cost to operate, which assumptions could make the business case fail, or when you will know whether the investment worked.

That is why two apparently similar proposals can produce very different outcomes. One team is pricing a deliverable. The other is helping you run a measurement exercise that happens to include software.

This article offers a more useful model. Treat it as a planning framework for a mobile app, web application, internal tool, or growth system — not as a universal price list. The goal is not to make the return look impressive. It is to make the decision defensible.

Start with the full cost, not the development quote

Put the investment into four columns before comparing vendors:

1. Build cost: discovery, product definition, UX, engineering, QA, launch preparation, and project management.
2. Internal cost: the hours your team contributes for decisions, subject-matter expertise, access, approvals, data work, training, and adoption.
3. Run cost: hosting, observability, third-party APIs, software subscriptions, security work, support, content, and iterative improvements.
4. Cost of delay: revenue or operational capacity that remains unavailable while the problem is unresolved.

The fourth column is not permission to invent urgency. It is a prompt to quantify the status quo honestly. If a manual process consumes 80 hours every month, that is part of the current cost. If a missed launch window would affect a seasonal channel, write down the assumption and test it rather than presenting it as a certainty.

The internal column deserves special attention. A product can be delivered on time and still fail because the people who must approve decisions were unavailable, the data owner was never involved, or nobody had capacity to change the surrounding process. "The agency will handle it" is not a resourcing plan.

A simple first-year example

Consider a hypothetical membership business considering a mobile app. These numbers are deliberately rounded so the method is easy to inspect:

‍

‍

The figure is not "the cost of the app" in perpetuity. It is a first-year planning number. The second year may be cheaper if the product is stable, or more expensive if usage grows, a platform changes, or the business learns that the first version solved the wrong problem.

Now choose one return mechanism. Suppose the app is expected to create $16,000 of additional monthly contribution beginning in month seven. In the first year, that produces six months of contribution, or $96,000. On these assumptions, the project has not paid back in year one. Across 18 months, it would produce $192,000 and pass the $144,000 investment somewhere around month 15 — before considering tax, financing, or the value of the team's freed-up time.

That is a more useful answer than "the app should increase engagement." It gives the team something to measure and a reason to revisit the assumptions. If the return depends on adoption, the adoption plan is part of the product — not a marketing task that begins after launch.

Do not stack every possible benefit into the numerator

Most business cases become unreliable when they count the same improvement several times. A new workflow may reduce support tickets, save staff time, improve retention, and increase conversion. Those effects may all be real, but they do not automatically add together. Some are consequences of the same underlying change.

Pick the primary mechanism and model it conservatively:

• Revenue: additional qualified opportunities, purchases, or subscription contribution.
• Retention: fewer cancellations or more repeat usage, with a clear baseline period.
• Capacity: hours removed from a repeatable process, multiplied by a realistic loaded cost.
• Risk reduction: avoided incidents or compliance costs, with the probability and impact stated separately.

Then list secondary benefits as hypotheses rather than guaranteed returns. That keeps the business case honest and gives the team a sequence for learning.

A good model also includes the "zero-return condition." What would have to be true for the project to produce no meaningful return? It might be low adoption, poor data quality, a process that nobody changes, or a distribution channel that cannot reach the intended users. If the answer is behavioural, adding another feature will not solve the problem.

‍

‍

Build, buy, or bring in a specialist?

The choice is not simply "agency versus internal team." There are at least three viable paths:

• Buy: best when the workflow is common, configuration is sufficient, and your differentiation does not live in the software.
• Build internally: best when you have the product ownership, engineering capacity, and appetite to maintain the system after the first release.
• Partner: best when the product is strategically important but you need outside speed, specialised experience, or a temporary delivery team.

Ask four questions before selecting a path:

1. Is the problem standard enough that an existing product will fit without distorting the process?
2. Does the internal team have time not just to build, but to make decisions and operate the result?
3. Which part of the experience is genuinely differentiating?
4. Who will own the backlog, metrics, security decisions, and maintenance six months after launch?

A useful partner should be willing to narrow the scope, challenge the premise, and explain what the organisation must do to make the product work. If the conversation stays on features and screens, the important risks are probably still hidden.

The same principle applies on the growth side. A studio such as m8l describes its work around growth, product, SEO, content, go-to-market execution, and low-code development. That is a different service mix from a team focused primarily on native mobile delivery. The right comparison is not "which provider has the larger menu?" It is "which capability is actually upstream of the outcome we need?"

Separate fixed costs from costs that grow with use

A digital product's first quote often hides the economics of scale. Map costs to a usage driver:

• users or sessions;
• messages, calls, or transactions;
• storage and media volume;
• third-party API requests;
• support conversations;
• releases and compliance reviews;
• markets, languages, or platforms.

For example, a notification service may be inexpensive during a pilot and material at national scale. A video workflow may look like a feature cost until storage and delivery become the dominant bill. A customer-support process may need a larger team even if the infrastructure remains cheap.

Ask every provider to identify the first three cost curves they expect to change as adoption grows. You do not need a perfect forecast. You do need to know what to watch.

The same applies to technical debt. A shortcut that saves two weeks today may add a recurring cost to every release. A narrowly scoped first version is healthy; an undocumented shortcut that nobody owns is not. Request a short decision log explaining what was intentionally deferred, why it was safe to defer, and what future signal would trigger the work.

Measure the first 90 days like an experiment

Launch is not the finish line. It is when the assumptions become testable.

Before release: record the baseline for the one outcome the product is intended to change. Define the target user, activation event, and owner. Decide which data is reliable enough to use and which is only directional.

Days 1–30: verify that people can complete the core task. Watch failed attempts, drop-off, support questions, and time-to-value. Do not optimise a dashboard before checking that the event tracking describes reality.

Days 31–60: test the highest-risk assumption. If the business case depends on repeat use, measure repeat use. If it depends on staff adoption, observe the workflow with real staff. A polished feature that nobody uses is not progress.

Days 61–90: compare the baseline with the new data and make an explicit decision: extend, change direction, hold, or stop. Stopping a weak experiment is not failure; continuing one without learning is.

Keep the measurement plan short enough to survive contact with operations. One primary outcome, two or three leading indicators, and a named owner are usually more valuable than a wall of metrics nobody reviews.

‍

‍

What a responsible delivery engagement includes

At Bolder Apps, our view is that the highest-leverage work often happens before the first production build: clarifying the user, narrowing the first release, choosing the right platform, and identifying the assumptions that can invalidate the plan. The delivery path may include paid discovery, prototyping, UX, mobile or web development, integrations, QA, launch support, and ongoing improvement — but the sequence should follow the risk, not a generic checklist.

That also means being explicit about handover. The owning team should know how to read the key metrics, where the operational controls live, how incidents are handled, and which decisions remain open. A successful engagement reduces dependency on the delivery team instead of turning the delivery team into a permanent support queue.

Before signing, ask for:

• the assumptions behind the estimate;
• the internal time required from your team;
• a list of excluded work and likely change triggers;
• the expected run-cost drivers;
• the first measurement plan;
• the ownership and handover model.

The decision to make next

Do not ask whether a digital product has a positive ROI in the abstract. Ask:

• What is the one outcome it must improve?
• What is the current baseline?
• What will the first year really consume, including internal time?
• Which assumption is most likely to fail?
• When will we have enough evidence to continue, change, or stop?

That is the difference between buying software and funding a measurable business change. The strongest partner is not the one that promises the biggest return. It is the one that helps you make the return—and the uncertainty around it—visible.

‍