Skip to content

Strategy & Systems Design

Technology selection: chosen for your requirements, not a favourite stack

Every builder has tools they like. That's a fine place to start and a poor reason to replace software your team already depends on. We choose against your requirements and what you already run, keep what works, build only what sets you apart, and write down what each choice gave up and what would change it.
Talk through a decisionSee the questions we ask ↓
Decision: invoicing and the bookskeep the accountingsoftware, connect itmove to anotheraccounting productbuild books intothe office appfinance already uses itin use todayfinance retrainsnew for everyonehandles tax and year-endyesyesnot worth rebuildingdeal-breakercan take invoices from the backendlikely; check firstyesit's oursrunning cost and upkeepalready paid fora migration firstours to maintainwhat we'd be tied toits invoice layouta new productour own codedecision recorddecidedkeep the accounting software and connect the office app to itbecausefinance already uses it, and tax and year-end aren't worth rebuildinggave upinvoice layouts limited to what accounting acceptsrevisit ifit can't take line items, or finance changes softwareAgreed with the owner and finance

Seven questions before building anything

Asked of every part of the system. Most answers point to keeping or connecting, not building.

  1. 01

    Is it what sets you apart?

    Build that

    The rules and screens that make your business yours are worth owning. Most of the rest isn't.

  2. 02

    Does something already do most of it?

    Reliably, today

    If a tool covers nearly all of the need, connecting to it usually beats recreating it.

  3. 03

    Which is harder: connecting or recreating?

    Honestly estimated

    Some tools are easy to connect to. Some aren't, and that changes the answer.

  4. 04

    Who keeps it running?

    Custom code is a commitment

    Everything built has to be maintained, updated and watched for as long as it's used.

  5. 05

    Do you need to own how it behaves?

    Your rules, your control

    If the rules are how you compete, they shouldn't live inside someone else's product.

  6. 06

    Can existing products do what you need?

    Data, permissions, screens, timing

    Sometimes the requirement is simply something no product can express.

  7. 07

    Is being tied in really a problem?

    Weighed, not feared

    Depending on a product is a cost to weigh against building, not a reason on its own.

Where we usually start, and what changes it

Defaults save time when they fit. Each has a known reason to change it.
Business recordsa relational databasesearch-heavy screens, or very large volumes of events
Screens for staff and customersa web app that works well on phoneswork where there's no signal: an installed app
Integrations people need to seea visible workflow toolheavy or code-only logic: background jobs in code
Slow or long workbackground jobs with retriesprocesses that run for days across many steps: a durable workflow engine
Search over documentssearch inside the main databaselarge collections or demanding search: a dedicated search engine
Tools you already usekeep them and connect to themthey can't do what's needed, or can't be connected

Specific products are named in the proposal, once the requirements are known. Our usual tools are a starting point, not a promise.

The decision, written down

Short enough to read in a minute. The next person to ask “why didn't we just build it?” finds the answer here.

Invoicing and the books

Options
keep the accounting software and connect it; move to another accounting product; build books into the office app
Chosen
keep and connect
Because
finance already uses it; tax and year-end aren't worth rebuilding; it's already paid for
Gave up
invoice layouts limited to what accounting accepts
Depends on
accounting accepting invoices from the backend, checked before anything else is built
Revisit if
it can't take line items, or finance changes software
Agreed by
the owner and finance

A favourite stack, or requirements first

A favourite stack

  1. 01The same tools for every project
  2. 02Working tools replaced to fit the stack
  3. 03Choices made before the problem is understood
  4. 04Reasons kept in someone's head

You inherit a stack chosen for the builder, not the business.

Requirements first

  1. 01Requirements and current tools looked at first
  2. 02Tools that work are kept and connected
  3. 03Defaults used where they fit, changed where they don't
  4. 04Each choice written down with what would change it

The choice still makes sense when someone else maintains it.

What a decision is made from, and where it goes

Made from

Requirements
from the architecture
Tools in use
and who depends on them
Constraints
budget, team, rules
Technology selection
options, criteria, a decision record

Goes to

Roadmap
what to check first
The build
what's used
Your records
why it was chosen

Worth doing when a choice is expensive to undo

Good fit

  • You're being told to replace tools that mostly work.
  • A build-or-buy decision with real money on each side.
  • You want choices someone else could maintain after us.

Not the right fit

  • The tool is chosen and working; it just needs connecting.
  • A small choice that's easy to reverse. Try it.

Where this capability is used

Next to technology selection

Questions about technology selection

Do you have a preferred stack?

Yes, as a starting point: tools we know well and can support. We change it when your requirements or existing systems call for something else, and we say why.

Will you make us replace our tools?

Only if they can't do what's needed. Tools that work are usually kept and connected.

Can we see the options you rejected?

Yes. Every decision record lists the options considered and why the others lost.

What if a choice turns out to be wrong?

The record says what would change it. When that happens, the decision is revisited on purpose instead of being worked around.