Interview with our CTO, Eric Moura

DC : Can you introduce yourself in a few words?

Eric Moura : I'm Eric, CTO at DealCockpit. I trained as an engineer and am now an architect: a role I moved into naturally after years as a developer and then in DevOps. With my multiple certifications, I oversee the entire platform, from the cloud architecture right down to the last line of code. I make sure I stay very up to date: technology evolves quickly, and I don’t hesitate to adopt new developments as soon as they seem relevant to me. Outside of work, I’m a keen gamer – video games, board games, 3D printing… I love challenges and competition, and generally speaking, building things, whether software or physical objects.

DC : You trained as an engineer. Do you remember the moment you realised you wanted to build systems, rather than just use them?

Eric M. : To be honest, it’s always been there. As a child, I didn’t just play video games; I wanted to understand how they worked, tweak them, and create my own. I’ve always been fascinated by the idea of taking an abstract concept and turning it into a tangible project. I still have that same instinct today: when I use a tool, I immediately think about how I would have designed it, what I would have done differently. Moving into engineering was simply a matter of applying a professional framework to something that came naturally to me. And today, with DealCockpit, that’s the culmination of it all: I’m not just a user of technology, I’m building a product from start to finish.

DC : Your history with DealCockpit goes back a long way – first as an external contractor, then as a freelancer, and now as CTO. What sparked your passion for this tool?

Eric M. : What drew me in right from the start was the field itself. M&A is an environment where every detail counts: confidentiality, reliability, and rigour. As an external service provider, I first got to know the platform from the outside, and I could already see its potential. Then, as a freelancer, I was able to really get my hands on it, understand its foundations, its strengths and its areas for improvement. And that’s when the passion took hold: it’s a technically demanding product, in a sector where there’s no room for error. For someone who loves a challenge, it’s the ideal playground. The move to the role of CTO was the logical next step; I wanted to drive this vision over the long term, not just contribute on an ad hoc basis.

DC : What does it change to know a platform from the outside before working with it from the inside? Is it an advantage, a bias, or both?

Eric M. : Definitely both. The advantage is that I gained a user’s and integrator’s perspective before taking on the role of an architect. I know what’s frustrating, what’s missing, and what wastes time, because I’ve experienced it first-hand. When I make a technical decision today, I have that real-world perspective that you don’t necessarily have when you’re building a product from scratch in a bubble. The challenge is knowing how to step back from it. When you know a system inside out, you can tend to develop it incrementally rather than questioning it. I’m aware of this, and that’s why I’m constantly on the lookout: I challenge my own choices just as much as the existing code. Ultimately, I think it’s mainly an advantage. Knowing a platform’s history, its scars and its compromises allows you to make informed decisions rather than reinventing the wheel.

DC : In practical terms, what does it mean to be the CTO of a data room? What aspects of your day-to-day work are different from those of a typical SaaS CTO role?

Eric M. : The fundamental difference lies in the level of security requirements. With a traditional SaaS solution, a security breach is simply a nuisance. With an M&A data room, a breach can scupper a deal worth millions, expose strategic information, and destroy a client’s trust. It completely changes the way we think about architecture; every technical decision is weighed up through this lens. In practical terms, my day-to-day involves a mix of architecture, development, DevOps, security monitoring and dialogue with the sales teams to translate highly specific business needs into robust features. I’m not a CTO who just does PowerPoint presentations; I’m in the code every day, deploying, monitoring and patching. That’s what I enjoy, in fact: the chain is short between a decision and its impact in production.

DC : The platform relies on 100% proprietary technology. It’s a bold choice, almost going against the grain. Who made that decision, and why do you believe in it?

Eric M. : This is a decision that was made right from the start of DealCockpit, and one that I fully support today. Why do I believe in it? Because in our field, having complete control over the stack isn’t a luxury, it’s a necessity. When you’re handling data as sensitive as due diligence documents, you don’t want to rely on a third-party component where you have no control over the code, the updates, or potential vulnerabilities. Ownership means we know exactly what’s running, why, and how. Every line of code is ours, every architectural choice is our own. It takes more effort, that’s for sure – no shortcuts, no magic plugins. But in return, we have a level of agility and responsiveness that platforms built on a patchwork of open-source components will never have. If a client has a specific need tomorrow or a threat emerges, I can step in directly, without waiting for a third-party vendor’s approval.

DC : M&A professionals entrust us with some of the most sensitive data there is. How do you handle this responsibility in technical terms – not just in theory, but in the actual architectural choices you make?

Eric M. : That’s the question I ask myself every day, and that’s a good thing. In practical terms, it translates into very specific choices. Hosting with an infrastructure that I manage from end to end; my numerous certifications aren’t just for show on a CV, but because when you bear that level of responsibility, you need to understand every layer of your infrastructure. Encryption is in place at every level: at rest and in transit, with strict key management. Access is controlled by granular permissions; each user sees only what they need to see, not a single document more. And beyond the architecture, it’s a daily discipline: security updates are never delayed, audits are regular, and every new feature goes through the filter ‘could this create a breach?’. This isn’t marketing, it’s engineering. Our clients’ trust is earned through the code, not through slides.

