You came here because
A problem nobody has solved
Bluetooth pairing has been unreliable for a year, and nobody knows exactly why.
No capacity to start
The work is planned. Your own developers are booked for the next 6 months.
Performance people notice
Your data platform has got slow enough that the people using it have started to mention it.
Every change takes months
A feature that should take weeks takes months, and maintenance costs about twice what it should.
No shared design language
Every screen looks like a different product, and each new feature starts the argument again.
The experience never caught up
The product does what it should. What people actually see and touch never got the same attention.
None of this is news to you. You’ve looked at it, you’ve tried things, and it’s still there. That’s the part we take off your desk.
Not sure yet what needs fixing? Start with a diagnostic
What this usually looks like
Most of what we take on falls into one of four shapes, although the bigger jobs tend to be two or three of them at the same time. A rebuild is rarely only engineering, for instance, and a redesign that nobody can build is just a nice set of screens.
The shape of the work
What that usually means
A fix
One problem, clearly bounded. The Bluetooth that has been unreliable for a year, or the platform that got slow so gradually nobody can say when.
A redesign
The product works fine. It is what people see and touch that never got the same attention as the engineering underneath it.
A rebuild
Two apps that should have been one, or a generation of the product that has simply run out of room to grow into.
A design system
One design language your own team can build on, so the next screen doesn’t start the argument again.
What you get
1
Working software, or the design system behind it
Something your users can open on Monday, or a design language your own team works in.
One thing, fully solved, and live.
2
What we found before we started
Before anything gets built we work out why it ended up this way, and we tell you what we find. Bluetooth that has been failing for a year usually has a cause nobody has gone looking for. A product whose screens all differ usually has one too, and it is rarely the designers.
You get that in a conversation, early. It tends to be the 10 minutes that decide whether the rest of it holds.
You know the scope and the price before we start.
How we work
You bring the briefing
The problem, the roadmap, or the ticket that has been reopened 4 times. Whatever state it is in, that is where we start, and there is no discovery phase in front of it.
We work out what’s going on
Your briefing is our starting point. The shortest route to a fix that keeps working is often somewhere other than the ticket, and finding that out takes days rather than weeks. It’s also why there are no juniors on this.
It gets designed and built, and it goes live
We can’t build your solution on our own. We build it together. We work in your technology, on your repositories, in your rhythm, and we challenge you where it’s needed.
Designers and developers sit on the same team from the first day. On a redesign that is obviously the point. On a fix it matters more than people expect, because the reason something keeps breaking is often the way it was meant to be used in the first place.
Intensive contact, which is something other than meetings.
When we can start
Within 2 to 3 months we can start to design or build.
That is the honest number, and it is longer than you were hoping. Freeing up a team takes more arranging than putting a workshop in a diary, and we would rather tell you now than have you find out in week 3.
What it takes from you
A clear briefing
If it isn’t clear yet we’ll say so before we start, and there is a different way in for that.
A scope we agree on up front
One fixed price and one end date, both settled before anything begins.
Someone who can decide while we’re building
One person who answers a question the same day. A monthly steering committee costs you weeks, and you pay for those weeks.
How Locinox started here
.webp)
6 months
from concept to an MVP on the trade show floor
An app that lets an installer update the firmware and change a gate motor’s settings
That was the starting point. Locinox makes gate hardware, and the product it had to work with was a new motorised pedestrian gate closer, one an installer could configure without training. The existing generation needed 24 connectors. The new one had to work with 6.
They arrived with a design brief already written, and building it as drawn would have cost far more than the product could carry. So we went through it with them and reworked it until it fit the budget. That is design work, and it happened before anyone wrote a line of firmware.
Then we started small, on one part of it. What we built into the product is an update mechanism that runs over direct WiFi, without internet or 4G, so the firmware updates itself in a field where there’s often no connection at all. Locinox programmes new features on it themselves.
“Our engineers were looking for a partner they could trust and who could keep up with their pace, and they found Aaltra. It’s a team that thinks along with us. We can rely on them when time is of the essence.”
Read the Locinox case
We’ve also done this work for Bekaert, Duco, Atlas Copco, Wet and Artes.
See all our work
They already trust us, only your logo is missing
Send us what you have
A briefing, a roadmap, a ticket that keeps coming back: whatever state it’s in. Pieter-Paulus Vertongen, our CEO, reads it himself. He’ll come back with what he thinks it takes, how long it runs, and whether we’re the right team for it.
If the briefing points at something else, he’ll say that too.
Services
