Feasibility & Cost-Benefit Analysis

Make, Buy or Subscribe?

18 min Lesson 8 of 10

Make, Buy or Subscribe?

Every feasibility study eventually reaches a pivotal crossroads: How should the organisation actually acquire this system? Should a team build it from scratch, purchase a pre-packaged product and install it on your own infrastructure, or simply subscribe to a cloud-hosted service and never own the software at all? This decision — commonly called the Make, Buy or Subscribe decision — shapes the entire economics of the project and is one of the most consequential recommendations a systems analyst can make.

To make that recommendation with confidence, you need a framework that goes beyond the sticker price. The true metric is Total Cost of Ownership (TCO): every dollar spent over the full lifetime of the system, from inception through decommissioning. Organisations that focus only on upfront costs repeatedly discover expensive surprises three years into a five-year plan.

The Three Acquisition Paths

Before comparing costs, it helps to understand what each option actually means in practice.

Make (Custom Build) — Your team, or a contracted development house, designs and builds the system entirely to your specifications. You own the source code and the intellectual property. Examples: a clinic building its own patient-booking portal to match its unique triage workflow; a logistics firm writing a custom route-optimisation engine tuned to its specific vehicle fleet and delivery contracts.
Buy (COTS — Commercial Off-The-Shelf) — You purchase a licence for a packaged application, install it on your own servers (or a dedicated cloud instance you control), and configure it to fit your processes. Examples: an online retailer deploying Magento or WooCommerce on its own infrastructure; a logistics firm licensing a commercial Transport Management System (TMS) and hosting it in-house.
Subscribe (SaaS — Software as a Service) — You pay a recurring subscription to use software that runs on the vendor's infrastructure. You access it via a browser or API; you own neither the code nor the servers. Examples: the clinic using Calendly or a healthcare-specific SaaS like Healthie for bookings; the online retailer running its store on Shopify; the logistics firm subscribing to Circuit or Onfleet for last-mile routing.

A fourth path exists but is often overlooked: Hybrid — subscribe to a SaaS platform for the commodity parts of a problem while building custom modules only for the differentiating logic. A logistics firm might subscribe to a leading TMS for standard routing but build a proprietary machine-learning layer on top via the vendor's API. Hybrid strategies are increasingly common and should be on the analyst's option list.

Total Cost of Ownership: What to Count

TCO analysis forces you to be honest about every cost category across the chosen time horizon (typically 3–5 years). The table below lists the cost categories and how they apply to each acquisition path.

Initial acquisition cost — Custom: development labour + tooling. COTS: perpetual or multi-year licence fee. SaaS: first-month or onboarding fee (often low).
Infrastructure — Custom & COTS: servers, databases, networking, hosting, DR environments, SSL certificates. SaaS: typically zero — the vendor bears all infrastructure costs.
Implementation & integration — All three paths carry integration costs: connecting to your CRM, ERP, payment gateway, or messaging system. Custom has the most flexibility; COTS integration often requires paid professional services from the vendor; SaaS usually provides documented APIs but charges for premium connectors.
Customisation & configuration — Custom: unlimited but expensive. COTS: configuration is bounded by what the vendor allows; deep customisation may require buying the source-code licence. SaaS: typically limited to the settings panel and API; deep customisation is not possible.
Training — Custom: you write your own training materials. COTS: vendor training courses (often charged per seat). SaaS: vendors invest heavily in self-service onboarding; often free or very low cost.
Maintenance & bug fixes — Custom: your team owns every bug. COTS: vendor releases patches under a support contract (annual fee, typically 18–22% of licence value). SaaS: vendor fixes bugs as part of the subscription; transparent to you.
Upgrades — Custom: you plan and fund every feature upgrade. COTS: major version upgrades require a new licence or upgrade fee and a fresh implementation project. SaaS: upgrades are continuous and included in the subscription, though sometimes disruptive.
Security & compliance — Custom & COTS: your team patches vulnerabilities and conducts audits. SaaS: vendor manages security, though you retain data-governance responsibility (GDPR, HIPAA processor obligations).
Vendor dependency & exit costs — SaaS: data export, migration to a replacement system, and the risk of vendor price increases or discontinuation. COTS: vendor lock-in through proprietary data formats. Custom: no vendor dependency, but code becomes a liability if the original team leaves.

Worked Example: Clinic Booking System (3-Year TCO)

A 20-physician private clinic wants an online booking system with SMS reminders, patient records integration, and a patient-facing mobile interface. Its IT team consists of two developers and one infrastructure engineer. Let us estimate a realistic 3-year TCO for each path (figures in USD, approximate).

