UFlow Suite

The situation

A CRM is a solved problem until the buyer is regulated.

A healthcare provider, a law firm, a field-services or construction business carrying other people's regulated data does not get to accept the standard arrangement, where every customer's records share one database and separation is a column the application promises to filter on. Some of them cannot let the data leave the country at all. That requirement is not negotiable by procurement, because it did not come from procurement.

So those buyers do one of two things. They accept a general-purpose CRM and carry a risk they have not really priced, or they pay for something bespoke and own the maintenance of it forever. Neither is a good trade.

The second constraint arrived with AI. Every CRM acquired assistive features, and almost all of them work by sending the customer's records to somebody else's model. For a regulated buyer that is not a feature — it is the reason to say no.

I am founder and principal architect. This is my own product, not client work.

What I did

I made isolation the architecture rather than a setting. Each tenant gets its own PostgreSQL database, provisioned automatically, and it can be placed in the country the buyer's obligations require. Separation is not a filter the application has to remember to apply; there is no shared table to leak across in the first place.

AI features run on local models. Qwen2.5 via Ollama, so the assistive work happens without regulated client data being sent to an external provider. That constraint costs capability against a frontier model, and it is the trade the buyer would make anyway if anyone asked them.

Security is built as the substrate: multi-key Fernet encryption on personal information, JWT and CSRF authentication, automated secret rotation, and tamper-evident audit logging. I wrote the GDPR and POPIA security framework the product is built to rather than assessing it against one afterwards.

13+ production-ready core modules, carried by 4,000+ unit tests. The test suite is the part I would point at: I cut its runtime by 85% through PostgreSQL parallelisation, which sounds like an engineering footnote and is not. A suite slow enough to skip is a suite that stops being run, and on a product whose whole claim is isolation, the tests are what keep the claim true while the schema keeps moving.

What changed

The product exists at 13+ modules with the isolation model, the local-inference path and the security framework all in place rather than planned — and with a test suite fast enough to actually gate the work.

No customer outcome is claimed here, because there is not one to claim yet. UFlow is a product I am building, and the evidence it offers a reader is architectural: what a system looks like when a hard external constraint — data residency, or regulated data that must not reach a third-party model — is taken as the starting point rather than handled as an exception.

That is the same problem shape I am hired for. The difference is that here I set the constraint, carried it, and can show what it cost.

What I'd do differently

I built Microsoft before trying to build Word.

UFlow started as the standalone, battle-tested version of what I had built at Holthuizen — my first do-it-entirely-myself project, with no prior self-build to learn from. So I learned on it, and what I learned is mostly about restraint.

Before a single customer existed I had built verticals for legal, property, healthcare and construction with translations for each, an isolated database per country per customer, ten-plus auto-translated languages, schema generated automatically in a Docker environment, rotating multi-key encryption, secret handling, and pricing in multiple currencies derived from a purchasing-power index.

All of it works. None of it was asked for. Every one of those decisions was defensible in isolation and the sum of them was a platform engineered for a compliance-sensitive buyer I had not yet met.

What I would do instead is obvious in hindsight and hard in practice: build one vertical, for one customer, in one country, and let the second one tell me what actually generalises. The architecture is not wasted — Pleks is faster because of what UFlow taught me. But I paid for that lesson in months I could have spent finding out whether anyone wanted it.