IZIRepair

The problem I saw

Car maintenance has a trust problem. For most vehicle owners, a repair bill feels opaque: you do not know whether the diagnosis is accurate, whether the price is fair, or whether the work was actually done. You rely on whoever you happen to know.

But trust was not the only friction. There was a second one: time. Taking the car to a workshop, waiting for a quote, coming back to collect it - for a working driver, that is a half-day problem that rarely goes away.

Those two frictions - opacity and inconvenience - shaped the first versions of the product. The initial focus was on instant online quotes in a booking-style marketplace (think Airbnb, but for workshop services), combined with a car pick-up and delivery option offered by some partner workshops. The goal was to remove both the information asymmetry and the logistical burden from the same platform.

From Bookauto to IZIRepair

Before IZIRepair, there was Bookauto. I co-founded it with someone I had studied with at university (ISEG). We were both from economics and management backgrounds, with no technical founder and no one inside the team who could build the technology we were trying to create.

My first attempt at validating the problem relied heavily on online questionnaires shared with friends and family. The responses were encouraging. People said they found the problem relevant and the proposed solution interesting. In retrospect, this told me almost nothing useful. People close to you are predisposed to support your idea, and closed-form questions test whether someone likes your proposed solution - not whether they have a real problem worth solving. I should have been doing unstructured discovery interviews with strangers before becoming attached to any answer.

We then tested the proposition more concretely. We used a landing page to collect emails for a waiting list, with car-maintenance discount coupons as one incentive to sign up. This was still not a software product - it was a demand test around a customer proposition.

After that, we moved beyond the waiting list and started serving real customers in Lisbon. We worked with a small number of local partner repair shops and coordinated real maintenance jobs, including car pick-up in some cases. The service was operated manually behind the scenes. Customers could receive up to three quotations from different local repair shops: we generated the estimates manually, using third-party automotive maintenance data, assembled them and sent them through Mailchimp, usually in less than 24 hours. What looked like a simple digital quotation experience to the customer was still heavily manual underneath. The data source happened to be a trial VRC account from TIPS4Y - a tool I would unexpectedly return to almost a decade later as Head of Product & Growth.

The founding structure created another problem. Bookauto was built on a 50/50 ownership split with no clear mechanism for resolving disagreement when it eventually arrived. It did arrive. Differences between the two founders led us to separate while the service was still manually operated.

Bookauto ended before the software product existed, but not before we had started serving real customers. We had moved from a landing page and waiting list to a manually operated service with local workshops in Lisbon. The customer-facing promise was ahead of the technology behind it. The operational learning was real, but the model was difficult to scale.

I did not leave convinced that the underlying problem was irrelevant. The opacity, the trust asymmetry, the inconvenience - those were real. I decided to try again, this time with two new co-founders and a clearer architecture from the start.

IZIRepair was not Bookauto renamed. It was the decision to take those operational learnings and start again with a new team and an actual technology product - productising much more of the customer journey and moving towards a true marketplace architecture.

What we built

Bookauto was closer to a manually operated concierge service than a technology product. We used a landing page to acquire demand, then handled quotations, workshop matching and much of the customer journey manually behind the scenes. That gave us real operational learning before we had software, but it was difficult to scale. With IZIRepair, we set out to productise much more of that experience and move towards a true marketplace architecture. Customers could choose workshops directly. The customer-workshop relationship became more direct. Collection and delivery became an optional add-on rather than something that had to be handled centrally every time. The goal was to preserve the consumer value while reducing the amount of operational complexity that had to be handled centrally.

The core offering started with online quotations for car maintenance services, workshop comparison and selection, booking and payment, and that optional collection and delivery service. On the supply side, we built tools and back-office capabilities that helped workshops manage incoming requests and communicate with customers.

Over time, we explored adjacent capabilities including customer support, regular maintenance, vehicle reminders and alerts, mobility options while vehicles were being serviced, predictive maintenance and potentially connected-car capabilities. These were directions we explored, not features that all reached full production maturity.

