HELP US MAKE DOTSUPER MORE USEFUL

Can we learn from your visit?

Privacy notice

LTRLS Learning Through Real-Life Scenarios

The subscription is cheap. The integration is not.

Choose a delivery route across six fictional technology decisions. Compare full costs, prove essential requirements and plan support, ownership and exit.

6 fictional cases20–30 minutes solo; 45–60 with a team (estimates)General technology procurement; fictional AED examples context
Start experience

No account needed. Work alone or discuss with a team.

Build, buy and integrate are compared as three delivery routes.
dotSuper. Original illustration for this learning experience.. Original dotSuper material. Contact dotSuper for reuse permissions. Third-party sources retain their own terms.

What you will practise

Make the trade-off visible.

Choose the route that meets the required workflow at a supportable total cost. Test the uncertain dependency before committing and include operations and exit in the decision.

  • Compare a consistent cost horizon and required scope.
  • Test the uncertainty that could invalidate a delivery route.
  • Make operating responsibility and exit usable before commitment.

Built for the people making the call

Business ownersIT leadersProcurement teamsAI project sponsors

Original fictional educational cases. All companies, prices, volumes and outcomes are illustrative. Sources support the stated principles, not claimed customer results. Completion is a learning record, not a professional assessment.

From the exercise to the business

What a better decision could change.

What you will learn

Write a conditional technology recommendation that includes delivery, running and exit.

Potential business value

Reduce unsuitable commitments, hidden operating effort and dependency on untested integrations.

How the value could happen

Required outcome → feasible route → bounded proof → supported operation → recoverable exit.

Measures to examine

  • Full incremental cost over a stated horizon
  • Essential workflow requirements demonstrated
  • Internal support hours and unresolved incidents
  • Export and transition steps actually demonstrated

Keep these limits in view

  • An existing system is not automatically the best route.
  • A prototype does not establish production operation.
  • A low initial price is not a full cost comparison.

A useful next step: Choose one essential requirement whose failure would invalidate the preferred route, then design a small proof around it.

Explore the companion method
  1. 01

    Read the situation

    Identify the purpose, people and consequences.

  2. 02

    Make your choice

    Confirm a response before opening the reasoning.

  3. 03

    Question the control

    Discuss what would need to change in a real workflow.

  4. 04

    Leave with a card

    Record an owner, evidence, approval conditions and a stop point.

LTRLS / Practise before the real decision

A situation. A choice. A better question.

Three proposals promise a similar result. Work through the costs and conditions that turn a purchase into a service the team can run.

6 fictional cases20–30 minutes solo; 45–60 with a team (estimates)No account, no countdown

Progress and notes stay in this page’s memory. Refreshing, leaving or closing the page loses them. Use anonymous examples and roles.

Running this with a team?
  • Assign sponsor, user, procurement and run-owner roles. A route must work for all four.
  • Ask what would make the current preferred option wrong.
  • Treat all prices and supplier capabilities as fictional case evidence.

Prefer to read?

The complete case notes.

The same situations and reasoning, without the interactive flow.

Open all 6 cases

Case 01

The licence is only one line

A packaged product costs AED 24,000 yearly. It also needs AED 12,000 setup, an AED 18,000 one-off connector and AED 12,000 yearly support. The proposal headline compares only its licence with a competitor’s full first-year price.

What first-year amount belongs in the comparable quoted-cost column?

  • AED 24,000, because the other items are implementation rather than software.
  • AED 36,000, covering licence and support.
  • AED 66,000, with unquoted internal effort shown separately.
  • An arbitrary 50% reserve on the licence is sufficient.

Recommended response for this scenario

AED 66,000, with unquoted internal effort shown separately.

The first-year quoted total is 24,000 + 12,000 + 18,000 + 12,000 = AED 66,000. Add any relevant internal effort, migration and change costs once assessed. Compare alternatives over the same scope and period.

Why each choice matters

AED 24,000, because the other items are implementation rather than software.
The required delivery route needs those items regardless of their accounting label.
AED 36,000, covering licence and support.
That omits the necessary setup and connector in the first year.
AED 66,000, with unquoted internal effort shown separately.
The four stated required items total AED 66,000. This is a quoted-scope total, not all possible costs.
An arbitrary 50% reserve on the licence is sufficient.
A generic reserve is less informative than known cost lines and explicit remaining uncertainty.

Practical control: Separate one-off, recurring and unquoted costs. Require the same horizon and scope for each candidate.

Discuss: Which missing cost could be large enough to change the preferred route?

Case 02

The cheapest route misses an essential record

The business requires an exportable approval history for each order. The cheapest extension exports current values but not the approval history. The vendor says it may add that feature later. No funded delivery commitment or usable workaround exists.

