I work with Matthias every day, but the clearest way to introduce him is not with a list of technologies or job titles. It is with the question he keeps bringing back into the room: can another person follow how we reached this answer? That question shapes how he approaches engineering, data and product decisions at Upswitch. A business owner does not need a number that merely looks precise. An owner needs to understand what the number rests on, which evidence is missing, which assumptions matter and what action could make the business stronger. Matthias is responsible for turning that standard into working software and a technical methodology that can carry it consistently.
His formal role is co-founder and engineering and data lead. The title is deliberately broad because the work crosses several boundaries: the information a company provides, the way that information is normalised, the calculations built on top of it, the confidence attached to an outcome and the explanation presented to the person making a decision. Those parts cannot be treated as unrelated features. If the input is weak, a polished report does not repair it. If a calculation is sound but impossible to explain, it does not earn trust. If an interface hides uncertainty, the product is making a promise the evidence cannot support.
A background built across software, product and data
Before Upswitch, Matthias spent roughly a decade building and improving software across Belgium, Sweden and a wider EMEA context. His public professional history reflects a mix of technical, analytical, product and growth responsibilities rather than one narrow discipline. That combination matters here. Upswitch is not only a calculation service and not only an interface. It has to receive imperfect company information, organise it, make method choices explicit and translate the result into language an owner, accountant or adviser can challenge. Experience at the intersection of software and how people actually use it is therefore more relevant than an isolated technical label.
The geographical part of that path also matters in a modest, practical way. Building for more than one market makes local assumptions visible. Accounting language, business classifications and expectations about what a useful report contains are not identical across Belgium, the Netherlands or the rest of Europe. Matthias does not treat those differences as decoration added after the core product is finished. He treats them as input to the design. A European system has to know where a shared method is possible and where country context must remain explicit. That discipline keeps the product from pretending that one market vocabulary can simply be copied everywhere.
Why Upswitch became the work
The route to Upswitch began with a problem that is easy to describe and hard to solve. Owners often reach consequential moments without a shared, current picture of their business. The question may arrive through a bank conversation, a succession discussion, an unexpected offer or the feeling that too much still depends on one person. The available answers are often fragmented between bookkeeping, spreadsheets, adviser knowledge and the owner’s own intuition. Matthias recognised that software could reduce the cost of assembling those pieces, but only if the system respected the limits of the evidence instead of replacing one black box with another.
That is where our two routes met. My work is closer to owners, advisers, transaction questions and the practical language of the market. Matthias works from engineering, data and product structure. Neither perspective is sufficient alone. A technically elegant workflow can fail if it does not answer the question an owner is actually asking. A persuasive market story can fail if the system underneath it cannot reproduce its conclusions. Upswitch became a shared project because the problem requires both disciplines at once: market judgment that can identify the real decision and engineering that can make the evidence more legible and repeatable.
Our earlier essay, we priced our own round the old way, explains why this is not an abstract criticism of how other people make decisions. Founders also rely on convention, trusted advisers and a number that feels plausible when a transparent method is unavailable. That experience sharpened the standard Matthias applies to the product: do not claim that software removes judgment, but make the inputs and reasoning visible enough that judgment can be exercised better.
What Matthias is responsible for today
Matthias leads the engineering and data work that supports the owner and adviser experience. At a high level, that includes the paths through which company information enters the product, the rules used to make unlike inputs comparable, the services that calculate and store results, and the layer that turns those results into explanations. It also includes the less visible work that determines whether a product is dependable: access boundaries, validation, monitoring, failure handling and the tests that prevent a confident interface from outrunning the data behind it. These responsibilities are described here at the level the public product can support; the details remain part of the team’s operating work rather than a marketing claim.
He also owns the technical side of the methodology. That does not mean replacing financial or transaction expertise with code. It means expressing a method clearly enough that the system can apply it consistently, record which path was used and show where human review remains necessary. Methodology becomes more useful when it can be inspected. If a normalisation changes an earnings figure, the user should be able to see the category and rationale. If a range is wide because the evidence is thin, the product should say so. If two approaches disagree, disagreement should be presented as information rather than averaged away without explanation.
Data leadership inside Upswitch is similarly practical. More data is not automatically better data. A registry field, an accounting balance, an owner answer and a market observation have different provenance and different limits. Matthias’ responsibility is to keep those distinctions intact as information moves through the product. The goal is not to make every signal look equally authoritative. The goal is to preserve enough context that an owner or adviser can tell what is known, what was inferred, what was supplied by the company and what still needs evidence.
The operating principles behind the work
- Provenance before polish. A useful answer identifies where its important inputs came from before it optimises how the answer looks.
- Uncertainty should remain visible. A range, caveat or missing-data request is more honest than false precision and more useful than a generic disclaimer.
- The owner needs a next step. Analysis should identify a weakness that can be investigated or repaired, not leave the user with a score and no route forward.
- Automation should support judgment. Repetitive collection and calculation can be accelerated while consequential choices remain reviewable by people.
- Local context belongs in the model. European SME data cannot be made trustworthy by erasing country, sector or reporting differences.
These principles make Matthias demanding in a productive way. He is wary of features that create an impressive demonstration but weaken the audit trail. He prefers a smaller claim the product can defend over a broader claim that depends on ideal data. He also insists that a technical limitation should not be hidden behind vague copy. If a workflow needs another document, another answer or an adviser’s review, the product should state that plainly. Trust grows when the system behaves consistently at its boundaries, especially when the answer is incomplete.
How our founder roles complement each other
Our roles are complementary without being sealed off from one another. I bring conversations from owners, accountants and advisers into product decisions. Matthias asks what evidence supports the request, whether the resulting behaviour can be expressed consistently and how failure would appear to the user. He brings technical constraints and data questions back into market conversations. I ask whether the explanation matches the way a person describes the problem. This loop is more valuable than agreement for its own sake. It forces product language and system behaviour to meet before either reaches a customer.
The division is therefore not “technology” on one side and “business” on the other. Matthias is accountable for engineering, data and technical methodology; I am accountable for the M&A practice, market relationships and how the product fits the work around an owner. We make the most consequential product choices together. The useful tension is between what can be built, what can be defended and what will help someone act. When all three are present, a feature belongs. When one is missing, the answer is usually more discovery rather than more certainty.
Readers who want the other side of that partnership can read Matthias’ introduction of me. The cross-byline is intentional. A founder biography written only in the first person tends to become a résumé or a manifesto. Writing about one another makes the operating relationship visible: what the other person is trusted to own, how decisions move between us and where our perspectives improve the result.
What Matthias is building for owners
The immediate product goal is straightforward to state: help an owner see the condition of the business clearly enough to decide what deserves attention. Value is part of that picture, but it is not the only part. A company can have a credible range today and still carry weaknesses that make the outcome fragile: customer concentration, owner dependence, inconsistent reporting or decisions that only one person can make. Matthias is building the technical foundation that connects evidence about those weaknesses to an explanation and, where possible, a concrete repair path.
That is why the broader Upswitch language has moved toward knowing and strengthening rather than treating valuation as a one-off reveal. The essay growth versus strength describes the distinction. Growth can make a company larger while leaving its dependencies untouched. Strength is the less visible work that makes performance more durable and the company easier to understand without its owner in the room. Engineering contributes by making changes measurable over time and by keeping the basis of each conclusion available for review.
The longer-term ambition is not a machine that announces an unquestionable price. It is infrastructure that makes important SME decisions less dependent on disconnected files and private interpretations. That requires patience: better coverage, clearer provenance, reliable country context, careful access rules and feedback from people doing the work. Matthias is most at home in that kind of long project. He is interested in the system becoming more useful and more defensible with each iteration, not in presenting an unfinished capability as if the hard work were already complete.
How to follow or contact Matthias
The canonical overview of Matthias’ role and published expertise is on his Upswitch team profile. His public professional history is available on LinkedIn. The team page is the source we maintain for his current Upswitch responsibilities; LinkedIn provides the broader professional context. For engineering, data, methodology or product-integrity questions, those pages provide the clearest route into his work. For owner, adviser or partnership conversations, either founder can make sure the question reaches the right place.
Frequently asked questions
What is Matthias Mandiau’s role at Upswitch?
Matthias is co-founder and leads engineering, data and the technical methodology. He is responsible for the systems that organise company evidence, support calculations, preserve provenance and turn results into explanations that owners and advisers can inspect.
Did Matthias come to Upswitch from M&A?
His primary background is in software, product and data work across Belgium, Sweden and a wider EMEA context. Upswitch combines that technical perspective with Lieven Plaetsier’s M&A, owner and market responsibilities.
What does technical methodology mean here?
It means expressing methods clearly enough that they can be applied consistently, recording which evidence and assumptions were used, showing uncertainty and preserving the points where human review or additional information is required.
Where can I find the canonical Matthias Mandiau profile?
Use the Upswitch team page at /en/about/team/matthias-mandiau, with the locale changed as needed. It is the maintained source for his current Upswitch role and links to his public LinkedIn profile.
Upswitch is the M&A infrastructure layer for the European SME economy. Defensible valuations and structured transaction matching for the lower mid-market.