The marketplace challenge

We had built a marketplace where one side had a much clearer reason to exist than the other.

For vehicle owners, IZIRepair solved tangible problems: instant online quotations, easier price comparison, more transparency about what was being charged and why, the convenience of booking without calling around, and the option to have the car collected and returned. The value proposition was strong.

For many independent workshops, the picture was different. Many already had enough customers to keep their bays occupied, pay their costs and operate profitably. For a workshop in that position, the offer - 'we can bring you more customers' - was often not compelling enough to justify adopting a new system, changing operational workflow, increasing price transparency, or paying a commission on transactions that might have arrived through existing relationships anyway.

This was not a failure of product quality or execution. It was a structural imbalance in the underlying value proposition. A marketplace cannot be designed primarily around improving the experience of one side. Both sides need a strong economic reason to participate, consistently enough to create and sustain liquidity.

That imbalance compounded the other dynamics already working against us: low purchase frequency on the consumer side, the difficulty of displacing existing mechanic relationships built on trust, and the challenge of building marketplace density without the early liquidity that makes both sides keep coming back.

Searching for a scalable model

The original IZIRepair marketplace monetised transactions through commissions on workshop services paid through the platform. But revenue and funding were very different things. At that early stage, transaction volume was still low, and those commissions covered only a small fraction of the company's monthly operating costs.

The business was financed largely by the founders. I invested a significant part of my personal savings, while Fernando Guimarães, our CTO and co-founder, and I also spent long periods working without salaries. Like many early-stage startups, we were effectively financing the company through a combination of cash and founder opportunity cost.

By 2017, that model was becoming increasingly difficult to sustain. It was in that context that Altice Labs introduced us to SAPO's commercial leadership. The initial conversation was exploratory: we discussed product integration, distribution and, at a high level, a possible M&A outcome. SAPO's commercial director made clear that an acquisition process would be complex and slow, and would not solve IZIRepair's immediate situation. Instead, he proposed a commercial partnership that could help us keep operating while we prepared a new workshop service under the AUTO SAPO brand. The revamp that followed was largely our team's effort: we adapted the IZIRepair platform to the new branding, shaped the product and operating model, and prepared the service for a national rollout. On SAPO / MEO's side, the main contribution was training the commercial team to take the new proposition to workshops. Marketing activity remained limited, and did not develop into a substantial campaign behind the launch.

That proposal evolved into AUTO SAPO Oficinas, powered by IZIRepair. IZIRepair's product became the engine behind a new, more transactional experience that replaced the old directory. The service used AUTO SAPO branding. Most of the product adaptation and rollout preparation was done by IZIRepair, while SAPO / MEO focused primarily on training its commercial team to approach workshops with the new proposition. Marketing activity on the SAPO / MEO side remained limited. The national soft launch followed in late 2018. There was no separate pilot before that rollout.

The partnership also changed workshop-side monetisation. Instead of relying only on transaction commissions, workshops could operate under different subscription tiers that influenced visibility, commercial conditions and transaction commissions. The exact mechanics varied, but the strategic move was clear: AUTO SAPO introduced a hybrid B2B subscription plus transaction model, creating recurring value and monetisation options on the workshop side.

By 2019, the workshop marketplace and AUTO SAPO Oficinas were still operating. Alongside that existing business, we began testing a separate consumer maintenance subscription thesis designed to address low transaction frequency, weak recurring revenue and the desire for a more continuous relationship with the vehicle owner. During SENTE Foundry Mobility III, we materially shifted the startup pitch towards this new consumer proposition and raised initial capital around it. That investment was external validation of a compelling thesis, not proof that it had already worked in production.

We tested the consumer subscription model, but it failed to produce enough evidence that customer behaviour and subscription economics could support the business. AUTO SAPO Oficinas and the original marketplace continued operating in parallel. The two subscription experiments were different: one changed workshop-side monetisation; the other was a consumer membership and mobility thesis. Neither ultimately produced the sustainable scale we needed.

AUTO SAPO Oficinas

