You came here because
Architecture that has to scale
You’re not sure your architecture will still hold once you grow.
Adoption never came
You built the platform, and the adoption never came.
Installation quality in the field
The quality of installation in the field isn’t at the level the market expects.
Knowledge walking out the door
Your most experienced technicians are retiring, and the same support calls keep coming.
Data nobody acts on
You have the data. You just can’t turn it into something anyone acts on.
Doubt about the CRA
You’re not sure whether your product meets the Cyber Resilience Act.
Every one of these takes research to answer. If you already know what needs fixing, you want a different door.
Go straight to build instead
What you get
One report, presented to the people who decide, and useful without us in the room.
1
What’s actually going on
The cause behind the symptom you called us about, with the research behind it.
Including the parts that turn out to be fine.
2
What needs to happen, and in what order
Recommendations you can prioritise, with an order of magnitude next to each one.
So you know what you’re weighing against what.
3
Whether to repair or rebuild
Sometimes a rebuild costs less than another 2 years of patching. Sometimes you’re better off keeping what you have.
We say which, and we show the sums.
We tell you what needs to happen. How to execute it is a separate decision, and a separate conversation. Which also means the recommendations hold, and the numbers hold, whoever ends up doing the work.
And when it’s done, it’s yours. The report is written to be acted on by anyone, including a team that isn’t us. You’re free after this.
How we work
Before we start you send us what already exists: your architecture, your usage data, your support tickets, the roadmap as it stands. Then we go and find out, and how we do that depends on what you’re facing.
If this is your question
This is how we answer it
Architecture that has to scale
We go through the architecture you have against where you’re heading: what holds, what gives first, and what it takes to change it.
Adoption never came
User research and behavioural data. Where exactly do people drop off, and on which screen.
Installation quality in the field
We go out with an installer. What goes wrong during an installation doesn’t show up in an interview.
Knowledge walking out the door
We work through your support tickets and ride along on service calls, to find the knowledge that only exists in someone’s head.
Data nobody acts on
Who looks at which screen today, and what decision were they supposed to make with it.
Doubt about the CRA
We check the product against the regulation: update mechanism, vulnerability handling, security by design, the full lifecycle. We assess and advise. We don’t certify, and we’re not a notified body.
Whatever the question, we talk to the people who use, install or service your product. That part isn’t optional. Without it we’d be handing you one more opinion, and you have those already.
We look at the product, not at the team. In our experience the technology is usually fine, and what creates the gap is distance between what got built and what people in the field do all day. Nobody sees that from inside their own product.
We never separate user experience from technology
The two shape each other, and looking at one without the other is how these problems stay unsolved.
Research the experience without knowing the technology and you end up with “the app should be nicer”. Research the technology without watching a single user and you end up with “the system works as designed”. Both answers are true, and neither one helps.
One workshop, and only if we need it
If a decision comes up that we can only make with your team in the room, we run a workshop. One at most, and only when the research asks for it.
Then we present it
To the people who decide, in one session. What you take away is the report, and you can hand it to anyone.
4 to 6 weeks, from kick-off to presentation
Talking to installers, riding along on service calls and working through a year of support tickets takes the time it takes. You get an answer at the end of it.
We can usually start within 2 to 4 weeks.
What it takes from you
Access to the people who use, install or service your product. Which of the three depends on the question. Without it, we’d be guessing in a more expensive way.
A look at what’s already there: architecture, usage data, support tickets.
Privacy and security by design, not an afterthought
All of our security documentation is in the trust center
This work asks you to open up a system, so it matters who is looking at it. We have worked under strict regulation for years.
The Cyber Resilience Act is coming for nearly every connected product.
They already trust us, only your logo is missing
Not sure this is even researchable?
That’s a fair first question, and it’s the one to bring. Pieter-Paulus will tell you in one conversation whether research can answer what you’re describing, or whether you already know enough to go and fix it. If it’s the second one, he’ll say so.
No pitch deck. Bring the problem and what you’ve already tried.
Services
