Scaling a Startup: Advice from Experienced Founders

The advice I would give my past self is this: find your second-in-command before you think you need one.

When I was building The COO Solution in its early stages, I carried both sides of the business simultaneously, as most founders do. The vision and the execution. The strategy and the operations. The client relationships and the internal systems. It felt necessary at the time, and it was, up to a point. But I held on to that dual role longer than I should have, telling myself the business was not yet ready for the overhead of another senior person, when the truth was that I had not yet fully accepted that my highest value lay not in execution at all.

What I would have done differently is draw that line earlier. Not when the ceiling forced the conversation, but before the ceiling appeared. The cost of waiting is not just the founder’s personal bandwidth. It is the organizational habits that form in the absence of a real operator. Teams learn to route everything through the founder. Decision-making is centralized by default. The founder becomes the bottleneck without anyone intending it, and by the time it is visible, it has already been expensive for longer than anyone realized.

The broader lesson underneath that specific advice is that scaling is not about doing more. It is about becoming clear on what only you can do and building the structure that handles everything else without requiring your presence. The founders who scale most successfully are not the ones who figure out how to carry more. They are the ones who figure out earlier what to stop carrying and who to hand it to.

The second-in-command is not a delegation solution. It is a structural decision that changes what the whole business can become.

If I could sit my past self down, I’d say this: stop saying yes to everyone who wants in. Early on, I treated every wellness creator who showed interest in Breakthrough as a win. A yoga teacher wants an app? Great, let’s build it. A meditation guide with 400 followers wants in? Sure, why not. I thought more creators meant more proof the model worked.

What I didn’t understand yet was that saying yes to the wrong creator costs you more than saying no ever does. A coach who isn’t ready – no real content strategy, no sense of who their audience is, no plan beyond “I want an app like everyone else has” – ends up needing far more hand-holding, produces a mediocre product, and often churns anyway. Multiply that by dozens of creators and you’re spending all your energy propping up accounts that were never going to work, instead of going deeper with the ones who were.

It took building an actual qualification process for the marketplace before I saw this clearly. Once we started being selective about which creators we brought into that initial launch – actually screening for content readiness, audience clarity, commitment – everything got easier. Support requests dropped. The creators who did get in built better, launched faster, and started referring other serious coaches our way. Word of mouth from ten committed creators did more for us than word of mouth from fifty half-in ones ever could.

So the advice is simple, even if it took me a while to actually believe it: exclusivity isn’t unkind, it’s a filter that protects everyone’s time – yours and theirs. A creator who isn’t ready doesn’t benefit from getting a half-finished app; they benefit from being told honestly that now isn’t the right moment.

What I’d have done differently is build that qualification thinking in from day one instead of learning it the hard way after months of over-extending myself for creators who weren’t set up to succeed. Growth that comes from chasing every lead looks impressive on a slide, but it’s brittle. Growth that comes from saying no more often than you say yes is slower to show up, but it’s the kind that actually holds.

One piece of advice I would give my past self about scaling a startup is to stop letting cross-functional debate drain your engineering team’s time. When we were scaling AI systems for millions of daily users at Leboncoin, and later when building AGO, progress would often stall when teams debated who owned an edge case. If an autonomous agent failed to ingest a highly specific type of knowledge base, for example, we would sit in triage meetings trying to decide if it was a core product bug or just a customer success gap.

Knowing what I know now, I would have bypassed those meetings entirely and let our infrastructure dictate ownership from day one. I would tell my past self to set a strict threshold based on manual intervention triggers right out of the gate. If a customer issue reveals a structural failure in the underlying AI, engineering automatically owns the ticket. If it just requires adjusting a standard workflow or handling general friction, operations owns the resolution completely, with zero technical sign-off required. Fiercely guarding our technical team’s time for complex architectural fixes, rather than everyday noise, noticeably changed the pace at which we could actually ship and scale.

I’d tell myself to build the teaching system first, then worry about the technology. I wasted months building video platforms and course delivery systems when my students just needed clear lessons that built on each other. Start with ten paying students and obsess over whether they’re actually getting better. If they’re not improving week over week, your fancy platform is worthless. The biggest mistake? Hiring developers before I’d taught enough students myself to know what they actually needed. I should’ve stayed small longer. Your methodology is your competitive advantage, not your tech stack. Get that right by teaching real people, write down everything you learn, and only scale when students are asking you for more capacity.

