Fast forever: how to keep shipping at speed as your SaaS company grows

We’ve been building ChartMogul for more than a decade. I’m a product-focused generalist and a solo founder with a deep love for design and detail. Over the years, I’ve come to believe that a company’s rate of innovation is both a huge motivator for the team and a lasting competitive moat. It fuels momentum and keeps people engaged and excited.

In Silicon Valley, speed often comes from massive funding rounds and all-consuming work cultures. But what if you’re a solid, product-focused B2B SaaS company in Europe without that kind of hypergrowth pressure? You still need to move fast. You just have to find another way.

This is the story of how we built that rhythm, lost it, and got it back again. This content was originally presented at ARRtist Summit in Berlin.

Early momentum

Back in 2014 and 2015, things were simple. We raised a bit of money, shipped fast, and found customers who loved what we were building. With just a handful of engineers, progress was visible every week. Commits were flying, and every release felt like a win.

When speed slipped away

As the product grew, so did the complexity. Fixing one part of the app broke something else. Our 2016 experiment with microservices only made things worse.

The backend became tangled. Only the frontend team was moving at a steady pace. Frustration built up, engineers left, and productivity stalled. It’s hard to tell who’s doing great work when no one can make visible progress.

Around that time, I spoke with another founder who explained how his company used swimlanes to organize engineering. Each team owned its area end to end, able to ship independently without blocking others. It was a lightbulb moment.

That wasn’t how we were set up at all. Realizing it was a bit crushing because it meant we’d have to rebuild large parts of what we’d already built. But it also gave me clarity on what needed to change.

The good news was that customers still loved the product, and revenue kept growing. That gave us time to fix the foundation before it was too late.

Rebuilding the machine

In 2018, on a long flight to Seoul, I started sketching what a clean, fast, scalable ChartMogul architecture might look like. It meant creating clear boundaries between integrations, pipelines, analytics, and frontend layers — our own version of swimlanes.

From 2019 onward, we got to work. We rewrote almost everything:

• Rebuilt every integration
• Moved the frontend from Backbone to Vue
• Folded microservices back into the monolith
• Migrated from DigitalOcean to AWS
• Switched the query engine from PostgreSQL to ClickHouse

Here’s what that looked like:

It took years, and it wasn’t easy. But the payoff was worth it. Today our codebase is cleaner, our engineers are happier, and we’re shipping faster than ever.

Lessons in building fast

1. Architecture Comes First

Good architecture matters more than team size. Hiring alone won’t fix a messy codebase. And less really is more. If your foundation is clean, everything else moves faster.

2. Run It Like a Sports Team

Burnout doesn’t come from hard work. It comes from working without progress. Engineers want to build and ship. That’s what keeps them energized.

A few principles I’ve learned along the way:

• Attitude beats experience
• Competence is everything
• Managing out weak performers isn’t optional

Steve Jobs once said the best managers are “experts leading experts.” I agree. At ChartMogul, everyone in engineering writes code, from the VP down.

3. Stay Close to the Work

Early on, I thought my job was to stay out of the way of the experts. That was a mistake.

If you’re building a software company, you have to be inside the software. Learn how everything works. Spend time with the engineers, even when it’s tiring. People come and go, but you’re the constant. The founder’s energy and product perspective belong inside the technical conversation.

4. Keep Process Light

Process helps, but too much of it slows you down. Don’t over-optimize how you work at the expense of actually building.

One simple habit that helps us: design features a few months before we implement them. It gives space for feedback, iteration, and better decisions.

Our design-to-build flow looks like this:

Identify a need or opportunity

Product creates a design and collects feedback

Engineering reviews and plans implementation

Build, test, and ship

Sometimes there’s a pause between stages, and that’s fine. The key is steady flow, not constant motion.

Fast forever

After all this, three lessons stand out:

Architecture beats headcount. Plan it carefully.

Experts should lead experts. Avoid “professional managers.”

Momentum creates motivation. Protect it at all costs.

We made every mistake in the book but kept going. Ten years later, we’re building faster than ever.