About Tobey Tobias

Behind The Business is the practice I built around a specific founder I kept meeting. They started a business doing the thing they were great at. Somewhere along the way they became the person running all the systems behind it: client data in their head, project status in scattered tools, the operations layer running because they remember every detail.

The work most operations firms do treats this as a tooling problem. New CRM. New project tool. New SOPs. The founder still ends up holding the weight, because nothing was designed around how they actually run the business.

I built this practice to do the opposite. Understand the founder first. Build the backend around how they think and operate. Then stay long enough to make sure it survives the next quarter, the next hire, the next growth spike.

A short list of things I work from. Not values posters — operating principles that shape what I will and won't do inside a client.

• Understand before you build.
  Every system I touch starts with how the business actually runs today, not how it should look on a deck. The fastest way to ship something that breaks in six months is to skip this part.

• Own what gets built.
  I don't hand over a system and disappear. The build phase ends when the system runs without me. The run phase is what makes the difference between an installation and a practice.

• Solo practitioner positioning.
  Every client works with me directly. There's no account team, no junior layer between you and the work. The practice scales through pricing and selection, not headcount.

• Decisions are thought through with you.
  I won't pick the tool, design the workflow, or wire the integration without you in the room. Your business is the source of truth. I am the architect, not the founder.

• Operational focus, not growth strategy.
  I build the systems that support how the business actually runs day to day. Strategy, growth advice, and the playbook for getting bigger live with other practitioners. The backend I build is what supports your growth once it's there.

The engagement runs in three phases. Each one has a clear exit. You're never paying for time you can't account for.

• Audit
  Two to three weeks. I map the business as it runs today — tools, workflows, data flow, the parts you're holding personally. You get a written read of what's working, what's quietly costing you, and what we'd rebuild first if we kept going.

• Build
  Three to six months as a starting point. Full timeline depends on the actual build requirements — some backends are wider in scope, some have more legacy to untangle. I architect and build the backend around what we mapped: CRM, workflows, automations, integrations, designed around how the business actually operates. You're in the room on every system decision.

• Run
  Three to six months after build. I stay in the system: tune it, fix what breaks, make sure it survives without me. The run phase is what makes this a practice and not an installation.

Engagements are typically six to twelve months end to end. I take on a small number of founders at a time so the work stays direct.

I map the business as it runs today. Not the org chart, not the tool stack on paper. The actual flow of work, data, and decisions across the team.

Why a real audit matters. Most founders walk into a first conversation with what they think the problem is. In my experience, that initial surfacing covers roughly five percent of the actual scope. The other ninety-five percent shows up only when someone is inside the systems, talking to the team, and following the work end to end. The audit is what reveals the real shape of what needs to be rebuilt, not what looked broken from the outside.

What you get at the end of the audit:

• A written read of what's working and what isn't, with specifics.

• A list of what you're holding personally that the business is paying for in your time.

• A recommended sequence for the build. What to rebuild first, what can wait, what to leave alone.

• An honest read on whether Behind The Business is the right next move, or whether a different shape of help fits better.

The audit can also redirect you. Sometimes the audit surfaces that Behind The Business isn't the right answer. The problem might be people-shaped instead of systems-shaped. The right next move might be a fractional COO, an operations consultant, or an internal hire. When that's the case I'll say so directly, and where possible point you at a better fit. The audit is honest scoping, not a sales gate.

The audit is its own engagement. You can stop here. Many founders use the audit 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, the data living in tools no one remembers picking. Until that's untangled, anything new layered on top inherits the same fragility. A lot of the build phase is replacing or absorbing that legacy. New shapes only get added once the existing weight has been cleared.

I architect and build the backend around what we mapped. The build phase covers the systems that hold the business together: CRM, project workflows, client onboarding, internal automations, reporting, integrations across tools.

How the build runs:

• Weekly working sessions where decisions get made together. You see the system before it's built and after it's built.

• I do the work end-to-end. Architecture, configuration, integration, testing, documentation.

• Nothing ships without you signing off. You're never surprised by something the team can't unwind.

Most operations work ends at handoff. The run phase is the part that makes this a practice and not an installation.

What happens in run:

• I stay in the system. Tune what needs tuning. Fix what breaks.

• Team gets trained on the parts they own. I document the rest so the next person doesn't have to ask you.

• You decide when the practice ends. Some founders want a long run. Some want a hard exit. Both are fine.

Before Behind The Business, I worked as an execution partner across multiple founder-led service businesses in parallel. The role bridged fuzzy founder direction and what their teams could actually build. Equal parts pattern recognition, translation, and hands-on systems work across CRM, automation, workflow design, integrations, and project oversight.

The industries varied. Professional services firms. Advisory and consulting practices. Regulated field services. Multi-location service operations. Boutique founder-led practices in specialized fields. The pattern stayed consistent across all of them. Founders carrying more in their head than the business could support. Tools that didn't fit how they ran. Teams that couldn't move without them.

The fixes that worked started with understanding how the founder actually operated, then designing the backend to match. That pattern is what eventually became Behind The Business.

At some point the work stopped feeling like a service and started feeling like a practice. The founders I worked with weren't looking for a vendor. They were looking for someone to own a layer of the business they'd been carrying alone.