How should the route be treated today?

  • Treat the roadmap statement as satisfying the requirement.
  • Keep it conditional on an acceptable approval-history solution before selection.
  • Drop approval history because the price is attractive.
  • Assume staff will recreate the history manually whenever needed.

Recommended response for this scenario

Keep it conditional on an acceptable approval-history solution before selection.

The route does not yet meet the stated requirement. Test a supported solution or an authorised change to the requirement. A workaround needs an owner, evidence and cost. Do not turn a roadmap promise into a present capability.

Why each choice matters

Treat the roadmap statement as satisfying the requirement.
An uncommitted future feature is not demonstrated capability.
Keep it conditional on an acceptable approval-history solution before selection.
This retains the candidate while making the missing essential capability explicit.
Drop approval history because the price is attractive.
Changing an essential requirement needs the appropriate business decision, not a hidden procurement compromise.
Assume staff will recreate the history manually whenever needed.
That untested workaround may be infeasible and has no cost or owner.

Practical control: For each essential requirement, record demonstrated, conditional or unmet status with evidence and an accountable decision owner.

Discuss: What evidence would make the workaround acceptable?

Case 03

Test the dependency that could break delivery

The product demo extracts documents accurately. The unproven step is writing approved records into the existing order system without duplication. A vendor offers another polished extraction demo before the annual contract is signed.

Which proof is most useful now?

  • Repeat the extraction demo with more attractive documents.
  • Sign the annual contract because integration is a standard feature.
  • Give the vendor unrestricted production access to discover the integration behaviour.
  • Run a bounded test of approved writes, duplicate handling and failed-request recovery.

Recommended response for this scenario

Run a bounded test of approved writes, duplicate handling and failed-request recovery.

Test the end-to-end dependency in an authorised environment with synthetic or otherwise approved data. Define the expected result for a normal write, a repeated request and a failure. Record both the capability and the operating responsibility before commitment.

Why each choice matters

Repeat the extraction demo with more attractive documents.
That tests a capability already demonstrated while leaving the integration uncertainty open.
Sign the annual contract because integration is a standard feature.
The specific requirement remains unproven in this operating context.
Give the vendor unrestricted production access to discover the integration behaviour.
A proof can be bounded and use an approved test environment; unrestricted access adds unnecessary exposure.
Run a bounded test of approved writes, duplicate handling and failed-request recovery.
This directly tests the dependency that could invalidate the delivery route.

Practical control: Write a proof charter with scope, data, permissions, success evidence, failure cases, budget and a stop condition.

Discuss: What result would make you abandon this integration route?

Case 04

The support promise ends before the shift

The new workflow must run during an evening dispatch shift. The proposal includes weekday daytime support only. Internal staff cannot repair the integration. A known manual fallback exists, but no one has estimated whether the evening team can handle its volume.

What must the sponsor resolve before launch?

  • Agree support coverage or prove a workable fallback, with a named operational owner.
  • Launch because the vendor’s general uptime claim is strong.
  • Ask the original developer to remain informally reachable forever.
  • Write that evening incidents will wait until morning.

Recommended response for this scenario

Agree support coverage or prove a workable fallback, with a named operational owner.

The support arrangement must fit the business need. Price the required coverage or demonstrate that the fallback can sustain agreed service. Name the incident decision-maker and define when work switches to the fallback. Include its effort in the cost model.

Why each choice matters

Agree support coverage or prove a workable fallback, with a named operational owner.
This addresses the actual hours and capacity needed to run the service.
Launch because the vendor’s general uptime claim is strong.
An uptime claim does not establish the ability to handle a failure during this shift.
Ask the original developer to remain informally reachable forever.
An informal personal dependency is not a defined operating arrangement.
Write that evening incidents will wait until morning.
That may contradict the dispatch requirement unless the business explicitly accepts the consequence.

Practical control: Document service hours, failure detection, escalation, fallback capacity and recovery ownership.

Discuss: Which evening workload would make the fallback insufficient?

Case 05

An export button is not an exit plan

The preferred vendor demonstrates a CSV export of current orders. The workflow also depends on attachments, approval history and mappings to product codes. The contract says additional export work is chargeable, but no price or scope is agreed.

What should procurement establish before commitment?

  • Accept the CSV because it proves all data is portable.
  • Rely on the account manager’s verbal promise to help later.
  • Demonstrate a representative complete export and agree the transition scope, cost and responsibilities.
  • Reject every external product and build internally.

Recommended response for this scenario

Demonstrate a representative complete export and agree the transition scope, cost and responsibilities.

Test whether another authorised operator can use the exported records with their attachments and history. Document formats, mappings, assistance and cost. The aim is an operable transition, not merely possession of a file.

