Some software only needs to work. Some software needs to earn trust.
Share Council came to us with the second kind of problem. Their goal is to close the capital wealth gap by turning employees into co-owners of the companies they help build, aiming to give a stake to some of the 137 million employees across European businesses who currently have none. That ambition depends entirely on whether people trust the platform underneath it. If an employee cannot verify their equity is real, correctly recorded, and protected, the model does not hold.
Before writing any code, we had to answer a harder question than usual: what does a platform need to do, structurally, to earn that kind of trust at scale.
Managing company ownership involves multiple investors, vesting schedules, convertible notes, and layers of approval, all governed by Dutch and EU corporate law. None of that is optional. For Share Council, this meant the legal and regulatory constraints functioned as the real product brief, not a checklist to satisfy after the fact.
Our first task was architectural: design multi-tenant infrastructure that could hold this complexity for many companies at once, without one tenant's data or governance rules affecting another's. Every later decision, from database structure to API design, had to be checked against Dutch and EU regulation, for every tenant, every time.
Corporate actions like issuing shares, approving a vesting schedule, or authorising a payout need defensible, auditable approval, often from multiple parties, often at different thresholds depending on what is being approved.
We built dynamic, multi-signature approval workflows directly into the system architecture. The thresholds are not fixed assumptions about how every company operates; they flex based on what is being authorised and who needs to sign off. A static approval flow can work fine in a demo, but it tends to break the first time a real company's governance structure does not match the assumptions baked into the code.
Ownership records need to be immutable, and an audit trail that could theoretically be edited after the fact is not really an audit trail. That is the specific problem blockchain solved here.
We built a custom Node.js integration with Stellar to record ownership transactions and issue digital certificates on an immutable ledger. Every transaction can be verified independently of Share Council's own systems, which is the point: trust that depends entirely on one party's internal records is a weaker kind of trust than trust that can be checked.
The blockchain layer does one job. It makes the ledger tamper-proof. The workflows, the financial automation, and the user experience were built around that guarantee, rather than built to put blockchain on display.
Equity management carries a lot of recurring financial work: reconciling payments, tracking vesting as it accrues, processing dividends, handling cross-border transactions. Done manually, this kind of work scales badly, and every new client, investor, or payment method adds friction that compounds.
We integrated SEPA reconciliation alongside Stripe and Mollie for payments, so financial operations run automatically and stay traceable end to end. In a system where the core value is trustworthy ownership data, a reconciliation error is not a minor bug. It undermines the premise of the platform, so removing manual handling here was a priority from early on rather than a later optimisation.
Role-based permissions, two-factor authentication, and detailed audit trails were built in from the start, not added once the platform was functionally complete. A platform that governs equity ownership has to assume it will be tested and audited, by regulators, by investors, and by the employees relying on it.
The result is a platform that does not just store records of who owns what. It governs ownership: enforcing approval rules, maintaining an immutable audit trail, and keeping financial operations synchronised across legal, financial, and blockchain layers, without manual intervention.
For Share Council, this means they can focus on their mission, giving employees a real stake in the businesses they help build, without having to worry about whether the infrastructure underneath can hold up to a regulator, an investor, or an employee asking hard questions about their own equity.
For this build, that meant treating the non-negotiable constraints as the starting point, designing the architecture to satisfy them first, and layering automation and experience on top once that foundation was solid.
If you are building something where trust is the product, not just a feature of it, let's talk about how this applies to your platform. Read the full Share Council case study here.
.jpeg)
For a platform that governs equity ownership, the legal and regulatory constraints aren't a checklist to satisfy after launch, they're the actual product brief. We've found that when compliance gets treated as an afterthought, it tends to surface as a costly rebuild later. Starting with Dutch and EU corporate law meant every architectural decision, from multi-tenant structure to API design, was already built to hold up to scrutiny.
We don't add blockchain to make a product look innovative. On Share Council, it solves one specific problem: making the ownership ledger tamper-proof. The custom Node.js integration with Stellar exists to support that single guarantee, while the workflows, financial automation, and user experience are built around it rather than designed to put the technology on display.
We treat the non-negotiable constraints (regulatory, security, audit) as the starting point rather than a layer added once something works. That's why role-based permissions, two-factor authentication, and audit trails go in from day one. It's a pattern that applies beyond fintech: anywhere a client's product depends on people trusting the system underneath it.
