The Call I Keep Getting

A founder called me last week. His company just crossed $18M ARR. Team of 40. Engineering shipping constantly.

But he was frustrated:

“We’re building more than ever. My team is working harder than ever. But somehow everything is taking longer.  Simple changes that used to take days now take weeks. Our best engineers are talking about ‘technical debt’ but can’t tell me what it’s worth to fix it.

Why does it feel like we’re moving backwards?”

I hear this exact pattern 2-3 times a month.

And here’s what I’ve learned after working with 30+ growth-stage platforms:

It’s not the team. It’s not the effort. It’s not even the technical decisions.

It’s that the architecture that got you to $20M won’t get you to $50M.

You made the right choices for where you were. But systems built for survival don’t automatically scale for growth.

Let me show you what I mean—and more importantly, what you can do about it.

The Inflection Point Nobody Warns You About

Every platform hits this moment. Usually somewhere between $10M-$30M ARR.

The question founders ask: “How did we get here?

The real question: “How do we get past this without stopping everything to rebuild?”

 

 

What This Actually Looks Like?

Let me show you five patterns we see constantly. Not because teams did anything wrong—but because what worked at one stage creates constraints at the next.

Pattern #1: The Checkout That Blocks Growth

Your marketing team wants to test different pricing experiments. Your engineering team can ship maybe 1-2 per quarter.

Why? Business logic is hardcoded throughout the system.

When you built checkout 2 years ago, you had one payment provider, one market, one set of rules. Hardcoding made sense—it was fast.

Now that logic is embedded everywhere. Every pricing change touches multiple files. Every test requires software engineering work.

Meanwhile, your competitor runs ten experiments in the time you run one. They’re not smarter—they just separated business rules from code. Their marketing team configures tests themselves.

The real cost: You’re not just slow at testing. You’re slow at learning.

Pattern #2: The Integration Nightmare

We worked with a B2B marketplace where every new vendor type took 6-8 weeks of engineering time.

The problem? Each vendor integration was custom-built. Different data models, different APIs, different logic scattered across the codebase.

Adding “equipment rental” vendors after “equipment sales” vendors meant building a parallel system from scratch.

In the early days with 3 vendor types, this approach was fine—even fast. But scaling to 30 vendor types? The 28th vendor was just as expensive as the 1st.

Their growth was bottlenecked not by market demand, but by how fast engineering could build custom integrations.

Pattern #3: The Feature That Slows Everything Down

Here’s a conversation we hear often:

Founder: “Why does everything take so long now?”

CTO: “Remember when we could ship a feature in a sprint? Now everything takes a month, and I can’t even explain why.”

Here’s what usually happened:

18 months ago, you launched a referral program. Took a few weeks to ship. Works great. To move fast, it touched user registration, checkout, emails, dashboard, and payments.

Now every change to any of those areas has to “be aware of” referrals. Change checkout? Test referrals. Update emails? Hope referrals still trigger. Touch payments? Pray credits still work.

One engineering leader described it perfectly:

“It’s like running with a backpack. Every feature adds another brick. We’re still running, but getting slower—and we can’t figure out which brick to take out.”

The compounding tax:

• Features that took one sprint now need two
• Every release requires twice as much testing
• New engineers take months to understand “what connects to what“

Pattern #4: The “We’ll Fix It Later” That Never Happens

Your team knows exactly what needs improving:

• The payment provider should be swappable
• The search should be its own service
• The notification system should be event-driven
• The admin panel shouldn’t share a database with the main app

But there’s never time. There’s always a customer request, a sales promise, a competitive threat.
Here’s the insight most teams miss: “Technical debt” isn’t really debt. It’s tax.

Debt you pay off once. Tax you pay forever.

Every sprint, you’re paying it:

• Extra time for testing
• Extra complexity in every change
• Extra risk in every deploy
• Extra time onboarding new engineers

We worked with a logistics company that tracked this over a quarter. Their engineering team—about 8 people—spent roughly a third of every sprint working around technical constraints instead of building new capabilities.

That’s 2-3 engineers worth of capacity just managing complexity. Real engineering talent solving problems that shouldn’t exist.

Pattern #5: The Success That Created the Constraint

Sometimes your best early decision becomes your growth ceiling.

We worked with a SaaS company that built single-tenant architecture for their MVP. Each customer got their own instance.

Brilliant decision at the time—easy to customize, easy to isolate data, easy to reason about.
Three years later: 200 customers, wanting to grow to 2,000.