Do not scale activity before you can scale the explanation.

At Megavrse and later IOPn we were operating in Web3 through difficult cycles, and the instinct when growth stalls is to add. More partnerships, more channels, more content, more announcements. We did all of it. Some of it worked.

What I would tell myself is that every addition inherits whatever clarity you already have. If the company takes twenty minutes of founder explanation to land, scaling does not fix that. It multiplies it. You end up with more surface area, all of it slightly wrong, and a founder who has become the bottleneck in every room.

The test I use now: ask a partner to describe your company to their colleague, then listen to what comes back. At IOPn, the deals that closed, including the $100m RAK DAO partnership and a joint venture with an ADX-listed company, moved because the counterparty could carry the story internally without me. The ones that stalled usually stalled after the meeting, in rooms I was not in.

Scale the sentence before you scale the spend.

Hire before you feel overwhelmed; don’t just wait. I was far too afraid to bring anyone in because I thought doing all of it alone was a sign of how committed I was. It was really just proof of how fast one person can combust under the guise of “dedication.” By the time I got people on, I was throwing tasks at them in a frenzy as opposed to transferring them with purpose. The onboarding process was chaotic due to my exhaustion, and the transferring was equally sloppy because I just didn’t have anything left in the tank for handovers. If I were the me of two years ago, this is what I’d be telling myself. Hiring is a sign that you believe in your own company. You bring people on as soon as you feel the strain, not once the wave has already crashed over you. One person only has so much reach. Your business does not.

I’d tell myself that the culture you tolerate early is the culture you scale. When you’re small, one person who’s brilliant but difficult feels like a trade worth making, because you need the output and there are only a handful of you. What I didn’t see is that everyone is watching what you put up with, and every hire after that quietly calibrates to it. You’re not just keeping one awkward person, you’re setting the standard for what the next twenty will think is acceptable.

What I’d do differently is act faster on the mismatches I could already feel, rather than waiting for undeniable proof. The times I let something slide because someone was talented, it cost us more later in the tone of the team than their work ever added. Scaling doesn’t just multiply your headcount, it multiplies whatever you’ve decided to ignore, so the honest version of the advice is fix the small things while they’re still small enough to fix.

If I could talk to my earlier self about scaling, the advice would be to obsess over keeping customers before spending a dollar to get new ones.

Early on the exciting metric is growth, new signups, new logos, the top of the funnel. What I underrated was that a business leaking customers out the back can’t be fixed by pouring more in the top. You just pay more and more to refill a bucket with a hole in it. If I’d understood sooner that retention is the real engine, I’d have put my earliest energy into onboarding and support instead of chasing acquisition.

The number I wish I’d watched from the start is churn. We now hold it under 2% a month, and that single figure does more for the health of the company than any growth spurt ever did, because low churn means every new customer compounds instead of replacing someone who left. Scaling on a shaky retention base just scales the leak.

What I’d have done differently is simple. Fall in love with the customers you already have, make the product and the support so good they don’t leave, and let growth stand on that instead of substituting for it. Boring, and it’s the whole game.

I would tell my past self that speed without process is simply expensive chaos arriving sooner. In online dispute resolution, the cases that drag on are usually the ones where nobody agreed on a clear process at the start. Startups behave the same way because growth exposes every shortcut and sends the bill at the worst possible moment.

I would build the boring structure much earlier, before the volume demanded it. The temptation is to chase revenue and fix the plumbing later, but later is when those repairs become hardest and most expensive. A small team that documents how decisions get made can preserve its judgement when it triples in size.

Teams that skip this work end up debating the same questions every week. The deeper lesson is about founders as much as systems. Leaders get into trouble when they keep relying on the strength that brought them this far instead of adapting as the market changes.

Flexibility ages better than brilliance. Build the process while it still feels unnecessary because once it feels urgent, you are already behind. I would have traded a little early speed for far more control later.

