When Blindspot co-founder Tijl Van Mierlo first came to us, he already had a pretty good idea of what he wanted to build. In fact, he had mapped out most of the product himself, screen by screen, in PowerPoint.

The idea behind Blindspot was to make life easier for field sales reps. Customer information typically lives in a CRM, while planning who to visit and how to get there happens somewhere else. Blindspot brings those things together in one platform, helping sales reps plan their customer visits and routes more efficiently.

Or, in Tijl's words:

“A kind of smart Google Maps, but built for sales reps.”

The idea was clear and the first sketches were there. What Tijl needed was a development partner who could turn them into an actual product, but also understood enough about the niche to challenge and improve what was already on paper.

A little over 18 months later, Blindspot's latest version is live. Looking back, Tijl says one thing in particular made the difference throughout that process: knowing what to expect.

Finding a team that understood the idea

Before choosing Hatch, Tijl spoke to three or four potential partners. The decision wasn't primarily about finding the lowest quote. He was looking for a team that showed enough interest in the product to really understand what he was trying to build.

Blindspot operates in a very specific niche, and that meant getting familiar with the reality of field sales rather than simply taking a list of requirements and turning it into software.

“You want people on board who will dive into your niche with you and understand what you're talking about. At Hatch, they got it from the very first conversation.”

So before we started designing, we did our own research into the market and the solutions that were already out there. We looked at what made sense to take inspiration from, what didn't, and how Tijl's initial ideas could translate into a product that would actually work for sales reps in their day-to-day jobs.

From there, his sketches gradually turned into designs in Figma. We worked through the flows together and used clickable prototypes to fine-tune the experience before development started.

By the time we moved into code, we weren't simply building what had originally been drawn in PowerPoint anymore. We had shaped the product together.

One phase at a time

The first development phase took roughly six months and resulted in Blindspot's Minimum Viable Product (MVP).

After that, Blindspot secured an innovation grant from VLAIO, which Tijl decided to invest fully in further developing the platform. A second phase followed, again spanning roughly six months, and the new version of Blindspot went live in July 2026.

Both phases followed much the same rhythm. Tijl explains what he wants to achieve, we analyse what it would take to get there and, before development starts, put an estimate on the time and budget involved.

That predictability is something Tijl keeps coming back to when talking about the collaboration.

“They give an estimate of the time, and with it a budget, and they always stay comfortably within it. For me as a founder that is extremely valuable, because my job is cash flow planning and keeping our head above water.”

When you're bootstrapping a company, a development budget isn't just a project budget. It's part of the bigger financial picture, and an unexpected extra few weeks of development can have consequences elsewhere in the business.

Knowing what a phase is likely to cost means Tijl can make those decisions before the work starts. It also gives him the freedom to adjust along the way: postpone something, move a feature to a later phase or invest more when the business is ready for it.

So far, each phase has stayed within the time and budget estimated upfront. Not a particularly flashy product feature, admittedly, but a useful one when you're the person paying the invoices.

The thousand-and-one-ideas problem

Predictability doesn't mean sticking rigidly to a roadmap either. Blindspot is still evolving, and so are Tijl's ideas for it.

Quite frequently, in fact.

“As a founder you have a thousand and one ideas a day.”

The temptation, of course, is to turn every good idea into another feature. But when time and budget matter, deciding what deserves to be built now is at least as important as coming up with what could be built next.

That's a conversation we have quite often with Tijl. When a new idea comes up, we look at what it would add to the product, how urgent it actually is and whether it makes sense to invest in it at that point.

Sometimes that means reminding him that we've had exactly the same conversation before.

“It helps to have a counterweight that says: nice idea, but we looked at this before and decided against it for good reasons. They challenge me on that, and I really appreciate it.”

We don't see our role as simply working our way through a list of requested features. Part of building a good product is being willing to question that list in the first place, especially when the person you're building it with has another thousand ideas waiting behind it.

Keeping things close

There was another reason Tijl deliberately looked for a Flemish development partner. He wanted the people building Blindspot to be within reach.

That sounds like a fairly small consideration in a world where software teams can work from pretty much anywhere, but in practice it has become an important part of how we work together.

If something comes up, Tijl can send a WhatsApp message or pick up the phone. If a conversation is easier face to face, he drives to our office in Leuven. He's joined us for lunch more than once and has been known to end up at the dartboard on a Friday evening.

There is, in other words, very little ceremony involved.

“On one side you have the quality and the estimates that have to be right. Beyond that, the human side matters a great deal to me. In the age of AI, maybe even more.”

That last part is interesting, particularly now. The tools we use to design and develop software are changing quickly, and we're quite happy to embrace that. But the collaboration around the product still matters: understanding the business behind it, discussing priorities, pushing back when needed and taking responsibility for what eventually goes live.

Those are difficult things to outsource to a prompt.

From building the platform to growing Blindspot

The latest version of Blindspot has been live since July 2026, and the focus is increasingly moving towards go-to-market. The first users are working with the platform, feedback is coming in and new ideas for the product continue to emerge.

Our role has evolved with it. Instead of working towards the first version of the product, we now manage the platform and continue developing it together with Blindspot. New features are discussed as they come up, each with their own scope and estimate, while we keep looking at what makes sense for the product at that moment.

For Tijl, having the same team alongside him throughout that process provides something that is difficult to put into a feature list.

“A partner who estimates well and, in our case, always delivers more than promised gives you a real sense of security. I always know where I stand as a founder.”

And as Blindspot moves from building the product to growing it, that continuity becomes all the more valuable.