Make: 6-month build at $100k labour + $15k tooling + $18k/yr hosting and DevOps + $30k/yr maintenance & enhancement = ~$191k year 1, ~$134k years 2+3 combined. 3-year total: ~$325k. Risk: the clinic owns a system perfectly matched to its workflow but has a single point of failure if the two developers leave.
Buy (COTS): $40k licence + $25k implementation & integration + $8k/yr support contract + $12k/yr hosting = ~$65k year 1, ~$40k years 2+3 combined. 3-year total: ~$145k. Risk: upcoming version upgrade in year 2 may require a $15k implementation project.
Subscribe (SaaS): $500/month for 20 physicians = $6k/yr + $5k one-time integration to patient records system. 3-year total: ~$23k. Risk: the vendor controls the roadmap, prices can increase, and data portability is constrained.

On pure TCO, SaaS wins decisively for this clinic. But cost is not the only dimension. If the clinic's competitive advantage is a unique triage workflow it wants to protect and monetise as a product itself, a custom build may be the right long-term answer despite the cost premium.

3-year total cost of ownership for the clinic booking system — SaaS is dramatically cheaper, but lowest cost does not automatically mean best choice.

The Decision Matrix: More Than Just Cost

A rigorous make/buy/subscribe analysis scores each option across several dimensions, not cost alone. The matrix below shows a typical scoring approach for the same clinic scenario.

Decision matrix comparing Make, Buy, and Subscribe across five practical dimensions — green signals an advantage, amber a trade-off, red a drawback.

Applying the Framework to Three Scenarios

Scenario A — Clinic booking system. The clinic's workflow is largely standard (appointment slots, SMS reminders, patient notes). No proprietary algorithm differentiates it from competitors. The IT team is small and already overloaded. Recommendation: Subscribe (SaaS). The 14× cost advantage over custom build, with near-instant deployment, is compelling. The only caveat is validating HIPAA/data-residency compliance on the vendor's platform.

Scenario B — Online retailer inventory dashboard. The retailer already runs its e-commerce platform on Shopify (SaaS). It needs a real-time inventory dashboard that aggregates data from three warehouses, two 3PL partners, and four sales channels. Most SaaS BI tools cannot ingest these non-standard feeds without expensive connectors. The integration complexity tips the analysis. Recommendation: Buy (COTS BI tool such as Metabase or Looker, self-hosted) with custom data-pipeline connectors. The organisation retains control of its data architecture while avoiding a full custom build of the visualisation layer.

Scenario C — Logistics route-optimisation engine. The firm's dispatch rules are uniquely complex: mixed fleet of refrigerated and standard vehicles, dynamic priority tiers for pharmaceutical clients, real-time integration with IoT sensors on 200 trucks. No commercial TMS supports all three constraints simultaneously. Recommendation: Make (custom build), or Hybrid — subscribe to a TMS for standard routing and build a proprietary constraint-solver as a sidecar service. The business's competitive position depends on route-cost performance; investing in unique IP is justified.

Analyst rule of thumb: The more a process is a commodity (widely shared, no differentiation), the stronger the case for SaaS. The more a process is a core differentiator (unique algorithm, protected workflow, competitive moat), the stronger the case for custom build. COTS occupies the middle ground where some customisation is needed but not to the level of bespoke development.

When SaaS Looks Free But Is Not

SaaS pricing is deliberately designed to minimise upfront sticker shock. Analysts must probe beneath the headline price to find the full subscription TCO:

Per-seat scaling — A $50/user/month plan looks cheap at 5 users. At 200 users it is $120k/year, at which point a COTS licence often becomes cheaper.
Overage and usage charges — Many SaaS platforms charge by API calls, data-storage gigabytes, or transaction volumes. A rapidly growing e-commerce store can see SaaS costs triple in 18 months.
Premium feature tiers — SSO, audit logs, advanced reporting, and custom integrations are often locked behind enterprise tiers that cost 5–10× the advertised price.
Data egress and migration costs — When you want to leave a SaaS vendor, extracting your data can be technically difficult, contractually constrained, or charged by the gigabyte.
Compliance surcharges — HIPAA BAA (Business Associate Agreement), SOC 2 reports, and GDPR DPA (Data Processing Agreement) may be available only on enterprise plans.

Watch for SaaS lock-in creep. Organisations often start with a cheap SaaS plan, customise their workflows around it, and then discover that switching vendors three years later requires a complete process redesign. Always evaluate data portability and migration paths before signing, not after.

Structuring the Recommendation in the Feasibility Report

The make/buy/subscribe analysis sits inside the Economic Feasibility section of the full feasibility report (covered in Lesson 9). Analysts should present it as a scored comparison, not a personal preference. A good structure is:

Define the options considered (make, buy, subscribe, hybrid) and document why each was or was not shortlisted.
Present the 3-year or 5-year TCO estimate for each shortlisted option, with assumptions stated explicitly.
Score each option against the decision criteria (cost, time to deploy, customisation, vendor risk, compliance, differentiation).
State the recommended option and explain the primary rationale.
List the conditions that would change the recommendation (e.g., "if user count exceeds 150, SaaS becomes more expensive than COTS by year 3").

By presenting the analysis this way, the sponsor can see the full picture and challenge the assumptions if needed — which is far more valuable than receiving a bare recommendation with no reasoning.