I would tell my past self to treat cash flow and healthy margins as the gate you must clear before you scale. When I built EESI, growth looked great on paper as we expanded to five offices and served more than 1,200 clients, but inventory, fleet, payroll, and sales costs were rising faster than profits. Knowing what I know now, I would have slowed the pace sooner and been more willing to say no to opportunities that added overhead before the business could support it. Scaling should strengthen the business, not stretch it so far that one bad quarter puts you in a bind.

What I would tell my past self is to identify what must never be diluted before scaling. Growth often brings pressure to add more products, features, and ideas, but more does not always mean added value for families. Knowing what I do now, I would have established product principles sooner: Does this enable active play? Can children interact with it in multiple ways? Will it still be useful as they grow?

Finally, I would have used parent feedback as a design criterion rather than treating it as an ongoing wishlist. Parents have diverse needs, and trying to please everyone can pull a startup in too many directions. My recommendation is to cluster feedback based on the core problems families are trying to solve and look for patterns. This approach maintains a clear focus on meaningful growth while allowing for thoughtful enhancements that truly reflect how kids learn and play.

If I could tell my younger self something, it would be to stop thinking I need to be involved in everything to be a good leader. When a company is new, it’s helpful to know about every decision so things move fast and are done well. But as the company grows, this can be a problem. It teaches employees to wait for the boss instead of making their own decisions. I wish I had written down rules for making decisions earlier. I would have made it clear what employees could decide on their own. I would have checked how well I was doing by seeing how often employees needed my approval for routine work. Giving tasks to others is not just about getting them off your to-do list. It’s about giving them enough information to make good decisions without you. A company can grow when the boss is not the only one who knows all the answers. If everything depends on one person, the company will not be able to grow much.

I would tell myself to separate growth from demand. I co-founded an analytics platform that scaled to over a billion dollars in cumulative volume and about a hundred thousand daily users at peak, on six million raised. Those numbers were real, and I read them as proof the market wanted what we built. A lot of it was proof that the market was hot and we were free.

Usage is not the same as willingness to pay, and neither is the same as a business. I now ask a much more boring question early: who is the person who would be in trouble if this went away tomorrow, and does that person control a budget? If the honest answer is “lots of people like it,” that is an audience, not a market. Audiences evaporate when conditions change. Budget holders do not.

What I would have done differently is spend the expensive year differently. We used a strong growth period to build more product, because that felt like momentum. I would use it to find whether anyone would pay, while we still had the leverage of being the obvious choice. Pricing is easiest to test when you are winning, and almost everyone waits until they are not.

The second thing: I would hire for the stage I was in, not the stage I was projecting. Hiring ahead of the curve feels like conviction. Mostly it front-loads burn and adds coordination cost to a team that was fast precisely because it was small.

Everything else, product decisions, the wrong integrations, features nobody used, was recoverable. Confusing traction with demand is what compounds.

I’d tell myself to focus on thought leadership before obsessing over features. When I started RankAISearch, I spent way too much time trying to perfect our AEO methodology. But visibility creates credibility, and credibility drives growth faster than having everything dialed in.

I should’ve started publishing what we were learning much earlier, even when it felt too soon. The brands that came to us early didn’t pick us because we had some flawless process. They picked us because we were talking about Answer Engine Optimization when nobody else was.

You don’t need to have it all figured out first. Your expertise grows when you share it in public. Make yourself the person people think of in your space right from the start.

I’d tell my younger self to stop treating every opportunity as if it deserves an immediate “yes.” Early on, I thought scaling meant doing more—more features, more partnerships, more marketing channels, more experiments. In reality, each new initiative quietly competes with the others for attention, and attention is usually the first thing a startup runs out of.

Looking back, I would have been much more disciplined about cutting projects that were merely promising instead of doubling down on the handful that were clearly working. Saying no feels uncomfortable because you worry you’re walking away from growth. More often, you’re protecting it.

The biggest surprise about scaling is that complexity grows faster than headcount. Every new product, process, or tool creates decisions someone has to make every day. The companies that scale well aren’t necessarily the ones moving the fastest. They’re the ones that stay simple long after they have the resources to make everything more complicated.

The advice would be to slow down on the code and speed up on the hiring. When I was scaling Capture Expense, the instinct was to build features quickly to win customers, and that is right up to a point. What I underestimated was how much early technical debt would tax every release that came after it.