The partnership with SAPO / Altice was one of the most significant things we built. It emerged while IZIRepair was financially constrained and needed a way to extend its runway, but it was not an acquisition and it was not merely a rescue mechanism. The high-level M&A discussion did not progress because it was too slow and complex for the immediate situation. What followed was a commercial agreement with real strategic and product significance.

Auto SAPO was one of Portugal's leading automotive portals - a high-traffic destination that vehicle owners already trusted for car listings, news and market information. AUTO SAPO Oficinas, powered by IZIRepair, replaced its previous workshop directory with an IZIRepair-powered product experience. The product and platform adaptation to the new branding, along with the operating model and launch preparation, was largely led by IZIRepair. SAPO / MEO's main contribution was preparing and training its commercial team to approach workshops with the new proposition, while marketing activity remained limited.

This was a genuine corporate product integration: national reach, credibility with workshops and consumers, new user acquisition, a more visible workshop presence and a hybrid B2B monetisation model. For a startup without the resources to build that audience organically, it was a meaningful achievement that gave the venture more time to operate.

But distribution is not product-market fit. AUTO SAPO improved reach, credibility, workshop visibility and monetisation options. What it could not automatically solve was thin marketplace liquidity, the imbalance in workshop incentives, low consumer frequency or a business model that had not yet found sustainable, repeatable growth. Those had to be solved at the product level.

There is also a harder retrospective observation. AUTO SAPO was a genuinely encouraging signal - and encouraging signals, when they arrive repeatedly, can make it easier to believe that sustainable scale is still reachable. The partnership was not a mistake. But it was one of several real achievements that made the decision to stop harder to reach than it might otherwise have been.

"IZIRepair accumulated many of the signals founders are taught to celebrate - awards, investment, accelerators and a major distribution partnership. What it did not build was enough repeatable demand and marketplace liquidity to reach sustainable scale."

What ultimately happened

The business generated enough encouraging signals to make stopping harder than starting.

Awards, ecosystem recognition, a major distribution partnership, international investment - these were real. But they also arrived at intervals that made the next milestone feel plausible. Each one created a reason to believe that the fundamental metric - repeatable customer behaviour and viable marketplace economics - might still change. It did not change at the rate needed.

In December 2020, I accepted an invitation to become CEO of Tap My Back, then part of the Build Up Labs startup studio. My professional focus moved towards building that business. IZIRepair continued operating the AUTO SAPO Oficinas service at a minimal operational level - maintained rather than aggressively grown.

Approximately one year later, the founders looked seriously at how to bring the venture to a close. A small exit or asset sale was explored, but nothing viable materialised. We decided to end the venture rather than continue maintaining a business that had not demonstrated a path to sustainable scale. The company closed in 2022.

Looking back, one of the clearest lessons is that the distinction between meaningful progress and a business becoming sustainable is harder to see from the inside than it looks from the outside. Milestones feel like evidence. Sometimes they are. Sometimes they are just milestones.

What I got wrong - and what I learned

How it shapes my work today

IZIRepair is the startup where I experienced zero-to-one building from the inside - not as an advisor, not from a case study, but as a co-founder navigating customer discovery, fundraising, team design, corporate negotiation, product iteration, marketplace economics, and eventually the decision to close.

Those experiences inform how I work with founders today in ways that are hard to replicate from a book. I know what it looks like when early validation feels solid because the signals are encouraging rather than because the evidence is strong. I understand the specific discomfort of a distribution partnership that creates real acquisition but does not move the underlying business. I have been inside the decision about whether a milestone represents progress or postponement.

The pattern recognition I carry from IZIRepair shows up in mentorship and advisory conversations around customer discovery methodology, founding team design, marketplace incentive structure, the difference between acquisition and retention, capital allocation under uncertainty, and how to read external validation without letting it substitute for harder evidence about the business itself.

Not as cautionary tales, but as calibration. The founders I work with best are often the ones who are in the middle of exactly the kind of difficult judgment that I only understood fully after making expensive mistakes inside it.