Build vs Adopt vs Extend

FieldDesk’s three futures

Dana’s low-code stopgap became load-bearing, and now it has three possible futures:

1. Adopt — take a mature open-source service-request product and configure it for Meridian
2. Build — rebuild FieldDesk purpose-made on Meridian’s modern stack (Next.js, Entra ID for identity, a managed database)
3. Extend — stay on the low-code platform and invest in doing it properly

The naive move is to pick a favorite in the first meeting and spend six weeks justifying it. The disciplined move is a rule: every option gets a full evaluation on its own terms before any comparison happens. If you evaluate “adopt” through the lens of the build you already want, you will find exactly the flaws you went looking for.

Prompt first: three advocates

I need three separate advocacy documents for the future of a service-request
application. For each option below, write the STRONGEST honest case for it --
architecture fit, cost profile, risks, and what success looks like in 2 years.
Do not compare options to each other. Do not hedge. Each document argues its
own corner.

Option A - ADOPT: [paste the OSS product's stack and feature summary]
Option B - BUILD: purpose-built on Next.js + Entra ID + managed Postgres
Option C - EXTEND: remain on [low-code platform], remediate properly

Context: [paste the Lesson 1.2-style assessment of FieldDesk here]

Three documents, three genuine best cases. Only after all three exist do you build the comparison.

The comparison: a qualitative attribute matrix

With three advocates on the table, the comparison is a matrix of attributes — not scores:

The table that wins schedules

The single most valuable artifact in this decision is the feature-parity disposition table. Take every capability the current FieldDesk has, and force each into one of four columns:

The “not needed” column is where the schedule is won. Every row you can honestly place there is scope the build option does not carry — and in real evaluations, discoveries like “we never migrated the legacy data anyway” or “authentication is IdP-only now” repeatedly shrink the build until it beats adoption. Scope discovery is not cheating; it is the evaluation doing its job.

What actually tips these decisions

Documented tipping factors from evaluations of exactly this shape, in weight order:

1. Platform alignment — Meridian already runs a settled modern-web ecosystem. Adopting a divergent stack means maintaining a technology island forever.
2. Remediation cost converges on build cost — with a worse endpoint: money spent modernizing a fork still leaves you on someone else’s architecture.
3. Scope discoveries — the disposition table deletes the adopt option’s biggest advantage (all those features you turn out not to need).
4. Security debt as entry cost — a customized fork can’t cleanly take upstream fixes; you inherit its vulnerability backlog on day one.
5. Run-rate economics — a purpose-built app on PaaS versus per-user licensing that rises with headcount.

And one discipline for whatever wins: the loser becomes a functional reference spec. If build wins, the OSS product’s battle-tested feature set defines what to build — and none of its code comes along.

The honest caveat — and your exercise

A qualitative matrix has a real limit: with no criteria weighting, the trade-off between rows is not auditable. A reviewer who values ops burden over platform alignment could defensibly reach the other answer. So run the weighting pass yourself:

Take this attribute matrix and disposition table. Propose weights for each
attribute from the perspective of (a) a CIO focused on 5-year run cost,
(b) a security officer, (c) the field-operations director. Score all three
options under each weighting. Where does the decision flip?

If the answer survives all three weightings, you have a robust decision. If it flips, you have found the actual disagreement to take to the steering committee — which is worth more than false consensus.

Key takeaway

Evaluate each future on its own terms, compare with an attribute matrix, and force every existing capability into MVP / later / not needed / defer — the “not needed” column is where schedules are won. Then stress the answer with a weighting pass. Next lesson: turning the winner into a roadmap that survives contact with reality.