What should the founder stop doing next?

The hardest part of scaling a founder-led business usually isn't what to start doing. It's what to stop.

Building Handytamila from zero to four cities and 9,000+ customers meant I spent the first year doing almost everything, provider onboarding, pricing decisions, customer escalations, marketing calls. That was correct at the start. It became the constraint by month eight. The full story of that build is in ORQENA's case studies.

The three categories worth separating

Work a founder does generally falls into three buckets: decisions only the founder can make, work that should already be a documented process, and firefighting that shouldn't exist if the process were working. Most founders can't see the split clearly because all three feel equally urgent in the moment.

The second category is where the leverage is. In that engagement, that meant building a full SOP library in Notion so operational decisions that had been living in one person's head became something a remote team member could execute without asking first.

What actually has to stop

Approving decisions that already have a clear precedent. Being the only person who knows how a process works. Answering questions that a documented SOP should answer. None of these require the founder specifically, they require the founder to have written the system down once.

The goal isn't to remove the founder. It's to remove the founder as the bottleneck.

Letting go of pricing, specifically

Pricing is usually the hardest thing for a founder to hand off, because it feels like a judgment call every time. At Discount Bazaar, building the market entry pricing strategy meant running supplier audits and competitor pricing analysis once, then turning the output into a framework the team could apply without re-litigating every price point with me directly. The store launched with a competitive advantage from day one and kept it, because the pricing logic didn't depend on my ongoing involvement.

What stays with the founder

Direction, key hires, and the handful of decisions where the cost of being wrong is genuinely high. Everything else is a candidate for a system, a process, or someone else's ownership. This is the same sorting exercise behind how ORQENA approaches operating model design, deciding deliberately what a founder should keep, not defaulting to keeping everything.

The uncomfortable part

Stopping something you've always done well is harder than starting something new. It requires trusting a system you built to actually hold, and trusting a team to run it without you checking every step. That trust has to be earned by the system being genuinely documented, not assumed, which is why this only works as a sequence: diagnose the bottleneck first, as covered in the founder bottleneck as an operating-system problem, then build the system that lets you actually let go.