← All field notes

02Decision log / Internal software

Do you need custom software—or one less workaround?

The right answer may be existing SaaS, a repaired process, a small automation, or a focused internal tool. Diagnose the repeated cost before choosing the category.

DECISION MACHINE / 02FIND THE REPEATED COST FIRST
Real Company character connecting tools in a workflow
CURRENT ANSWERCONNECT NARROWLY
Decision
Buy, connect, automate, or build
Starts with
The repeated workflow
Avoids
Software for its own sake

Core premise

Existing software wins when the process is genuinely common.

SaaS is usually the best first choice for standard jobs such as accounting, scheduling, support, analytics, and document collaboration. You gain maintenance, security work, support, and improvements shared across many customers.Four decisions / 01—04
01

Buy when it fits

Existing software wins when the process is genuinely common.

SaaS is usually the best first choice for standard jobs such as accounting, scheduling, support, analytics, and document collaboration. You gain maintenance, security work, support, and improvements shared across many customers.

The question is not whether custom software feels more prestigious. It is whether the existing product can carry the important workflow without forcing the team to rebuild the missing part every day.

  • The workflow is standard
  • The product covers the critical path
  • Integration is reliable
  • Recurring cost remains lower than ownership
01BUY

Common job

Source / real work / 01
02

Find the workaround

The real requirement often lives between the tools.

A team may own several capable products and still copy data between them, maintain a private spreadsheet, ask one person to remember exceptions, or repeat the same status message in three places.

That repeated bridge is the evidence. Before proposing a platform, trace who performs it, how often, what mistakes cost, and which decision the missing context prevents.

  • Manual copying and reconciliation
  • Approval hidden in chat
  • One person as the unofficial API
  • Reports rebuilt from several exports
  • Customer status nobody can see completely
02TRACE

The workaround

Source / real work / 02
03

Build the narrow tool

Custom should mean specific, not enormous.

A useful internal tool can be one focused interface over existing systems. It may connect data, expose the next action, automate a handoff, or make one operational state visible.

The first version should remove a measurable repeated cost. It does not need to replace every product the company already uses.

Explore internal tools and automation
03BUILD NARROW

One knot

Source / real work / 03
04

Count the whole cost

Compare subscriptions with ownership honestly.

Custom software creates responsibility: hosting, security, access control, monitoring, maintenance, documentation, and future changes. SaaS creates dependency, recurring fees, limits, and integration risk.

Write both costs down. Build when the repeated operational value and control justify ownership—not because the demo looks cleaner than the current spreadsheet.

  • Frequency and cost of the workaround
  • Risk of errors or missed action
  • Integration and data ownership
  • Maintenance owner and budget
  • Expected lifetime of the workflow
04COUNT

Ownership

Source / real work / 04

What should survive

Show us the workaround your team repeats every week.

We will help decide whether to buy, connect, automate, or build—and keep the first version focused.Start a project

FAQ

Questions, answered directly.

Is custom software always more expensive than SaaS?

Not always, but it carries ownership costs that must be counted. A narrow tool can make sense when a costly repeated workflow remains unsolved across several subscriptions.

Should an internal tool replace existing software?

Usually not at first. The smaller opportunity is often connecting existing systems or giving one missing workflow a clear interface.

What should the first version prove?

That it removes a repeated cost, reduces a meaningful error, shortens a handoff, or makes an important operating state reliably visible.