Trustform

When I joined Trustform the project was only beginning. There was an in-house compliance tool, working code, and deep domain knowledge. The plan was to take it first to the whole group of companies, then to the external market.

The work itself was clear enough. Before a bank or a fund can take on a client, someone has to prove the client is who they claim to be, see who really owns the company behind them, and keep watching once the relationship starts. That someone is a compliance officer, and the tool was built to do that job.

What was missing was the product around that job. Inside one company a tool can lean on people who already know how it works. Nothing yet said which firms outside would buy it, what they would pay for, or what they would compare it against.

Together we shaped it: rewrote the problem statement from the customers' perspective, mapped the compliance workflows financial companies actually run, and cut everything that only made sense in-house.

After that we ran a gap audit: what the product was missing to scale beyond a single company. We talked to the people already using the tool and to the ones we wanted as customers, laid out a proper SaaS model with multi-tenancy, so one installation could serve many companies without any of them seeing the others, and worked out what had to be configurable rather than fixed. That became the first roadmap.

I designed the system architecture around one idea: a single source of truth for the client, from first contact to ongoing monitoring. Every module reads and writes the same client graph: the companies, the people behind them, who owns what, the documents, the checks, and the decisions.

That shape is what let us ship modules independently. Corporate Onboarding, Customer Due Diligence, Client Risk Assessment and the rest were built on top of that graph, not beside it, so none of them had to keep its own version of the client.

I stayed hands-on through the whole loop, not just the drawing board. For the core modules that meant the process models, the API design, and the code itself, written alongside the team rather than handed to it.

I also set the engineering standards: how services are structured, how they talk to each other, how we review, and what counts as ready to ship. As the team grew to fifteen, those standards are what kept one codebase from quietly turning into several.

Then we reworked how analysis and delivery ran. The team started shipping 1.5× faster, and quality held.

Working both ends taught the architecture things a diagram never would: real document flows broke the tidy first version of the review process, so we reworked the model around the way compliance officers actually batch their work.

We shipped v1 against that first roadmap. From there the roadmap stopped being ours to guess at. I moved closer to the go-to-market side, working on the strategy with sales and marketing and on the analysis of what clients actually needed: which parts of the product they valued most, and which ones needed fixing straight away.

As the client base grew, so did the requests, and the architecture paid for itself. It let us cut down support work quickly, both on custom tickets and on the questions everyone was asking. Reporting is the clearest example. We built an AI-powered reporting hub where a question written in plain language, an NLQNatural language query. You ask in plain words and the system works out the query to run. query, produces the report a regulator is asking for. Before that, an engineer wrote each one by hand.

Over three years the product went from one company's internal tool to a platform with dozens of clients, from Malta to the Cook Islands.

The module set we planned in that first roadmap is what shipped, and the team we hired is still building on it.