Why Building Our Own Products Makes Us Better Consultants

When a client asks us to review a proposed architecture, scope a new build, or work out why a product's infrastructure keeps causing problems, we're not reaching for something we learned in a book or a certification course. We're reaching for the same decisions we've had to make, and sometimes get wrong first, while setting up our own products.

That's the part of our technical consulting that's easy to undersell in a services page: it isn't advisory work sitting apart from what we actually build. It's the direct output of having set up subscription software and digital media products ourselves, end to end, and having to live with every decision afterward instead of handing it off once the invoice is paid.

There's a version of 'setting up a product' that lives in a proposal document: pick a framework, choose a database, wire up payments, deploy somewhere, done. That version is fine for a slide. It leaves out almost everything that determines whether the product still works cleanly a year later.

The real list includes things like: how you structure subscription billing so a plan change or a failed payment doesn't leave a customer in a broken state; how you handle compliance requirements (VAT, POPIA, data retention) as part of the architecture instead of bolting them on after a client or regulator asks; how you design an API so it can hold up under real traffic instead of just a demo load; and how you set up monitoring so you find out about a problem before your users tell you about it.

We know that list isn't theoretical because we've had to work through every item on it for our own products, more than once, with our own money and our own uptime on the line. That's a different kind of knowledge than having read about how it should be done.

Our technical consulting engagements are narrow on purpose: software architecture reviews, technical due diligence before a client commits to a build or an acquisition, and scoping work for a specific, well-defined problem. Our services page lays out how we frame that split against subscription software and digital media, which are the other two things we run.

What makes those engagements useful isn't that we can name the right pattern in the abstract. It's that we've had to choose between competing architectural options for our own products, live with the consequences, and in a few cases go back and fix a decision that looked fine at launch and turned into a liability six months later. When we walk a client through why one approach to a payment flow or a data model will cause them pain later, we're usually describing something we've already paid the cost of finding out the hard way.

That's also why our consulting capacity stays deliberately limited rather than something we try to scale into a second full business line. Giving a client architecture advice that's grounded in real operational experience takes the kind of attention that doesn't scale past a small number of engagements at a time, and we'd rather take on fewer of them properly than dilute the thing that makes the advice worth paying for.

Sorted Nexus is the clearest example. Building a business admin platform for South African small businesses meant working through VAT handling and POPIA compliance as core architecture, not an afterthought, because we were building it for ourselves and couldn't afford to get it wrong. That's precisely the kind of gap we now catch fastest in a client's proposed system: compliance treated as a checkbox at the end instead of a constraint shaping the data model from day one.

Qrop taught us a related lesson from the API side. Moving from a simple web tool that generates one QR code at a time to an enterprise API that businesses can call at volume forced us to think properly about rate limits, idempotency, and what happens when a client's integration retries a request it thinks failed. Those are exactly the questions we now ask when reviewing a client's own API design, because we've had to answer them for a product where getting it wrong meant our own customers noticing.

The product we're building next, Offloader, is shaping up the same way. It's a stateless API for portfolio performance and risk metrics, built deliberately so it never holds onto a client's sensitive portfolio data. That design choice came directly out of understanding how advisor platforms and fintech products are actually built, and what they'd realistically integrate, which is the same understanding a fintech client hires us to bring into a review of their own system. We've written more about how this pattern shows up across everything we've built in How Our Experience Shapes What We Build, one of our other articles.

Most technical consultants can show you a list of past clients and projects. That's useful, but it's a different kind of evidence than being able to say: we run three live products ourselves, we've handled the support tickets when something broke, and we've made the call on whether to fix a piece of infrastructure or replace it, using our own operating budget as the constraint.

That distinction matters most in the moments a client actually needs a consultant for: not the parts of a build that go smoothly, but the parts where two reasonable-looking options have different long-term costs that aren't obvious from either option's spec sheet. Recognising that difference reliably takes having been on the wrong side of a similar decision before, not just having reviewed a lot of other people's architecture diagrams.

It also means the advice we give tends to be conservative in a specific, useful way. We're not proposing an architecture we've only read about and would like the chance to try on someone else's budget. We're recommending the pattern we'd choose if it were one of our own live products, our own on-call rotation, and our own uptime on the line, because in a very literal sense, it usually already has been.

Technical consulting makes the most sense when the scope is clear: a build that needs an architecture sanity check before it starts, a system that needs a due diligence pass before a decision gets made about it, or a specific technical problem that needs a second, experienced set of eyes. It makes less sense as an open-ended retainer, which is part of why we keep it scoped and limited rather than trying to be a general-purpose engineering team for hire.

If that sounds like what you need, describe the problem you're actually trying to solve rather than a pre-decided solution. We'd rather hear where the friction is and tell you honestly whether we're the right fit, the same way we'd want someone to tell us before we spent our own time and budget building the wrong thing. You can reach us through our contact page, or take a look at our services page for how we scope consulting work.