Knowing what I know now, I would have invested sooner in the foundations that are dull to build and expensive to retrofit: automated testing, clean data models, and clear boundaries between parts of the system. Shortcuts that save a week early can cost a quarter later, once real customers depend on the thing you rushed.

The other change would be hiring for judgement over raw speed. A smaller team that makes good calls under uncertainty tends to outpace a larger one that needs everything specified. Scaling is mostly about the decisions you avoid having to unpick.

One crucial realization I would share with my younger self is the absolute necessity of decoupling specialized custom design consultations from standard order fulfillment workflows by building robust, self-service automated design tools for online buyers. In the early stages of scaling, allowing complex custom cabinetry and luxury closet layouts to bottleneck at the desk of senior interior designers creates severe operational throttling, inflates sales overhead, and drags out the conversion cycle by days or weeks. Had I prioritized developing interactive, web-based parametric design software and real-time instant rendering engines from the start, customers and trade contractors could have self-configured, previewed, and finalized their room dimensions independently, allowing our expert design team to focus exclusively on high-value commercial accounts while dramatically accelerating our order-to-production pipeline.

I’d tell my past self to stop hiring developers for automation work.

That sounds counterintuitive. You need automation, so you hire someone who codes. That’s what I did for the first three years running our ORM work and media business. I’d post job descriptions looking for Python developers or Node.js engineers who could build internal tools. What I got were people who could write code but had no idea what the business actually needed.

The turning point came when I hired someone from our operations team who had never written a line of code but understood every bottleneck we faced. I taught her n8n, our automation platform, in two weeks. Within a month, she’d built a press release humanization pipeline that ran AI detection scoring, flagged trigger words, and looped rewrites. A developer I’d hired six months earlier was still trying to architect the same system.

Here’s what I learned: ops people who learn automation tools outperform developers every single time. They know which problems are worth solving. They know what good output looks like. They don’t over-engineer. A developer builds for elegance. An ops person builds to ship.

The second thing I’d tell myself is to productize your internal tools sooner. We built a coverage tracking system for our own PR work. Used it internally for two years. Then a client saw it during a reporting call and asked if they could buy access. That became our SaaS product. We built a LinkedIn monitoring system to qualify inbound leads. Kept it internal for 18 months. When we finally packaged it, three clients signed within a week.

The pattern repeats. If you built something that saves your team four hours a week, someone else will pay for it. Most founders treat internal tools as cost centers. I did too. That was the mistake. Your internal efficiency is someone else’s revenue stream. Stop hoarding it.

The advice I’d give is to get closer to your customers earlier than feels necessary. When you’re building in the early days there’s always a pull toward the product, toward the next feature, toward the next thing on the roadmap. But the most valuable information we got wasn’t from building, it was from conversations with the firms actually using Vinyl.

What I would have done differently is structured those conversations more deliberately from day one rather than letting them happen organically. We learned things from our beta users that changed the direction of the product significantly, including the decision to build a mobile app for in-person meetings. That insight came from listening, not from anything we planned. If I’d been more systematic about it earlier, we’d have got there faster.

If I could hand my earlier self one piece of advice about scaling, it would be to hire slower and fire faster, because I got that backwards and it cost me.

Early on I hired in bursts whenever things felt overwhelming, and I kept people too long when it was clear the fit was wrong, because letting someone go felt like failing them. Both mistakes came from the same place, avoiding short-term discomfort at the expense of the thing I was building. A wrong hire made in a rush does not just underperform, they change the culture, absorb management time, and quietly lower the bar for everyone around them. Scaling multiplies whatever you already have, including the problems.

The other thing I would tell myself is that scaling too early is as dangerous as scaling too late. I poured resources into growth before the core was repeatable more than once, and paid for it. The right move was to nail the thing that worked, prove it held, then add fuel. Looking back, I would say close to 30% of my early spend went into scaling something that was not ready. Get the fit right, prove it repeats, and be far more careful about who you let in as you grow.

One piece of advice I would give my past self is not to treat a lack of immediate demand as proof that an idea is wrong.

When you are scaling a startup, it is easy to rely only on what customers are asking for today. But some of the most valuable opportunities come from seeing where the market is going and building before the demand becomes obvious.

