Some of the most useful software does not begin inside software companies. It begins inside operational businesses that hit the limits of spreadsheets, generic SaaS, manual processes, and disconnected tools.
Before leading Exirio, Damien Toulouse built technology inside restaurant and food-delivery operations, including kiosk-only ordering systems, marketplace API integrations, automated order-routing logic, real-time kitchen displays, and operational analytics. His experience shows a pattern many founders eventually recognize: when the market is still immature, the right product often has to be built from first principles.
In this conversation, Damien explains how founders should think about build-versus-buy decisions, what makes operational software difficult, and why internal tools can become a source of strategic advantage when they are designed around real workflows.
1. Many founders are told not to build internal tools because SaaS already exists. When is that advice wrong?
Damien Toulouse:
The advice is often right at the beginning. If a mature SaaS product solves 80% of the problem, you should usually use it. Founders have limited time, limited capital, and too many things to build.
But the advice becomes wrong when the workflow that makes your business different is not supported by existing tools. In that case, forcing the business into a generic SaaS process can create hidden costs: manual workarounds, duplicated data entry, poor visibility, slow operations, and eventually a worse customer experience.
The question I ask is simple: is this process administrative, or is it part of the company’s operating advantage?
If it is administrative, buy. If it determines throughput, margin, customer experience, or product quality, you should at least consider building around it.
In my restaurant and food-tech businesses, ordering, kitchen routing, marketplace integrations, and operational analytics were not side processes. They were the business. That made proprietary software much more strategic.
2. What was the first operational problem that made you realise existing tools were not enough?
Damien Toulouse:
The first clear moment came when we wanted a customer experience that did not exist in the market at the time.
In casual dining, the standard flow was still very manual: customers ordered at a counter, staff entered the order, the kitchen interpreted it, and data was often fragmented across systems. I wanted a kiosk-only ordering model where the customer could customise a dish in detail, the order could go directly to the right kitchen workflow, and the business could track what was actually happening during service.
That sounds simple now, but at the time there was no off-the-shelf system that matched the level of personalisation and operational control we needed. For example, a Vietnamese pho order can include many ingredient-level choices. The UX had to make that easy for the customer while keeping the kitchen process clean.
So the software was not a nice-to-have. It was the only way to make the operating model work.
3. What makes operational software harder than it looks from the outside?
Damien Toulouse:
Operational software has to survive reality.
A normal SaaS interface can often assume that the user is sitting at a desk, focused, with time to correct mistakes. In an operational environment, people are moving quickly. Staff are under pressure. Customers are waiting. Orders arrive in bursts. Hardware can fail. Internet connections can be unstable. A small UI mistake can become a bottleneck within minutes.
So the software has to be simple, fast, and forgiving. It has to match the physical workflow.
In a kitchen environment, for example, it is not enough to display an order. You need to think about routing, timing, modifications, preparation sequence, delivery platform requirements, and how the team will understand the information under pressure.
That is why operational software is not only an engineering problem. It is a systems design problem.
4. How did APIs change the way you thought about food operations?
Damien Toulouse:
APIs turned food operations from a set of separate workflows into something closer to a connected system.
If you operate through delivery platforms, POS systems, kitchen displays, and your own internal tools, the problem is not only receiving orders. The problem is making sure the right information moves to the right place at the right time, with as little manual intervention as possible.
At Central Kitchen, the goal was to reduce the number of human handoffs. Every manual handoff is a chance for delay or error. If an order from a marketplace can be captured, routed, displayed, prioritised, and tracked automatically, the kitchen can focus on execution rather than administration.
The value of APIs was not technical elegance. The value was throughput, accuracy, and visibility.
That lesson applies far beyond food tech. In any operational business, APIs become powerful when they remove friction from the core workflow.
5. What did kiosk ordering teach you about product design?
Damien Toulouse:
It taught me that good UX is not about making the interface look modern. It is about reducing hesitation.
A kiosk user is not patient. They do not want to learn your system. They want to order quickly, understand their choices, feel confident that the order is correct, and move on.
That creates several product constraints. The menu structure has to be clear. The customisation flow has to be logical. The system cannot overload people with options too early. It must reduce mistakes, especially when the product has ingredient-level personalisation.
The other lesson is that UX and operations are connected. A design decision on the kiosk can affect kitchen complexity, service speed, average order value, and customer satisfaction.
A founder should never treat UX as something separate from the operating model. In many businesses, UX is the operating model.
6. How should founders decide which parts of the workflow to automate first?
Damien Toulouse:
I would start with three questions.
First: where does the business lose the most time?
Second: where do errors create the most cost?
Third: where does better data improve decisions?
If one workflow scores highly on all three, that is usually a strong candidate for automation.
In food operations, order routing is a good example. If routing is manual, it slows down the team, creates mistakes, and makes it difficult to analyse performance. Once you automate it, you improve execution and create better data.
But founders should avoid automating everything at once. Automation only helps when the process is understood. If the workflow is still changing every week, premature automation can lock the company into the wrong process.
The best sequence is: observe the real workflow, simplify it, instrument it, then automate the parts that are stable and high-impact.
7. What metrics matter most when software is used to run physical operations?
Damien Toulouse:
You need metrics that connect software behaviour to operational outcomes.
In a restaurant or dark-kitchen environment, that might include order acceptance rate, preparation time, delivery-time SLA, cancellation rate, modification errors, kitchen throughput, contribution margin by brand, and demand by time of day.
The important thing is not to create a beautiful dashboard. The important thing is to make the data actionable. If a metric does not help someone make a better decision, it is probably noise.
For example, knowing total orders is useful, but knowing which brand creates bottlenecks during peak hours is much more useful. Knowing revenue is useful, but knowing margin contribution by menu item or channel is more useful.
Operational analytics should help managers change behaviour, not just report what happened.
8. You have built software in food tech and now lead a WealthTech platform. What is the common thread?
Damien Toulouse:
The common thread is that both domains require software to organise fragmented information and support better decisions.
In food tech, the fragmentation was operational: orders, menus, delivery platforms, kitchen workflows, demand patterns, and margin data. In WealthTech, the fragmentation is financial: accounts, assets, currencies, institutions, user goals, and portfolio behaviour.
The domains are very different, but the product discipline is similar. You need reliable data, clear workflows, good instrumentation, and a strong understanding of what the user is trying to achieve.
I think that is why operational experience is valuable in technology. It teaches you that software is never abstract. It lives inside human behaviour, business constraints, and real-world pressure.
9. What mistakes do founders make when they build proprietary software too early?
Damien Toulouse:
The first mistake is building before they understand the process. If you automate a messy workflow too early, you often preserve the mess inside code.
The second mistake is overbuilding. Founders sometimes imagine a complete platform when they only need one narrow tool that solves a painful problem.
The third mistake is treating internal tools as a side project. If the tool supports a critical workflow, it needs product ownership, maintenance, documentation, and user feedback. Otherwise, it becomes technical debt.
The fourth mistake is failing to measure impact. If you build proprietary software, you should know what it improves: speed, accuracy, margin, conversion, retention, or decision quality.
Building software is expensive. The justification should be operational impact, not founder preference.
10. How do you avoid creating internal tools that only one company can understand?
Damien Toulouse:
You need to separate the workflow logic from the company-specific details.
Every business has its own vocabulary and habits, but the underlying patterns are often reusable: intake, validation, routing, prioritisation, status tracking, exception handling, reporting, and feedback loops.
If you design around those patterns, the system becomes more flexible. If you design only around today’s exact process, it becomes fragile.
Documentation also matters. Internal software often fails because knowledge lives in one founder’s head or one developer’s head. If the company grows, that becomes a bottleneck.
The goal is not to build a generic SaaS product from day one. The goal is to build internal software with enough structure that it can evolve as the business evolves.
11. What should non-technical founders understand before they ask engineers to build operational software?
Damien Toulouse:
They should understand that engineers cannot compensate for an unclear process.
Before writing code, the founder needs to define the workflow, the edge cases, the user roles, the data needed, and the decision that the software is supposed to support. If that thinking is missing, the engineering team will either make assumptions or build something too generic.
I also think founders should spend time with the people who will use the tool. Watch the kitchen team, the operations team, the support team, or the sales team. See where they hesitate, where they create workarounds, where they copy information between systems.
That observation is product research. It is not less important because the users are internal.
12. What is your practical advice for founders deciding between SaaS, no-code, and custom software?
Damien Toulouse:
I would think in stages.
Use SaaS when the process is standard and not part of your differentiation. Use no-code or low-code when the workflow is still evolving and you need to test quickly. Build custom software when the process is stable, strategically important, and directly connected to performance.
The danger is choosing custom software for ego reasons. The opposite danger is staying with generic tools too long because building feels risky.
A good rule is this: if your team is repeatedly creating manual workarounds around a SaaS product, and those workarounds affect customers, margin, or speed, the SaaS product may no longer be the right system of record.
At that point, building is not about owning technology for its own sake. It is about designing the operating system your business actually needs.
When Software Becomes the Business Advantage
The build-versus-buy decision is often framed as a technology question, but Damien’s experience shows that it is really an operating question. Founders should not build proprietary software simply because they can, or because custom tools feel more impressive than SaaS. They should build only when the workflow is strategic enough, stable enough, and important enough to justify the cost.
Generic SaaS works best when the process is standard. No-code works best when the process is still being tested. Custom software becomes powerful when the process defines how the business wins.
For operational founders, the lesson is clear: the right software is not always the most advanced system. It is the system that understands the business better than any generic tool can.
