Designing Around Your Business

I show why renting a one‑size SaaS never fits, and how to map your real processes, replace the tools you use, and own a system that grows with you.

When I first walked into a midsize manufacturing firm that relied on a dozen SaaS subscriptions, the first thing I asked was simple: which of those tools actually moves a unit from raw material to shipped product? The answer was a handful, and the rest were legacy, redundant, or barely used. That gap between what they paid for and what they needed is the hidden cost I spend my career exposing.

Start with the real workflow, not the software menu

The temptation to start a rebuild by listing every app you own is strong, but it leads you back to the same mismatched stack you tried to escape. I begin by shadowing the front line for a full production cycle, noting every hand‑off, decision point, and data entry. Those observations become a process map that lives in a single spreadsheet, not a diagramming tool that disappears after the workshop.

Three questions keep the map honest:

• What triggers the next step?
• Who owns the data at that moment?
• Which tool, if any, is actually required to complete the step?

If the answer to the third question is “none,” you have an automation candidate. If it’s a SaaS product that only formats a report, that product is a candidate for replacement.

Turn the map into a modular operating system

A true operating system for a business is a collection of loosely coupled services that speak the same internal API. I treat each department as a module that publishes its inputs and subscribes to its outputs. The advantage is two‑fold: you can swap a module without breaking the whole, and you own the code that defines the contract.

During a recent rebuild for a 200‑person enterprise, we identified 21 SaaS tools that were either duplicating functionality or sitting idle. By extracting the core logic into a set of Node.js micro‑services and a shared PostgreSQL data layer, we eliminated the recurring subscription fees and gave the finance team direct access to the data model they needed.

The modular approach also lets you reuse the same service across 16 departments and 14 live bases without rewriting business rules. The only thing you need to change is the configuration that tells the service which data source to read.

Where automation belongs—and where it hurts

Automation is not a blanket solution. I always run a cost‑benefit matrix that weighs implementation effort against error reduction and employee time saved. If a task takes less than a minute for a human and occurs less than ten times a day, the ROI of an AI agent is usually negative.