“Looking around the corner is riskier, but getting there first can create an advantage that is almost impossible to buy later.”

Knowing what I know now, I would spend more time distinguishing between a bad idea and an early idea. The absence of a proven market increases the risk, but it can also increase the reward if the underlying behavior, technology, or customer need is clearly moving in that direction.

The key is not to ignore validation. It is to validate differently. Instead of asking only whether people are buying today, look for early signals such as changing behavior, new technology adoption, rising search interest, customer frustration, and shifts in how decisions are being made.

I would still protect cash and test cheaply, but I would be more willing to invest in opportunities where the market was emerging rather than already crowded.

“The safest opportunity is usually the one everyone can already see, which is also why it often has the least upside.”

I have a decade plus of experience building, launching and scaling startups, including a number of which that have been acquired. My biggest piece of advice is that it is just as hard building a startup that you charge $10 per user for, as it is building one that you can sell for many multiples of that.

My first tech orientated startup was a task management solution called Task Pigeon, where we had an average cost per user of just $9. The sheer number of users you need to scale to, in order to generate meaningful revenue is significant.

If you are opting to bootstrap, rather than raise external funding then it is significantly harder taking this approach, as opposed to focusing on a solution that you can sell for hundreds or even thousands of dollars a month. So while it is great to cut your teeth on problems you perceive to be easier to solve, my advice is to aim higher and don’t be afraid to go after problems you can charge significantly more for.

I would tell my younger self to stop hiring managers too early because a small team moves much faster than a heavy staff. Scaling feels like you need more supervisors, but adding layers just slows down your daily progress. I now know that smart people perform better when they interact directly with your buyers instead of navigating internal bureaucracy.

I maintain a flat structure to keep our internal speed high and our costs low. My team focuses strictly on solving the biggest problems our customers mention in direct conversations. That gives us an authentic edge because we communicate from the perspective of the people who actually use our product.

In my experience, you waste precious capital building things that buyers never requested. You should prioritize getting your product into the hands of users so they see results within the first month. Your retention stays high when you only succeed by helping your customers win in their own market.

If I could go back in time and give advice to my younger self about scaling a startup, it would be this: build for regulation and operational complexity NOW, not when you think you need to.

Automotive finance and claims management is a sector where growing too fast will show cracks in your compliance processes, customer journey, and reporting lines way before you think it will. In the early stages, your attention is consumed by winning customers and growing revenues. But my advice would be to future proof where possible by having the right people and processes positioned and ready to scale. Generally, the businesses that win are the ones who can react quickest when the market or regulatory tides turn.

With what I know now, I would have invested in scalable tech and specialist people way sooner than when demand required me to. Growth is about building resilience, not just growing for the sake of it. It’s always cheaper to scale early than it is to scale late. If you’re in a regulated industry, build your business for tomorrow’s problems today.

I’d tell myself that mistakes are inevitable. As cliche as it may sound, you need to understand that your job isn’t to make perfect decisions; it’s to make the cost of each bad decision cheaper. Throughout the years, I’ve learned that great companies still make mistakes, but they spot them quickly and reverse them just as fast. If I could start over, I would break big decisions I have to make into smaller experiments to create a better chance of bouncing back regardless of the outcome.

I would tell my past self to narrow the problem earlier. It is tempting to build for every promising customer and treat every feature request as urgent. A startup becomes scalable when it identifies a repeatable problem and builds its product, sales process and onboarding around solving that problem consistently.

If I could go back in time, I would tell myself to think bigger.

It’s tough because a few months after we opened our first location, the pandemic hit and derailed our business. However, it’s a process, and had I thought bigger from the beginning, I would have been in an even stronger position going into and emerging from the pandemic. It’s tough to challenge yourself when you’re uncertain of the success, but realize bigger matters, because no matter how large you think your margins are in any given business, they will be eaten away by things outside of your control. So, by being bigger, with smaller margins, the net can be the same. And in business, it’s all about the net!

Knowing what I know now, the one piece of advice I would give to my past self would be to change my approach to hiring. Whereas in the past, I would prioritize hiring people who felt most like me or people who I simply liked. I have since learned the importance and the benefit of hiring people who are not necessarily similar to me but are qualified to do the job and are still aligned in terms of our company culture and values.