Technical judgement, before you commit to it.
Advisory, coaching and hands-on product work for founders and engineering leaders making decisions that are expensive to reverse.
Most costly technical decisions are not made badly. They are made early, with incomplete information, by people who will not find out for eighteen months whether they were right.
What this is for
The decisions that are cheap to make and expensive to unmake:
What to build first, and what can wait longer than it feels like it can
Build, buy or borrow — and the honest cost of each, including the one nobody prices
Architecture decisions that are expensive to reverse, identified while they are still cheap to change
Hiring — what to look for, when to hire, and what a senior engineer is actually for
Which technical risks matter, and which are absorbing attention out of proportion to their consequence
None of that requires you to have a product yet. Much of it is most valuable before you do.
When you are raising
Investors fund a technical claim as much as a market one, and the technical claim is usually the part a founding team has the least practice defending.
We help you write it down and stand behind it: the white paper, the technical half of the pitch deck, the answer to the question a technical diligence call will ask. Not ghostwriting a story you cannot support — putting the real one in a form that survives scrutiny, and telling you plainly where it does not yet hold.
Product research and R&D
Some questions are not advice questions. They are we do not know whether this is possible, and we cannot afford to find out slowly questions.
We take those on directly — researching the option space, building the thing that settles the argument, and reporting what we found rather than what we hoped. This is the same engineering practice that runs the rest of MLabs, pointed at a question instead of a product, and it is why the advice on this page is not only advice.
Training your team, not replacing it
The cheapest version of this service is the one where you stop needing it.
Where the gap is knowledge rather than capacity, we teach: working sessions with your engineers on the methods we use, on the parts of your own system nobody has had time to understand properly, and on the discipline that keeps a fast-moving codebase honest. Teams retain what they were walked through far better than what was handed to them finished.
Two ways to work with us
A regular cadence. Recurring sessions, so the advice arrives while the decision is still open rather than after it. This suits teams making a lot of consequential calls in a short period — which is most teams before a launch or a raise.
A defined piece of work. A document review pass, an architecture opinion, a research question answered, a stretch of R&D. Bounded, scoped and priced up front.
You do not have to decide which of those you want before you speak to us. Most people arrive describing one and turn out to need the other, and working that out is part of the first conversation rather than something you have to get right in advance.
Who you’re talking to
MLabs builds and verifies software for fintech and on-chain finance — systems where being wrong is expensive. The advisory work is led by Ben Hart, who came to MLabs by way of AdvancePro Technologies and Finnovate.io, and it draws on the same people who do the delivery.
That matters, because the useful patterns are not theoretical. We ported Juspay, India’s largest payment gateway, from PureScript to Haskell. We built the first generation of Cardano’s DeFi. We maintain open-source tooling other engineers in this field depend on, in public, at github.com/mlabs-haskell.
We have also sat on the other side of the table: named partners in fundraises for Liqwid and Clear Contracts, direct stakes in projects we believed in, introductions that mattered, and the job of explaining the technical side of a product to the investors and regulators who had to believe it.
The opinions behind the advice are specific. Software that handles money should make strong guarantees about safety and privacy. Those guarantees are compatible with tooling that ships faster and more cheaply than it used to — using it well is the point. And most architecture decisions are really decisions about what you will still be able to change in three years.
None of that has to be taken on trust. The code is public, the clients are on our own front page, and the write-ups, talks and grant results are all findable.
How this starts
A conversation first. Tell us what you are deciding and what it would cost you to get it wrong. That call is free, and if it turns out we are not the right help we will say so.
A mutual NDA before we read anything that isn't already public. We do not ask for access to your code or your commercial material to decide whether we can help you.
Then a cadence or a scope, whichever fits what you actually need. We would rather tell you that two conversations will do it than sell you a retainer you do not need.
If you are about to make a decision you cannot easily undo, this is the moment it is worth most — and usually the moment nobody has time for it. Tell us what you are weighing up, and we will tell you honestly whether we can help.