The constraint:

• Every new customer requires manual provisioning
• Every update gets deployed 200 times
• Infrastructure costs are 3-4x what they should be
• Onboarding takes 2 weeks (competitors do it in 2 hours)

Their brilliant MVP decision created an operational ceiling. They couldn’t scale customers without scaling their ops team 1:1.

Meanwhile, competitors with multi-tenant architecture could 10x customers without 10x-ing their team.

Here’s What’s Actually Happening

If you’re seeing these patterns, you’re not behind. You’re not failing.

You’re at an inflection point.

The systems you built to get here were right for that stage. But they weren’t built for where you’re going.

This is normal. This is expected.

Every platform that scales hits this. The question isn’t “How did we avoid this?” (you couldn’t have).
The question is: “How do we move past this without losing momentum?”

The Strategic Response (Not the Naive One)

Here’s what doesn’t work:

What Actually Works: Strategic Architectural Leverage

Here’s what we’ve learned works across our client engagements:

Don’t rebuild everything. Rebuild the 3-4 things that create the most business leverage.

Not the messiest code. Not the oldest systems. Not what your team complains about most.

The areas where strategic refactoring unlocks exponential velocity.

Three Companies That Got This Right

Let me show you what this looks like in practice.

Example 1: The Commerce Platform That Couldn’t Experiment

The Situation:

A mid-market commerce platform came to us with around $15M ARR. Growth had plateaued.

Their marketing team knew exactly what they wanted to test—different pricing structures, bundle offers, seasonal promotions. But every experiment required engineering work. They were running maybe 1-2 tests per quarter, sometimes none.

Conversion had been stuck in the low 2% range for over a year.

The marketing director told me: “We have a backlog of 30 experiments we want to run. We just can’t get engineering time.”

The Strategic Decision:

We didn’t rebuild their entire platform. We rebuilt one thing: their checkout and pricing architecture.

Separated business logic from code. Made pricing rules configurable. Built experimentation capability into the foundation.

The Investment:

Original estimate was 6 weeks and around $100K. Actual timeline was closer to 10 weeks and about $140K—we discovered their payment provider had some undocumented limitations we had to work around, and their discount logic was more tangled than anyone realized.

The Outcome:

Within the first quarter after deployment:

• Marketing ran 12 experiments themselves (no engineering tickets)
• Conversion improved from low 2s to around 3.5%
• By month six, they were consistently above 4%

The revenue impact? Their traffic was pretty stable, so going from roughly 2% to over 4% conversion meant they effectively doubled revenue from the same marketing spend. On their revenue base, that translated to several million in additional ARR.

But here’s what mattered more to their CTO: “My team isn’t firefighting pricing logic anymore. We’re building actual product features again.”

The Real ROI:

The direct revenue impact paid for itself in under 6 months. But the compounding effect is what matters—they can now iterate on pricing continuously. Each quarter they’re finding new optimization opportunities that would have been impossible before.

The lesson: One strategic architectural improvement unlocked their entire growth engine.

Example 2: The B2B Marketplace Stuck at Weeks Per Vendor

The Situation:

A B2B marketplace doing around $12M GMV had potential to 10x, but every new vendor type took 6-8 weeks of custom engineering. Competitors were onboarding vendor types in days.

The Diagnosis:

Each vendor type was a snowflake integration. No abstraction layer, no reusable patterns. Growth was literally bottlenecked by how fast engineering could build custom integrations.

The Strategic Decision:

We didn’t rebuild their entire marketplace. We built one thing: a vendor abstraction layer.

• Standardized integration points
• Created vendor “profiles” instead of vendor “code”
• Made data mapping configurable

The Investment:

Around $180K over 12 weeks. Timeline expanded a bit from the initial estimate as we uncovered edge cases in their existing vendor data models.

The Outcome:

New vendor types went from 6-8 weeks down to 2-3 days. They onboarded 16 new vendor categories in the next 6 months—previously they’d done maybe 4 per year.

GMV grew over 3x in 12 months once they removed this constraint.

The lesson: They didn’t need more engineers. They needed the right abstraction.

Example 3: The Logistics Platform Bleeding Margin

The Situation:

A logistics platform with razor-thin margins around 15-18%. Cost per delivery was eating their lunch, and competitors were undercutting on price.

The Diagnosis:

Manual dispatch operations meant riders were taking suboptimal routes. No intelligence optimizing for cost or efficiency.

The Strategic Decision:

We didn’t rebuild their entire logistics platform. We rebuilt one thing: dispatch from manual to algorithmic.

• Auto-assignment based on proximity and route optimization
• Predictive rider positioning
• Real-time re-routing based on new orders

The Investment:

About $90K over 10 weeks.

The Outcome:

Cost per delivery dropped from around $3 to roughly $2.10—nearly 30% reduction. At their volume, that meant saving close to $10K monthly.
Hit ROI breakeven in about 8 months. More importantly, they could now beat competitors on both price AND speed.

The lesson: They didn’t just digitize their process. They re-engineered their economics.

The Pattern You’re Seeing

None of these companies:

• Rebuilt everything
• Stopped shipping for 6 months
• Spent $2M on a rewrite

They all did the same thing:

✓ Identified the one architectural constraint blocking their growth
✓ Made a strategic, bounded investment to fix it
✓ Created exponential leverage from that single improvement
✓ Used the velocity gain to fund the next improvement

This is architecture-led growth.

Not architecture for architecture’s sake. Not technical perfectionism.

Architecture as a business investment with measurable ROI.

How to Find YOUR Leverage Point

Here’s what you can do this week:

Gather your leadership team (CEO, CTO, Head of Product, Head of Sales/Marketing) and ask:

     “What’s the one thing that, if we fixed it, would make everything else easier?”

Usually, there’s immediate consensus. Usually, it’s one of these:

For Product Velocity:

• The deployment process that makes releases scary and slow
• The testing infrastructure that catches bugs too late
• The code structure that makes simple changes ripple unexpectedly

For Business Agility:

• The checkout/payment flow that blocks experimentation
• The integration layer that makes every vendor a custom build
• The pricing engine that requires engineering for every change

For Unit Economics:

• The infrastructure architecture that’s expensive to scale
• The operational process that should be automated
• The manual workflow that doesn’t need to be manual

That’s your leverage point.

Once you know what it is, you can ask:

• What would it cost to fix strategically?
• What would we unlock by fixing it?
• What’s the ROI timeline?

In our experience:

• Investment: Usually $100K-$300K depending on complexity
• Timeline: 8-16 weeks for most strategic improvements
• ROI: Often within 6-12 months, sometimes faster
• Impact: Unlocks next stage of growth

Not a $2M rewrite. A strategic improvement that unlocks millions in velocity.

What Comes Next in This Series

Over the next few months, I’ll walk through exactly how to identify and execute these strategic architectural improvements:

Understanding the Inflection Point:

• Why architecture becomes your marketing engine (yes, really)
• How to build fast without building fragile
• The real cost of technical debt (it’s not what you think)

The Framework:

• Why most roadmaps are built backwards (and how to fix yours)
• The 6 pillars of architecture-led organizations
• How modularity creates business leverage, not just clean code

The Execution:

• Custom engineering vs plugin assembly (when each makes sense)
• The science behind faster delivery
• Building platforms that think (AI and agentic layers)

The Leadership Side:

• Why growth starts with technical leadership mindset
• Communication dynamics that accelerate (or kill) momentum
• Building engineers who think like architects

The Proof:

• Real case studies with full before/after metrics
• How we’ve helped companies break through their growth ceilings
• What strategic architectural improvements actually look like

But it starts here.

Recognizing that your growth constraint might not be market, product, or team.
It might be a foundation.

And unlike market or product constraints, the foundation is something you can fix with strategic investment.

The Bottom Line

If you’re at that $10M-$30M inflection point and growth suddenly feels harder—you’re not behind.

You’re at a decision point:

Option A: Keep building on the same foundation, pay increasing technical tax, watch competitors who rebuilt strategically pull ahead.

Option B: Make 3-4 strategic architectural investments over the next 12-18 months, unlock exponential leverage, and break through to the next stage.

The companies that scale don’t avoid this moment. They navigate it strategically.

The difference between stalling at $20M and scaling to $100M often comes down to 3-4 architectural decisions made at exactly this inflection point.

Where are you feeling the constraint most?

Is it product velocity? Business agility? Unit economics? Something else?

I’d love to hear what patterns you’re seeing in your own systems.

Want help identifying your highest-leverage architectural improvement?

We do this diagnostic work with growth-stage companies—usually a 2-3 week engagement that maps your current constraints to potential strategic investments with estimated ROI. Contact us to discuss your growth challenges.

Not a sales pitch. Just a clear-eyed look at where strategic refactoring would create the most business value.