DC : Against the backdrop of the major US VDR players, what is the technical or architectural argument you put forward first?

Eric M. : Expertise. The major American players are often behemoths that have grown through acquisitions. The result is cumbersome platforms that aren’t always consistent, and the end user feels the difference. We’re the opposite: a proprietary stack, designed as a whole, by someone who knows every line of code. And that translates into an unbeatable time-to-market. From the moment a requirement arises to its deployment in production, it sometimes takes less than a day. No major player can match that. Beyond speed, there’s proximity: our data is hosted in Europe (in Paris and Dublin), and we implement all the necessary encryption mechanisms to guarantee end-to-end confidentiality. For M&A deals, this is an argument that’s not just technical, but strategic.

DC : How do you keep up to date with threats and regulatory changes? What’s your approach to staying informed, your personal discipline?

Eric M. : Keeping up to date isn’t just a slot in my diary; it’s a constant reflex. I’m very active in tech communities, I read a lot, and I test a lot. When a new technology or framework comes out, I don’t just read the blog post; I get my hands dirty to understand what it really changes. On the security front, I keep track of infrastructure bulletins, CVEs, and advisories for the dependencies we use. Security updates are never delayed; that’s a non-negotiable rule. For regulatory matters, I rely on publications from the CNIL and ANSSI, and on developments in the European framework: GDPR, DORA, NIS2. It’s less exciting than coding, but when you’re managing an M&A data room, you can’t afford to fall behind on these issues. And then there are the certifications I maintain, which force me to stay up to date with cloud best practices; it’s a discipline in itself.

DC : How does customer feedback help shape the platform? Could you give an example of a request from the field that led to a real technical change?

Eric M. : Customer feedback is the driving force behind our roadmap. We’re not sitting in an ivory tower dreaming up features; we listen to what’s happening on the ground. A concrete example: redaction. During due diligence, clients regularly need to share documents whilst masking certain sensitive information (names, amounts, confidential clauses). This is a need that comes up time and time again from the field. Technically, it’s far from trivial: we need to ensure that the redacted information is actually removed from the document, not just visually hidden, otherwise it’s a false sense of security. This feedback from the field triggered a major architectural overhaul to integrate reliable redaction directly into the platform. That’s the power of listening to the field: it drives us to solve real problems, not imaginary ones.

DC : Do you ever turn down a development request from a client because it goes against your beliefs regarding security or architecture? How do you handle that?

Eric M. : Yes, and I make no secret of it. Part of my role is also to say no when necessary. If a client asks for something that compromises the platform’s security or introduces unmanageable technical debt, I refuse; but I never stop at simply saying no. I explain why, and above all I propose an alternative that meets the need without sacrificing the integrity of the whole system. It’s a question of responsibility: I manage a data room tool that contains documents sometimes worth hundreds of millions. If I say yes to everything just to please people, I’m putting all our clients at risk. The sales teams understand this very well, too: over time, this rigour has become a selling point, not a hindrance. When you tell a client, ‘We refused to take that shortcut to protect your data’, it inspires confidence.

DC : AI is finding its way into all professional tools. How do you approach this issue when data privacy is non-negotiable? What are your red lines? And are there any AI use cases you’re working on that could really transform the due diligence process?

Eric M. : AI is a subject I’m passionate about: I use it every day in my development work, so I know just how powerful these tools are. But when it comes to M&A data, the red line is clear: no customer data leaves our organisation to feed a third-party model. Ever. That’s non-negotiable. This means we don’t integrate AI just to tick a marketing box. We assess each use case with a simple question: does the data remain under our control, from start to finish? If the answer is no, we don’t do it. And above all, my view is that AI is a tool at the service of the user, not a service that replaces them. It’s an assistant to whom we delegate simple but time-consuming and often tedious tasks (summarising a 200-page document, performing a semantic search across an entire data room). But certainly not decision-making, and not even giving an opinion. Ultimately, it’s the professional’s name and their responsibility that will be on the file, not that of an AI. We are looking at this very closely, with a pragmatic approach: technology must serve the profession, not the other way round, and above all without ever compromising confidentiality.

DC : In five years’ time, what do you think data rooms will look like? And what advice would you give today to an M&A professional who is choosing a platform and who isn't a technical expert?

Eric M. : In five years’ time, I believe the data room will become a truly smart workspace, where information is indexed, summarised and accessible in a matter of seconds. The time-consuming tasks involved in due diligence (sifting through, filing and cross-referencing hundreds of documents) will be largely automated. But the core will remain the same: security and confidentiality. Tools that don’t put this at the centre will disappear. And what advice would you give to an M&A professional who isn’t a technical expert? It’s simple: ask three questions. Where is my data? Who has access to it? And if I have a problem, how long will it take to get a response? If the person you’re speaking to can’t answer these three questions clearly, move on. Don’t be swayed by fancy interfaces or buzzwords: what matters is what’s under the bonnet. And if possible, choose a provider that has end-to-end control over its technology. It makes all the difference when it really counts.