Custom software

We'll make your team cry.

In a good way. We'll explain in a minute.

You've hit the ceiling of spreadsheets and off-the-shelf tools. The answer isn't more software — it's software your team will actually use. We learn how the work runs and who has to live with the result, then build for that. You own all of it.

The problem

You're running a real business on software built for someone else's.

The off-the-shelf platform covers 60% of what you do, so your team spends its days working around the other 40%. Eventually they stop opening it at all and the real work moves back into a spreadsheet. You're paying for software you use an eighth of. The enterprise tools that would actually fit require revenue you don't have yet; the small-business tools broke two years ago. You're too small for one shelf and too complex for the other — so the gap is filled with spreadsheets, manual handoffs, and one person who carries the whole system in their head.

That person is usually the reason it works. They're also the reason it can't grow.

And you've heard the custom software stories — eighteen months, six figures, a tool nobody uses. So you stay on the duct tape, working harder inside a system that was never designed for the business you have now. The problem was never effort. Off-the-shelf software can't see the intricacy of how your business actually runs — and that intricacy isn't a flaw to be standardized away. It's the business.

What we build

Software your team runs the business on, not software that sits beside it.

Operations platforms.

For a professional services firm, we built the platform that schedules their entire field team — real-time availability across 40+ team calendars, session creation with instant calendar invites, double-booking detection, and reporting that shows utilization, overtime risk, and where inquiries are coming from, down to the neighborhood.

Profitability and time systems.

We built a platform that shows hours delivered against hours scoped, per client, as it happens. Run against a real accounting firm's books, it surfaced a client quietly consuming 129 hours against an 18-hour scope. The firm knew something was wrong. The system showed exactly where, and by how much.

Command centers.

We run Group 18 on one we built ourselves — time and capacity data ingested nightly, budget burn tracked per client, alerts posted to Slack before a problem becomes a surprise. We build the same for clients: the numbers you need to run the business, pulled from the tools you already use.

And we don't forget the connective tissue: integrations between the systems you already own, so data moves between them on its own, instead of getting re-typed by your team every week.

Why this is different

A development shop will build whatever you ask for. That's the problem. If the process is broken, faithful software just automates the breakage — we've watched companies deploy expensive systems and change nothing, because the software was never the root cause.

We start somewhere else. Discovery maps how the work actually flows — every tool, handoff, decision, and workaround — and, just as much, who has to live with whatever we build. That shapes the architecture before anyone writes code. The design keeps sharpening after that, because no process survives first contact with a working screen, and we'd rather find that out in week six than at go-live.

We also build for the whole life of the thing, not the demo: the metrics you'll use to know it's working, the configuration that lets it bend without calling a developer, the admin so someone on your team can run it, and an architecture that's still standing in three years. We run businesses ourselves, and we'd demand the same.

The test isn't whether it does what you asked for — any shop clears that. It's whether it does the thing you'd stopped bothering to ask for, because you'd written it off as just how the work goes. That's also why we care how it looks and where the buttons sit. People use what they like using, and software nobody enjoys opening is software that quietly goes unused.

Now, about the crying. At one of our first demos, a team member told the room she'd almost cried multiple times through the training — because the thing that made her job hardest was suddenly gone. That's the bar for every engagement. Software good enough that the people drowning in the old process feel the water drop.

That isn't the same as day one being frictionless. People arrive carrying years of muscle memory, and the first few weeks are a transition we plan for rather than pretend away.

And everything we build lives in your business. Code, documentation, credentials, training — you keep it all. No license to us, no hostage IP, no dependency dressed up as a service.

How it works

Every engagement starts the same way: a paid, fixed-fee discovery. After that we build in bounded phases, with working software in your team's hands during the build rather than a reveal at the end. Our longest-running platform is three phases in, and the client keeps choosing to build.

Start here

Discovery and architecture

$10K–$15K Four to eight weeks

We interview your team, map how the work actually flows, then design the architecture, the fix, and the price — before anyone writes code. You keep the blueprint either way. Stop here and you've bought clarity, not a sunk cost.

Then we build in phases

First build

$25K–$75K

Eight to twelve weeks

A working system in your team’s hands, scoped and priced before it starts.

Platforms

$100K+

Phase by phase

Larger systems grow across phases, each one earned by the one before it.

Fixed fee per phase, quoted before the phase begins. Go-live is in scope, not an afterthought: training, documentation, and a handoff designed so your team runs it without us.

Common questions

What does it cost?

Discovery and architecture is $10K–$15K. First builds typically $25K–$75K, fixed fee per phase. No hourly meter, no open-ended retainer. If scope changes, we re-scope the next phase — we don't quietly grow the bill.

How long does it take?

Discovery and architecture runs four to eight weeks. A build phase is typically eight to twelve weeks from kickoff to your team using it daily — and you see working software during the build, not at the end of it.

Who owns it?

You do. The code, the documentation, the accounts it runs on. If we disappeared tomorrow, another developer could pick it up from the docs — that’s a design requirement, not a courtesy.

What happens after launch?

Training and documentation are in the build. After that, most clients keep a small maintenance agreement for iteration and support; some run it themselves. Both are fine. It’s yours.

What if our requirements change?

They will — that’s why we build in phases. Discovery gets the first phase right; each phase after that starts from what your team learned using the last one. These are initial conditions, not what we’re locked into.

Let's see what you'd build.

A 30-minute conversation about where your business is, what's not working, and whether we can help. If we can, we'll tell you exactly what we'd do first. If we can't, we'll say so.

Not ready to talk?

Get the Catalyst — Kevin's weekly newsletter on designing businesses that scale without depending on you.