What is surgical software?

Surgical software is a development approach where instead of forcing organizations to adapt to standardized enterprise platforms (SAP, ERP, HRM), you build smaller, highly adapted systems that conform to the user's actual workflow. AI tooling has made code cheap enough to do this economically.

How is surgical software different from custom software development?

Traditional custom development is expensive because code is expensive. Surgical software leverages AI-assisted engineering to make the code cheap, shifting the value to requirements gathering, domain expertise, and knowing what to build. The methodology starts with extensive stakeholder interviews and workflow observation before any code is written.

What is the surgical software methodology?

The methodology has three phases: (1) Deep requirements gathering through stakeholder interviews, workflow recordings, and transcription analysis, (2) Detailed planning and data model design — getting the "data bones" right, (3) Rapid build using AI-assisted engineering. The ratio is roughly 60% understanding, 20% planning, 20% building.

Why surgical software instead of off-the-shelf platforms?

AI made code cheap enough to build systems that conform to how people actually work. Domain expertise, taste, and judgment are the moat — code can be replicated, but knowing what to build and why cannot. Surgical software invests 60% of effort in understanding the problem before writing a line of code.

← Digital Rain Technologies

Surgical Software

Software that adapts to you — not the other way around.

Enterprise software got the relationship backwards. Organizations restructure around SAP, contort workflows to fit Salesforce, hire consultants to translate their processes into someone else's data model. AI changed the economics. Code is now cheap enough to build systems that conform to how people actually work.

We call this surgical software: smaller, highly adapted systems purpose-built for a specific workflow, team, or operation. Not platforms. Not frameworks. Tools that fit like they were always there.

Principles

—Software adapts to users, not the other way around. If people have to change how they work to use your system, you built the wrong system.

—Capability over functionality. Don't ship features. Grow a team's capability. The difference: features get checked off; capability compounds.

—Build the data bones first, then add AI at the end. Get the data model and user flow right before layering on intelligence. AI on a broken foundation just produces confident wrong answers faster.

—Domain expertise is the real moat. Code can be replicated. Knowing what to build and why cannot. The methodology — not the technology — is what makes surgical software work.

—Pareto optimal. Focus on the 20% of effort that yields 80% of user delight. Surgical means precise — no feature bloat, no configurability theater.

Methodology

Surgical software inverts the traditional ratio. Most of the work happens before a line of code is written.

Phase 1: Understand                              ~60%
├── Stakeholder interviews (recorded, transcribed)
├── WhatsApp audio walkthroughs of actual workflows
├── Field observation — watch people work
├── Map the real process, not the documented one
└── Identify the 20% that drives 80% of value

Phase 2: Plan                                     ~20%
├── Data model design ("the bones")
├── User flow mapping
├── Scope to Pareto-optimal feature set
└── Validate with stakeholders before building

Phase 3: Build                                    ~20%
├── AI-assisted engineering (agentic, not vibe)
├── Spec → plan → build, not tweaking by feel
├── Mobile-first for field workflows
└── Ship, observe, iterate

Case study: Ridgeline

Field Provisioning Decision Engine

Built for Outward Bound Hong Kong

Outward Bound HK runs multi-day wilderness expeditions. Field staff need to calculate meal and ration requirements with precise safety margins — the kind of domain-specific logic that doesn't exist in any off-the-shelf system.

The old process: spreadsheets, institutional knowledge in people's heads, and manual calculations that worked until the person who built the spreadsheet left.

Ridgeline is a mobile-first decision engine that encodes the provisioning logic field staff actually use. Not an ERP. Not a general-purpose inventory system. A surgical tool for one specific, high-stakes workflow.

Mobile-FirstField OperationsDecision EngineSafety-Critical

ridgeline.works →Design blog →

Agentic engineering, not vibe coding

The industry calls it “vibe coding” — tweaking prompts until something looks right. That produces demos, not production systems. We practice agentic engineering:

—Spec first. Detailed requirements before the AI agent touches code.

—Plan explicitly. Architecture, data model, and user flow locked before build.

—Build with agents, review with humans. AI generates code at scale. Human taste and judgment determine what ships.

Taste can't be automated

AI regresses to the mean. It produces the average of everything it's seen. That's useful for boilerplate. It's useless for the decisions that make software feel right.

Taste is learned through apprenticeship — watching someone with good judgment make hard calls and understanding why. It's not documentable. It's not trainable into a model. It's the thing that makes surgical software surgical instead of just small.

Stop adapting to your software.

If your team is working around a system instead of with it, describe the problem and we'll shape a brief together — right here, right now.

orcontact@digitalrain.studio →

Built by Digital Rain Technologies. Founded by Augustin Chan, former Development Architect at Informatica (12 years, Fortune 500 data integration across APAC/MENA/Europe).

← Back to home