Behind The Business delivers operational backend systems for founder-led service businesses. The work covers everything from the initial read on what the business is carrying through the long-term running of the systems built. The layer the business runs on day to day gets owned end to end.
My work focuses on the operational backend. I don't sell strategy, scaling playbooks, or recipes for getting bigger. I build the systems that support how the business runs day to day, so the founder can spend their hours on the parts of the business only they can do.
Every engagement runs in three movements. Each phase has a clear scope, a clear exit, and a deliverable you can hold against the work that came before. You can stop at the end of any phase.
I map the business as it runs today. Not the org chart or the tool stack on paper. The actual flow of work, data, and decisions across the team. Most founders walk in with what they think the problem is. In my experience that initial reading covers roughly five percent of the actual scope. The audit is what reveals the rest.
What you get:
The audit is its own engagement. Many founders use it as a standalone read before deciding whether to commit to the build.
Three to six months is the starting point. Full development depends on the actual build requirements: the scope of what's being rebuilt, the systems being replaced, the integrations involved, and how much legacy is already in the way. After the audit, you get a written read on the real timeline before anything starts.
Untangling legacy is usually the hard part. Most founders assume the build is the heavy phase. In practice, the actual build work is often the easier part. The harder work is understanding what already exists: the patched-together tools, the workarounds the team has built around broken systems, the half-finished automations from earlier attempts. Until that's untangled, anything new layered on top inherits the same fragility.
How the build runs:
Most operations work ends at handoff. The run phase is what makes this a practice and not an installation. I stay in the system, tune what needs tuning, fix what breaks, and make sure the backend survives without me before the engagement ends.
What happens in run:
The build phase covers the systems that hold the business together day to day. The specifics depend on what the audit surfaces, but most engagements touch some or all of the following layers:
Structure, configuration, and ownership rules for the system that holds client history, opportunities, and the relationships the business runs on.
The way work moves from intake through delivery. Stages, handoffs, ownership, and the points where the system needs to ask the team or surface a decision.
The rules that run quietly in the background. Triggers, conditions, escalations, and the cleanup work the team shouldn't be doing manually anymore.
Making the tools talk to each other. Sales tool to delivery board. CRM to billing. Project status to client-facing reporting. The seams between systems where most rebuilds break down.
The dashboards and reports that surface what the team and the founder actually need to see. Built so you stop having to assemble status manually.
Who sees what, who can change what. Designed so the system reflects how decisions get made, not who happens to know how to use the tool.
Documentation built alongside the system, not after. The kind your team can actually inherit. Designed for handoff to a successor or an in-house hire.
The team gets brought up to speed on the parts they'll own. Live sessions, recorded walk-throughs, and a documented baseline they can come back to.
Engagements typically span six to twelve months end to end. I take on a small number of founders at a time so the work stays direct and the read on the business stays sharp. There is no account team. There is no junior layer between you and the work. You work with me directly.
Every system decision gets made with you in the room. I bring the architecture and the reasoning. You bring the read on the business. Nothing ships without your sign-off. I'll push back when something doesn't fit, and I'll tell you when a decision is going to cost you later. That's part of the practice.
I don't show up with a preferred stack or a target industry. The infrastructure gets designed around how your business runs, not around what I'm most comfortable building.
Tool choice follows the business. If your operation runs best on HubSpot, the build is HubSpot. If it needs Airtable, GoHighLevel, Zoho, Salesforce, or some combination, that's what gets used. Part of the work is researching the tools that actually fit your operation, then configuring and connecting them.
Industry choice follows the founder shape. The pattern that breaks businesses at this stage is consistent across professional services, advisory practices, consulting firms, regulated field services, and multi-location service operations. The industry shapes the specifics. The underlying work is the same.
Agnostic doesn't mean everything is a fit. Some businesses need a fractional COO. Some need an operations consultant. Some need an in-house hire. The audit is what reveals which shape of help actually fits, and where it points elsewhere, I'll say so directly.
The practice fits founders running successful service businesses who have become the only person who knows how it all fits together. Revenue is in the range where the backend can't be held in your head anymore, but the business isn't big enough yet to hire a full operations leader. The team can deliver the work, but every system question still routes back through you.
If that's the shape you're in, this is what I do. More on fit on the About Tobey page.