What Honan taught us (and why we rebuilt xMS after)

Shipping a production portal to 500+ strata clients changed how we thought about the platform. Here's what we learned - and what we did about it.

In 2023, we went live with Honan Insurance's strata client portal. Built on xMS, fed from Honan's internal CRM, serving 500+ strata managers across Australia. 33,000 properties under management.

It worked. It still works. It's in production today.

It also changed how we thought about the platform.

This post is about what we learned from that rollout, what we decided to do about it, and why the two years after Honan went live weren't spent chasing the next customer - they were spent rebuilding xMS from the ground up.

What we got right

The Honan portal was a real test of the thesis: can a small team ship a production-grade enterprise application on a configurable platform, faster than a traditional custom build, without the quality trade-offs?

The answer was yes. The platform carried us through:

  • A sophisticated permission model - brokers and strata managers with different views, properties scoped to portfolios, sensitive financial fields hidden or shown per-role.
  • Live integration with Honan's existing CRM, keeping client data current across both systems.
  • Self-service at scale - strata managers who used to call the broker now just looked up certificates of currency and policies themselves.
  • Time-to-production that would have been a year-long build in the traditional model.

The business case validated. Honan was happy. Clients were using it. Data was flowing.

What we learned to be uncomfortable with

Production has a way of surfacing the parts of a system you convinced yourself were "good enough for now". Three specific things stuck with us.

Too much lived in the app, not the platform

The 2023 xMS was less opinionated than it needed to be. Business logic - permission edge cases, workflow rules, custom transitions - often lived in application code on top of the platform rather than being expressible in the platform.

That worked. But it meant every new customer would start with "we need to write some custom code for this specific thing". Which meant every customer needed custom maintenance. Which didn't scale.

Honan's portal works. But the right fraction of the configuration is Honan-specific app code, not platform configuration, and that line is where platforms succeed or fail.

Versioning wasn't a first-class feature

When a workflow needed to change - a new approval step, a renamed field, a shifted permission - we didn't have a clean way to let Honan preview the change before it went live to all 500 clients. What we had instead was careful scheduling, maintenance windows, and our own nerves.

For a single customer that's manageable. For the tenth customer, each with their own cadence and change appetite, it's a coordination problem that becomes a blocker.

AI wasn't native

In 2023 the platform was pre-AI in its bones. We could add AI features to specific pages, but the Designer itself - where you build the app - didn't have an assistant that could create resources, configure permissions, or design pages for you.

By mid-2024, as AI-assisted development was becoming the default way a whole cohort of people built software, "pre-AI in its bones" was not a viable long-term posture. We either rebuilt to put AI at the centre, or we'd be refactoring around it for years.

The decision

We could have kept going. Honan was a happy customer. The product worked. We had an obvious next move: sign another customer, bank the revenue, iterate on the platform at the edges while serving both.

We didn't do that. Not because we thought it was wrong - because we thought the platform had a version of itself that would carry us much further, and every customer we signed on the 2023 version would be a customer we'd later be migrating or apologising to.

So in 2024 we stepped back. We kept Honan running. We stopped actively selling new seats. And we spent two years on the three lessons above:

  • Move more of the "custom" into platform configuration rather than app code.
  • Make parallel versions a first-class feature - v1 in production, v2 in preview, switchable per-user with one click.
  • Rebuild around AI from the ground up - a native assistant in the Designer, AI function templates for runtime apps, and the structural decisions an AI-native platform needs but a bolt-on can never retrofit.

Was it worth it?

Talk to us in three years and we'll know for sure. But here's what we believe:

Honan's portal is in production today. It will be in production tomorrow. The 2023 platform is fine. The 2026 platform is right - right in a way that would have required re-architecting the business later if we'd kept shipping the 2023 version to new customers.

There's a class of companies that ship v1 and then fight the gravity of v1 forever. There's another class that recognise v1 as a prototype, use production to learn, and invest in v2 before the tech debt compounds. We wanted xMS to be the second kind. Honan is why we could be confident enough to pause and rebuild. Rebuilding is why we can now say, with a straight face, that what we're selling is the thing we actually wanted to sell.

If you're a team shipping your first enterprise application: ship it. Put it in production. Serve real users. Learn what you couldn't have predicted from a whiteboard. But don't fall in love with v1 so hard that you can't let yourself build v2. The 80% of enterprise software we've been writing about in this blog - permissions, audit, multi-tenancy, versioning - is the substrate that either gets easier or harder with every customer you add. It compounds. Get it right early; get it right properly.

We learned that the hard way. So now you don't have to.

See xMS in action

Book a personalised demo tailored to your organisation.