Understand first, then build.
Software projects rarely fail on technology. They fail because building starts before anyone has looked properly at how the work actually runs. What you end up with is software that functions but sits just beside the process.
We work in four phases, and after the last one it starts at the first again. Every new wish follows the same route, whether we build something new or take over an existing platform.
Why it goes wrong so often.
Most failed projects start out enthusiastic. There is an idea, there is budget and building begins immediately. What there is not, is a picture of how the work runs today: which exceptions exist, who keeps a list beside the system, and why it grew that way.
Six months later there is software that adds up on paper. In practice half the cases turn out to be slightly different, the old list carries on, and nobody dares to say it is not being used. That is not a building error but a starting error, and repairing it afterwards is expensive.
So we put the first weeks into the process rather than the code. And we keep that going while building: every two weeks something is ready that you can use, so you can steer while steering still costs nothing.
Four phases, over and over.
They follow each other, but it is not a one-way street. What we learn in phase three goes back to phase one, which is how it keeps moving with your business.
- Digging in We get into your process, your systems and your code. What works, what costs money and what becomes a problem later? You get it in writing, with the order we would tackle it in.
- Building Small pieces that go into use quickly. You see something running within weeks instead of after six months, and we can adjust while that still costs nothing.
- Sharpening What people actually use always differs from what they asked for upfront. Every sprint we sharpen it against what the floor shows us, not against the plan.
- Keeping it running Hosting, monitoring, updates and a developer who knows your platform. No hand-offs: the same people who built it.
What a month with us looks like.
No twenty-page status report. A fixed rhythm instead, so you never have to ask how it is going.
-
Something working every two weeks
At the end of a sprint there is something on a test environment you can click through yourself. Not a demo of a screen, but the real thing with your own data in it.
-
A quarter of an hour to catch up
Briefly going through what is done, what disappointed and what comes next. Usually over video, and when nothing special is going on it takes ten minutes.
-
You decide the order
The wish list is yours. We say roughly what something costs and where the risk sits; what gets built first is your call.
-
One invoice, no surprises
You see in advance what a sprint costs and afterwards where the hours went. If something overruns you hear it during the sprint, not on the invoice.
Questions we get a lot.
Not in the list? Just ask, and you get an answer straight from someone who would have built it.
Ask your questionWhat is custom software exactly?
Software we build around your process, instead of a package you have to work around. Usually that is a portal, a dashboard or a link between systems you already use. You notice the difference in the exceptions: that one order type, that one client with their own pricing. In a standard package those are workarounds. In custom software they are simply buttons.
Website, web app or app: what is the difference?
A website is there to be read. A web app is there to work with: log in, enter, process. It runs in the browser, so on any device and without an install or an app store. An app sits on the phone itself and can reach the camera, location and notifications. For most business processes a web app is enough, and a lot cheaper to maintain.
What is an integration?
Making two systems talk. Your ERP passes stock to your webshop, the webshop sends orders back, and your accounting gets the invoices. That runs over an API: an agreed language between two programs. If a system does not have one, we build the bridge to it. The result is that nobody retypes anything.
What does it cost roughly?
An integration usually starts around ten thousand euros, a platform runs from twenty five thousand up to a few hundred thousand. It depends mostly on the number of exceptions in your process. We prefer to work back from what it returns: if someone spends four hours a week retyping, that is more than half a working week a month.
How long does a project take?
An integration is often live within a few weeks. A platform we build in pieces: the first version usually runs after two or three months, and after that something is added every two weeks. So you do not wait half a year before you see anything.
Who owns the code and where does it run?
The code sits in your repository and stays yours, also when the partnership ends. Hosting, backups and monitoring run with Dutch parties, so during an audit you do not have to go looking for where your data lives.
Do you work with our existing suppliers?
Often, yes. Sometimes we build the platform while another party runs the infrastructure, or the other way round. As long as it is clear who is responsible for what, we work fine alongside the people already there.
What if our current builder stops?
Then we take it over. We read ourselves in, write down how it fits together and take over maintenance. Also when there is no documentation and the code is a mess, because that is usually exactly why someone calls. Within about three weeks you know where you stand again.