Software built around your operation. Not the other way around.

Stax

John Cole

The hardest software problems usually aren't coding problems. They're problems of context: understanding the system, workflow, constraints, and tradeoffs well enough to know what should change.

I work on operational software where the difficult part is figuring out what should change. Sometimes that means building something new. Sometimes it means rescuing or modernizing what you already have. And sometimes it means working alongside your existing engineering team to get a difficult system or project moving again.

View pricing

What I Do

  • Operational software & internal systems
  • Legacy rescue & modernization
  • Systems integration & migration
  • Workflow & process engineering
  • Technical assessment & Groundwork
  • Ongoing systems stewardship
Fixed-price  ·  US-based
You own everything

Your operation developed rules no software vendor anticipated.

Complex operations accumulate rules, dependencies, edge cases, and exceptions over time. Those details often live partly in software, partly in documentation, partly in spreadsheets, and partly in people's heads.

When a project begins before that context is understood, even competent teams can build the wrong thing correctly. Off-the-shelf tools weren't designed for your exceptions either — so workarounds fill the gaps, and the workarounds become the system.

The result works at demo. The gaps surface three months in.

What I do differently

Software projects often move into implementation before the operational context is fully understood. I start with your operation — every stage, every role, every rule, every edge case. That understanding becomes the basis for deciding what should change, and only then for building, rescuing, or integrating.

Built without operational understandingBuilt operation-first
Works at the demo, gaps emerge in productionEdge cases designed in before significant implementation
Requirements miss how the work actually runsContext captures the workflow, the rules, and the exceptions
Workarounds compound over timeSoftware fits the operation — no gap to fill with spreadsheets
Changes require re-explaining the whole systemLiving documentation; context is always current

Diagnosis before implementation

Software built from a shallow understanding of the operation will miss the cases that matter. I spend real time learning how your operation and systems work before deciding what to change.

Edge cases get designed in

Not discovered after launch when they're expensive to fix. The exceptions and rules that make your business yours get accounted for from the start.

The software stays yours

Every project includes Groundwork documentation — architecture, data model, business logic. The system doesn't live only in my head when we're done.

Understand the system before deciding what to change

When an important system has become difficult to maintain, extend, replace, or even fully understand, the first problem is not implementation.

It is determining what you actually have, what the operation really needs, where the risk is, and which path makes sense.

Groundwork is a focused technical and operational assessment that maps the workflow, business rules, architecture, data, integrations, constraints, and risks behind the system.

The result is not automatically a development project. It is a clear recommendation.

What Groundwork can include

  • stakeholder and workflow review
  • current-system inventory
  • business-rule and exception inventory
  • architecture, data, and integration map
  • operational risk review
  • technical-debt findings
  • documentation of undocumented behavior
  • modernization or replacement options
  • prioritized implementation roadmap

Recommended path

A Groundwork engagement ends with a clear recommendation:

  • Maintain — the current system is basically healthy.
  • Stabilize — fix the risky pieces without rebuilding everything.
  • Extend — keep the system and add what is missing.
  • Modernize — replace components incrementally.
  • Rebuild — the current system no longer makes economic sense to preserve.
  • Replace — an existing platform may solve the problem better than custom software.

Standalone Groundwork assessments start around $3,500. Larger legacy, modernization, or multi-system engagements are scoped according to complexity.

Talk through your system →

Solve the right problem

Once the system and operation are understood, the right answer may be to stabilize what exists, modernize part of it, connect systems, build something new, or leave healthy pieces alone.

Rescue / Modernize

Untangle systems the business already depends on

Inherited, undocumented, or aging systems often contain years of business logic the operation still relies on. Making them safer to change requires understanding what they actually do before touching the code.

I work with fragile architecture, technical debt, stalled modernization efforts, unsupported components, and systems that have become difficult or risky to maintain, extend, or migrate.

Typical work includes:

  • legacy and inherited system assessment
  • reverse-engineering business rules
  • stabilization and technical-debt reduction
  • incremental modernization
  • migration and rebuild planning
  • replacement of unsupported components
Talk through what you're dealing with →

Integrate / Migrate

Connect systems and move data without disrupting the operation

Sometimes the problem is not that you need another application. It is that the systems you already use do not share data, support the full workflow, or can be moved cleanly to something better.

I build the custom layer between ERPs, inventory platforms, APIs, internal tools, shipping systems, accounting software, and other operational systems — and plan migrations so the operation keeps running.

Typical work includes:

  • API integrations
  • data synchronization
  • system-to-system workflows
  • migration planning and legacy data migration
  • automated imports and exports
  • middleware and reporting consolidation
Talk through the integration →

Build

Build when a new system is actually the right answer

Sometimes the operation genuinely needs software that does not exist off the shelf. When Groundwork or a clearly defined problem points to a new build, I design the system around the actual workflow rather than forcing the business into a generic application model.

Typical work includes:

  • internal systems and operational dashboards
  • inventory and order systems
  • workflow automation
  • reporting and admin tools
  • custom business applications
  • spreadsheet replacement
Talk through what you need →

Steward

Keep critical internal software healthy