Why each choice matters

Accept the CSV because it proves all data is portable.
The demonstration covers only current order fields, not the other dependencies.
Rely on the account manager’s verbal promise to help later.
The required work, price and ownership remain undefined.
Demonstrate a representative complete export and agree the transition scope, cost and responsibilities.
This makes the intended exit usable and priceable.
Reject every external product and build internally.
Internal systems also require maintainability and transition planning; the concern is not unique to vendors.

Practical control: Keep a tested exit checklist covering records, attachments, history, mappings, access closure and accountable owners.

Discuss: What would you need on the first day after the vendor relationship ends?

Case 06

The route should follow the requirement

For a specialist workflow, neither available package nor the existing-system extension supports an essential constraint. A bounded custom prototype has demonstrated it. Delivery estimates, maintenance staffing and full costs have been reviewed and funded. The sponsor previously preferred buying.

Which recommendation best fits these changed facts?

  • Buy anyway because packaged software is always cheaper to operate.
  • Proceed with the bounded custom route under its reviewed delivery and operating conditions.
  • Force the workflow into the existing extension to avoid introducing another system.
  • Treat the prototype as a finished production service and remove further acceptance checks.

Recommended response for this scenario

Proceed with the bounded custom route under its reviewed delivery and operating conditions.

A custom route can be justified when the need is real and the team can deliver and operate it. Preserve production acceptance, cost limits and ownership. Revisit the decision if those conditions change. Build, buy and integrate are context-dependent choices.

Why each choice matters

Buy anyway because packaged software is always cheaper to operate.
That general rule ignores an unmet essential requirement and the specific cost evidence.
Proceed with the bounded custom route under its reviewed delivery and operating conditions.
The requirement and capability evidence now support that route, subject to the stated conditions.
Force the workflow into the existing extension to avoid introducing another system.
Reuse has value only if the resulting workflow meets the required need.
Treat the prototype as a finished production service and remove further acceptance checks.
Demonstrating the specialist capability does not complete production acceptance.

Practical control: Write the chosen route, decisive evidence, remaining acceptance conditions and assumptions that would trigger reconsideration.

Discuss: Which change in team capability or commercial alternatives would reopen the decision?

Worked example / Fictional teaching context

Technology route and ownership record

Illustrative assumptions, not a customer result, forecast or professional assessment. Keep the conditions beside the numbers.

Packaged product
AED 12,000 setup + AED 18,000 one-off connector + AED 24,000 annual licence + AED 12,000 annual support
Custom application
AED 48,000 setup + AED 18,000 annual support + AED 12,000 annual running
Existing-system extension
AED 18,000 setup + AED 18,000 annual extension + AED 12,000 annual support
First-year quoted totals
Packaged AED 66,000; custom AED 78,000; extension AED 48,000
Three-year quoted totals
Packaged AED 138,000; custom AED 138,000; extension AED 108,000
Comparison limits
No price changes or discounting; taxes, internal effort and migration excluded consistently and still to assess
Decision
Extension is provisionally cheapest on quoted scope, subject to essential requirements and unquoted costs

Try the idea in a different situation

A new workflow requires a specialist capability absent from the current system. Explain what would justify a custom build.

Prompts for your discussion
  • Shows why the requirement is essential and unsupported by available alternatives.
  • Includes delivery and operational capability with full incremental costs.
  • Defines a proof, accountable owner and exit or fallback route.

Use these prompts to examine the reasoning, not to award a score or certify readiness.

Sources and limits

Keep the context with the decision.

Original fictional educational cases. All companies, prices, volumes and outcomes are illustrative. Sources support the stated principles, not claimed customer results. Completion is a learning record, not a professional assessment.

Editorial source review: 2026-09-17. Not legal approval or a verified readiness assessment.

  • All scenario facts and numerical examples are fictional. They are not verified customer results or estimates of a particular business’s performance.
  • The stated durations are planning estimates. Learning outcomes and commercial impact have not been validated with intended readers.
  • Source guidance is used for the stated principles. It does not establish legal applicability, certification or professional approval.
  • Changed-fact prompts support discussion. This is a fixed case sequence, not a branching simulation.

/ CITE OR SHARE THIS GUIDE

Make the evidence easy to verify.

When you reference this guide, link to its canonical URL. That gives readers one stable place for the evidence, limitations and future updates.

Suggested citation

dotSuper Research Desk. (September 17, 2026). The subscription is cheap. The integration is not.. dotSuper. https://dotsuper.net/feeds/applied-systems/build-buy-integrate-decision-lab

Share on LinkedIn

Move from practice to your operating context

Put the decision into practice

Choose one essential requirement whose failure would invalidate the preferred route, then design a small proof around it.

Talk with dotSuper