What We Learned Running Our Own SaaS Products for Six Years

Beacon runs three SaaS products of its own — a lead manager, a CRM built for construction firms, and an ecommerce platform. We did not set out to become a product company; we built these because we needed them ourselves, and once they existed, other businesses with the same problem wanted to use them too. Six years of running them in production, alongside our client work, has taught us things a client project never fully teaches, because we could never walk away from the consequences of our own decisions.

What did a bad onboarding flow actually cost us?

Not an obvious, immediate failure — the real cost showed up as a slow trickle of customers who signed up, poked around for a few days, and quietly stopped logging in without ever contacting support to complain. It took us longer than it should have to connect this pattern to a specific onboarding flow that asked new users to configure several settings correctly before they could see any real value in the product, rather than getting them to a meaningful first result quickly and letting configuration happen later. On a client project, an agency delivers the built onboarding flow and moves on to the next engagement; we had to watch this pattern play out in our own retention numbers for months before we understood what was actually happening, which is a harder and more honest way to learn the lesson, and it now shapes how urgently we push clients to get onboarding right in SaaS development engagements from day one rather than treating it as a polish item for later.

How did pricing tier boundaries confuse real customers?

We set tier boundaries based on what looked like sensible usage bands on a spreadsheet — a reasonable-looking jump from one price point to the next based on feature access. What we did not anticipate was how many customers sat right at a boundary and felt genuinely confused, sometimes frustrated, about why a seemingly small usage increase pushed them into a meaningfully more expensive tier. Support tickets taught us this faster than any planning exercise would have, and we adjusted tier structure based on real customer behaviour rather than our original assumptions about how customers would think about the pricing. This is now a specific thing we push back on when a client's SaaS pricing plan looks clean on paper but has not been tested against how real usage actually clusters.

What does technical debt actually feel like when you can't hand the bill to anyone else?

Different from a client project, where technical debt is eventually someone else's decision to accept or pay down. In our own products, a shortcut taken under a deadline does not go away when the project ends — it sits in the codebase, quietly making the next feature harder to build, until eventually we are the ones paying the cost in slower development or an unplanned refactor. This experience is the direct source of advice we now give clients plainly: a shortcut that saves time this sprint often costs more than it saved within a year, and we are more willing to push back on a shortcut in our own products than we might otherwise be tempted to on someone else's deadline, precisely because we know we cannot walk away from the consequences.

Which multi-tenancy decision from month one turned out to be the most expensive to reverse?

Our earliest multi-tenancy approach kept less separation between customer data than later versions of the same product, which was faster to build initially but became a genuine constraint as we needed finer-grained data isolation for enterprise customers with stricter requirements. Retrofitting stronger isolation into an already-running multi-tenant system with real customer data in it is a significantly harder and more delicate job than building it correctly from the start, precisely because you cannot pause the product to do it. This is now one of the most heavily scrutinised decisions in any SaaS development engagement we scope for a client — we push hard on getting tenancy architecture right in the first sprint specifically because we know from direct experience how expensive it is to fix later.

How has this experience actually changed how you scope client SaaS projects?

It shows up as specific, sometimes unwelcome, early pushback — questioning whether a client's proposed launch feature list is really the right first version, flagging a pricing structure that looks clean but has not been tested against real usage patterns, and insisting on stronger tenancy isolation earlier than a client might otherwise think necessary. None of this comes from a textbook; it comes from having made the alternative mistake ourselves and watched what it cost. It also means we are honest when a client's plan echoes a mistake we have already made — we would rather have that occasionally uncomfortable conversation early than watch a client repeat something we already know does not work.

Would you recommend other agencies build and run their own products?

Cautiously yes, with the caveat that it is a genuine commitment, not a side project you can abandon without cost — a product with real customers depends on you in a way a completed client engagement does not. But the specific kind of judgment it builds, about onboarding, pricing, technical debt and architecture decisions, is difficult to develop any other way, and it has made a measurable difference in the quality of advice we can offer clients building their own products.

What's next for Beacon's own products?

We continue investing in all three — the lead manager, the construction CRM, and the ecommerce platform — as live products with their own roadmaps, not legacy systems we are winding down. Each one continues to surface lessons that feed back into how we scope and build client work, which is the whole reason this arrangement has been worth the ongoing commitment it requires.