This guide tests whether one proposed purchase, upgrade, or replacement belongs in the operating stack.

The lean software stack blueprint defines the baseline roles a stack must cover. This page stays with the purchase decision: the current failure, the task a tool would replace, the full operating cost, and the conditions for keeping it.

Name the failure before the category

Write one sentence describing what happens now. For example:

  • a qualified lead waits because no owner sees the follow-up;
  • an approval exists in email but the active project still looks blocked;
  • invoice status is absent from the weekly review;
  • two people update different versions of the client record.

Do not begin with a product name. If you cannot describe a current failure, return to the client workflow guide and locate the stage first.

Test the proposed purchase

Answer these questions in writing:

  1. Which current failure would the tool prevent or expose?
  2. What existing task, subscription, or workaround would stop?
  3. Where would authoritative client status live afterward?
  4. Who would configure and maintain the system?
  5. Which exception would still require manual judgment?
  6. What observable condition would cause cancellation or replacement?

A purchase is premature when its role is described only as convenience, growth, organization, or future flexibility.

Count operating cost

The subscription is one part of the cost. Include:

  • seats, add-ons, and transaction charges;
  • setup, migration, and training;
  • recurring data entry or reconciliation;
  • permission and access maintenance;
  • the exit work required to export or move records.

Record the current vendor price from its own pricing page. Do not use a remembered price or assume the cheapest plan includes a required capability.

Look for duplicate authority

A second tool creates risk when both systems appear to own the same current fact.

Before buying, finish this statement:

The new tool owns ________. The existing system remains authoritative for ________.

If the boundary cannot be stated, define it with the system-of-record rules worksheet before adding the tool.

Delay when the rule is still moving

Wait when:

  • the service stages are still being renamed or reordered;
  • ownership changes from project to project;
  • the manual step is inconsistent because the underlying decision is unclear;
  • the product would mirror a record already available elsewhere;
  • no one is responsible for reviewing exceptions.

A checklist or a clearer trigger can be the correct fix when the work is stable enough to repeat but does not require a new system.

Buy or upgrade when the limitation is concrete

A purchase has a defensible role when the current system cannot support a required condition and the new system can. Examples include a missing permission boundary, a required approval record, a handoff that cannot be assigned, or a billing state that must affect delivery.

Verify the capability in current provider documentation. Then decide whether the workflow benefit outweighs the subscription, setup, maintenance, and exit costs.

Record the decision

Keep a short decision note with:

  • the failure being addressed;
  • the source that confirms the required capability and current price;
  • the system-of-record boundary;
  • the owner;
  • the implementation and rollback approach;
  • the condition and date for review.

A rejected purchase should also record why it was delayed. That prevents the same vague proposal from returning without new evidence.

Continue with the relevant page

The purchase decision is complete when the tool has one necessary role, an owner, a verified capability, a known total cost, and a clear removal condition.