Some businesses depend on custom software but do not need a full internal engineering team.

Systems Stewardship provides ongoing technical ownership: maintenance, planned improvements, integrations, architecture decisions, documentation continuity, and someone who understands how the system fits the operation.

This is not unlimited break/fix support. It is long-term ownership of software the business depends on.

Systems Stewardship starts at $2,500/month.

Talk about ongoing ownership →

Talk through your operation →

Work with the team you already have

Not every difficult software problem needs another development team.

Sometimes an existing engineering organization needs focused senior capacity around a specific system or project: an inherited codebase, difficult integration, migration, stalled modernization effort, architecture problem, or technical issue that needs dedicated attention.

Stax can work inside your existing development process for a defined problem, milestone, or period without replacing the team responsible for the system.

When I join an existing team, I work within its current architecture, planning, documentation, review, testing, and delivery conventions—filling gaps rather than imposing a parallel process.

Typical engagements

  • legacy/inherited system assessment
  • modernization planning and implementation
  • difficult integrations
  • system or data migrations
  • architecture cleanup
  • technical-debt reduction
  • testing and CI remediation
  • troubleshooting stalled projects
  • focused implementation around a difficult subsystem
  • technical review and verification

Have a team but still have a difficult problem? Let’s talk →

What this looks like in practice.

Logistics · Active

Auction-to-shipment operations portal

Situation

Fragmented auction-to-shipment workflow spread across multiple systems and manual steps.

Constraints

Multiple operational roles, three clear-check providers, and a process that could not pause while tools were consolidated.

Decision / approach

Build one operations portal around the real workflow rather than forcing the operation into disconnected tools:

  • lot management
  • bid management
  • three clear-check providers
  • warehouse check-in
  • label generation
  • outbound shipping/tracking

Result

Supports processing approximately 100k items across 10 operational roles and replaced 12 separate manual tools or spreadsheets.

Warehousing · Active

Full rebuild of a decade-old legacy system

Situation

A decade-old ColdFusion inventory platform with little or no usable documentation, a fragile/inaccessible data layer, and critical system knowledge concentrated in one person.

Constraints

The business still depended on the system day to day. The data layer was difficult to access. Institutional knowledge was not written down.

What I found

Reverse-engineered the actual workflow and business rules before changing the system. Groundwork documentation captured architecture, data relationships, workflows, and operational logic so the work would no longer depend on undocumented institutional knowledge.

Result

1M+ records migrated · 20 operational roles · goal of reducing manual work by more than 50%

Running something similarly complicated? Let's talk. Talk through your system →

If your operation or engineering team is stuck on a difficult system, we should talk.

You're running an operation with real complexity — multiple stages, multiple roles, specific rules that don't map to a standard template.
Off-the-shelf tools work for simple cases, but your cases aren't simple. You've built workarounds to fill the gaps.
You have a legacy system — old software, aging codebase, maybe an undocumented build someone handed off years ago — that you need to change without burning everything down.
You've started software projects before and still ended up with something that missed the workflow, business rules, or exceptions that matter in production.
You have internal software the business depends on, but not enough software work to justify a full engineering team. You need someone who can own the technical context, keep the system healthy, and improve it as the operation changes.
You already have a development team, but you're dealing with an inherited system, difficult integration, migration, stalled modernization effort, or another problem where focused outside senior capacity would help.

If you can build it yourself with standard off-the-shelf tools, you probably should. If your operation has genuine complexity that doesn't fit those tools — that's exactly what I do.

Clear scope. Clear pricing.

Focused systems

$8–15k

A contained operational problem with clear boundaries.

Examples: workflow automation, focused internal tool, reporting/admin system, API integration, dashboard, small operational application.

Operational systems

$15–35k

Substantial custom internal software supporting real business operations.

Examples: inventory systems, order-management systems, multi-role workflows, custom operations portals, substantial integrations, significant legacy-system replacement.

Complex platforms

$35k+

Systems spanning multiple stages, departments, integrations, or data sources.

Examples: end-to-end operational platforms, deep system integrations, major migrations, multi-team workflows, complex legacy rebuilds.

Systems Stewardship

from $2,500/mo

Ongoing technical ownership for software the operation depends on.

Can include: maintenance, planned improvements, integrations, dependency/security work, architecture, technical decision-making, documentation continuity, roadmap planning.

Collaborative engineering engagements

Work inside an existing engineering team is typically scoped around a defined problem, milestone, or monthly period rather than an entire system.

These engagements are quoted based on scope, duration, and required involvement.

Stax-owned projects use fixed pricing agreed before work starts. Groundwork documentation is included in build engagements. Complex or poorly documented legacy systems may begin with a standalone Groundwork assessment. Collaborative engagements are scoped separately based on the problem and required involvement.

Book a 30-minute call →

Free 30-minute call. No pitch.

Tell me what you're running on, what is becoming difficult, and where the workarounds are. I'll tell you honestly whether the right next step is to assess the system, stabilize or modernize what you have, build something new, work alongside your team, or do nothing at all. If I can't help, I'll say so.

© 2026 Stax · John Cole 100% U.S.-based · Fully remote · Senior-led