We build it, in whatever shape it arrives.
A portal where your customers sort out their own business. An app for the engineer in the van. A connection between your ERP and your webshop. And when it is needed, a box of our own that reads the inverters on the roof and sends the figures to the dashboard we build alongside it.
We take the process as the starting point rather than the package. That way you never have to work around anything, and the awkward exceptions are simply part of it.
What we build when someone says custom.
From a screen people work in every day to a circuit board pulling in measurements. Usually it comes together in one project: the portal, the connection to the system underneath and the app for the people out on site. Whatever is missing we build, and whatever works we leave alone.
-
Web applications and portals
Where your team and your customers work. Ordering, requesting, planning, invoicing. It runs in the browser, so on any device and without installing anything.
-
Mobile apps
For the people out on site. Signing off job sheets, taking photos, scanning. Also when there is no signal for a while and the data travels along later.
-
Connections between systems
ERP, WMS, accounting, webshop, point of sale. We build the bridge between them, even when one side has no decent interface.
-
Automating processes
Everything that is retyped by hand or kept in a spreadsheet. Usually that returns more in the first months than the building cost.
-
Measuring and reading out
Inverters, machines, sensors and meter cupboards. We have built our own boxes that read what is happening and send it on, smart meters included.
-
Dashboards and reporting
The figures you steer on, pulled together from every system. Not a monthly export, but correct at any moment.
Why we start small.
Roughly three in ten software projects finish on time and on budget. That number has not moved in thirty years, and it is rarely down to the technology.
-
Big fails five times as often
Large projects run aground more than five times as often as small ones. So we cut it into pieces that hold value on their own, even when the whole is large.
-
The brief changes along the way
In more than half of all projects the scope shifts while it is being built. That is not a mistake, that is how it goes. You just have to be built for it.
-
You see something work within weeks
The first piece is usually there within six weeks and goes into use. That is when it becomes clear whether we understood it properly.
-
Stopping costs you nothing
Whatever is finished runs and is yours. You are never locked into something that only pays off in a year.
From idea to something running.
Not six months of talking and then building. We start by understanding and then put something new in place every fortnight.
Book a call-
We sit in
At the table with the people who do the work. What goes in, what comes out, where it gets stuck and which exceptions genuinely exist. That gives us more than ten pages of requirements, because people show what they never write down.
-
The first piece goes live
We build the part where the pain is worst and put it live with a handful of people. If our picture is wrong, we find out now rather than in six months.
-
Something gets added
Fixed sprints, a fixed release day. You set the order and can turn it over every sprint. What looked important last week may drop off the list.
-
We stay on it
The same people who built it keep it running and keep building. No handover to a support desk that does not know your project.
What we build belongs to you.
This is what companies most often discover afterwards: the software they paid for is not legally theirs. Without an explicit transfer the builder keeps the rights, and then you cannot simply have your own platform changed by someone else.
With us it is written down. The code, the repository, the servers and the documentation are in your name. If you want to continue with another party tomorrow, you hand it over and we will not stand in your way. That is not us being nice, that is how it should be.
What we built for others.
From a connection between two systems to a platform people work in every day.
All cases-
De app en de API waarmee een SOS binnen seconden bij vrijwilligers in de buurt ligt.
Een SOS die binnen seconden op de telefoon staat van vrijwilligers een paar straten verderop.
-
De app die hun magazijnsysteem en Shopify aan elkaar knoopt, te installeren vanuit de App Store.
Voorraad die in het magazijn afgaat en op hetzelfde moment in de webshop klopt.
-
De vernieuwde site met een configurator waarin klanten hun eigen pakket samenstellen en meteen bestellen.
Bestellingen die binnenkomen zoals de klant ze zelf heeft samengesteld, klaar om te verwerken.
Helpful, proactive and always solution minded. Communication and transparency are their strongest points.
Questions about custom software.
Not answered here? Just ask. You get someone who builds.
Ask your questionIs an existing package not cheaper?
At the start, almost always. It tips the moment you have to work around your package: exports someone updates by hand every week, a connection that does not exist, per-user licences while you grow. Once that runs for three years, custom is often cheaper. We would rather do that sum honestly than talk you into something.
What does it cost?
A first working part is usually a six to eight week project. What the whole comes to depends on how much has to go in. After the first call you get an outline with a figure per part, so you can decide yourself where to start and where to stop.
How do you stop it from overrunning?
By working in pieces that go into use separately. There is no moment where everything has to be finished at once, so a setback shifts one sprint instead of the whole project. And because you see something every fortnight, you notice immediately if it heads the wrong way.
Do you build the hardware too?
When it is needed, yes. We have built our own boxes that read inverters and meters and send the values to software we also make. If something exists that can do it, we simply buy that. We only build our own when nothing fits.
Who owns the code?
You do. Code, repository, servers and documentation are in your name and we put that in writing. If you want to continue with another party later, you hand it over without us making it difficult.
What if our wishes change along the way?
That happens in more than half of all projects, so the approach is built for it. At the start of every sprint you decide what comes first. What was at the top last month may drop off.
Do you work with a fixed team?
Yes. The same people who build it stay on it once it runs. You do not get handed to a support department that does not know your project.
Can you connect to a system without an API?
Usually. Then we read whatever is available: a database, an export folder, a file format from 2009. Less elegant, but it works and it saves you retyping.