I started turning down the work that didn't fit the shape. Tooling-only projects. One-off automations. Templated audits. The work that mattered was the work that asked the founder a different question first: what is this business actually trying to do, and what's getting in the way?

Behind The Business is a practice, not an agency. Every client works with me directly. There's no account team, no junior layer, no handoff to someone you haven't met.

This is a design choice, not a stage. Practices scale through pricing, selection, and depth. Not through headcount. I take on a small number of founders at a time so the work stays direct and the read on the business stays sharp.

Most operations practitioners come from one of two sides. Operators who picked up tools along the way, or builders who picked up operations along the way. Each background produces a different blind spot. Operators tend to scope from the team's perspective and underestimate the build. Builders tend to scope from the tooling perspective and underestimate the operational fit.

My background sits on both sides. I've held real operations roles inside service businesses, and I've held project management roles inside delivery teams. Operations taught me how a business actually runs day to day: what the team needs to keep moving, where decisions get stuck, what slows founders down. Project management came at the same work from a different angle: how to scope across teams, how to estimate against existing systems, how to sequence dependencies so a build doesn't collapse halfway through.

The combination shows up in the audit. Operations is what makes me ask the right questions about how the work moves through the team. Project management is what makes the rebuild scope realistic and the sequencing survive contact with the actual work. Most practitioners see one half of this picture clearly. Holding both is what lets the audit account for the parts most projects miss, and what keeps the build from running over once it starts.

This practice is built for industry practicing founders. Lawyers running firms. Accountants who built practices. Architects, engineers, financial advisors. Trade founders whose contracting, HVAC, or electrical business grew past a one-person operation. Founders who started doing the work they were trained for, then grew the practice into something bigger than they could carry alone.

The fit works because your expertise sits in your craft. Backend systems are a different discipline. The legal mechanics, the engineering specs, the trade knowledge, the regulatory weight: that stays with you. The operational architecture surrounding the practice is what I own. You keep direction of the business. The backend layer moves to me.

I don't show up with a preferred stack or a target industry. The infrastructure gets designed around how your business runs, not around the tools I'm most comfortable with or the niche I happen to know best.

Tool-agnostic. 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 into a working system. The operation is the source of truth. Tool choice is downstream of it.

Industry-agnostic. 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 specific industry shapes the details. The underlying work is the same.

Agnostic doesn't mean everything is a fit. Not every business needs what this practice does. Some need a fractional COO. Some need an operations consultant. Some need an in-house operations hire. The audit is what reveals which shape of help actually fits, and where the audit points elsewhere, I'll say so directly.

Some shapes of help this practice doesn't do. Naming them here saves both of us the discovery call.

• You're looking for growth strategy.
  I don't sell go-to-market, pricing strategy, scaling playbooks, or recipes for getting bigger. The operational backend supports growth once it's there. The strategy that aims for growth lives with other practitioners.

• You want a vendor relationship.
  If the plan is to hand over a brief and step back, this won't work. The audit and build require the founder in the room. Founders who treat that as an interruption don't end up letting go of the backend cleanly.

• The problem is people-shaped, not systems-shaped.
  If what you actually need is operational leadership (running standups, project routing, day-to-day decision flow), the right move is a fractional COO or an operations consultant. The audit will name this directly if it surfaces.

• You want one-off tooling work.
  Single integrations, one automation, a templated SOP audit. These are useful in other contexts. They aren't what this practice does best.

• You're early-stage and still finding product-market fit.
  The backend rebuild is for businesses that have something working. If the business is still figuring out what it sells, the operational layer isn't yet the bottleneck.

Founder participation isn't optional. The instinct is often to hand a systems builder a brief and step back, expecting the work to happen offstage. That's where most operations rebuilds break down. The questions I'll ask during the audit are the same questions the system has to answer once it's built. If you don't answer them, I have to infer them, and the inferences are what end up baked into the backend you'll eventually walk away from.

This is also what makes the handoff possible at the end. The system can only carry what you've taught it. Hours in the room during the audit and build are the cost of being able to step back later. Founders who stay engaged through the sync between operations and systems are the ones who actually let go of the backend cleanly. Founders who treat the audit as an interruption end up still holding the same weight after the build is done.

Three things from your side in practice:

• Access.
  To the systems we're rebuilding, the team that runs them, the data inside them. The audit can't be partial. The read is only as good as what you let me look at.

• Time in the room.
  Weekly working sessions during the build. Not status updates. Working sessions where decisions get made.

• Honesty about what's actually broken.
  The audit lands harder when you tell me what you've been carrying alone, not when I have to guess.

Two ways:

• LinkedIn. Send a note about what's running you. A few sentences is enough. I read every one.

• tobey@behindthebusiness.net. If you'd rather skip the platform.

I don't use intake forms. The first conversation is the intake.

Thirty minutes on a video call. No deck.

What I'll ask:

• What's the business doing today, and what's running you personally inside it?

• What does the team currently own, and where are the seams?

• What have you already tried, and what didn't hold?

What you'll get from me on the call: a real read on whether this is the right fit, not a pitch.

If the shape fits, you'll get a written scope for the audit within a week. The scope names what I'd look at, how long the audit would take, what you'd get at the end, and what it costs.

You decide from there. There's no follow-up sales cycle. Either it lands and we start, or it doesn't and we move on.