Building does not stop at delivery.
Most companies spend around seventy per cent of their IT budget keeping what they already have running, and thirty per cent on something new. That is not a law of nature. It is the result of years of putting out fires with nobody having time to set anything straight.
We put a fixed team on it with fixed hours per sprint. Something goes live every two weeks, and there is room left to keep the underlying work in order. That tips the ratio back, instead of it getting worse every year.
What is fixed and what you decide.
The rhythm is fixed so you can count on it. What gets built is not, because that is up to you.
-
The same people, every sprint
Not a pool someone gets pulled from because they happen to be free. Fixed developers who know your code, know why something was built the way it was and which integration breaks first. That saves half a day of reading on every change.
-
Fixed hours per sprint
You know in advance how much gets built every two weeks and what it costs. No surprise afterwards, no argument about an hour more or less, and no month where suddenly nobody turned out to be available.
-
A fixed release day
Something goes live every two weeks, on a day you know in advance. That lets you prepare your own people and means nobody has to watch along on a Friday evening.
-
You set the order
At the start of every sprint you choose what comes first. What was at the top last month may drop off, without a discussion about what was once agreed.
Why we do not work with prepaid hours.
A card of hours bought up front sounds flexible, and on paper it is. In practice it works against you, in four ways.
-
You start counting instead of building
Every wish begins with the question of how many hours are left. That leads to postponing things that really should happen, and to small jobs that just fit the remainder instead of the job you actually need.
-
You get whoever is free
Because no capacity is reserved, whoever has room picks it up. They read in, make the change and forget it again. Next time that reading starts over, and you are paying for it.
-
Maintenance never happens
Nobody wants to spend ten of their bought hours on updates they cannot see. So it gets left. Spend less than a fifth of your time on the underlying work and your maintenance costs climb fifteen to twenty per cent every year.
-
There is no plan, only a balance
Prepaid hours have no direction. There is no moment where someone says where this should be in six months, because there is only a balance running down. So we work with a fixed rhythm and a list we keep together.
What a month with us looks like.
Two sprints of two weeks, with a fixed day on which something goes live. You do not have to organise anything for it.
Book a call-
We choose together what goes in
Half an hour at the table or over a call. We run through the list, you say what comes first and we say what has to happen technically first. After that everyone knows what will be there in two weeks.
-
Building, with room for the underlying work
Around a fifth of every sprint goes to updates, tests and clearing up things that get expensive later. That is not up for discussion, because it is exactly the part that gets cut everywhere else.
-
Release day
What is finished goes live, on a fixed day and outside the busy hours. You get a list of what changed in plain language, so you can forward it to the people who work with it.
-
When something breaks
Then it goes first. An outage does not wait for the next sprint. We tell you what we are doing, fix it and push everything else along one place, rather than pretending the rhythm matters more than your business.
Platforms we have been building on for years.
Software that was not delivered and let go, but got a little better every fortnight.
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.
Helped us extremely fast and understood right away what was needed. I know who I am calling next time.
Questions about continuous development.
Not answered here? Just ask. You get someone from the team that would build it.
Ask your questionWhat does it cost per month?
It depends on how many hours per sprint you take. Most companies sit between fifteen and twenty-five per cent of what the build cost, counted per year. You choose the number of hours and can adjust it every quarter, up or down.
Are we tied into a long contract?
No. We work per quarter, with a month's notice. If you want to stop we hand everything over: code, servers, documentation and whatever was still on the list. We would rather you stay because it works than because you are stuck.
What if we need nothing for a month?
Then we use those hours on the underlying work: updates, tests, speed, security. Work you cannot see but that you get back later in changes that become cheaper. Hours genuinely left over roll into the next sprint.
Can you maintain software you did not build?
Yes, we often do. We read in first and then say what we find. With something ten years old and badly behind we usually start with a code scan, so you know what you are getting into before you start paying monthly.
Who decides what gets built?
You do, at the start of every sprint. We think out loud and say when something has to happen technically first, for instance because otherwise it has to be built twice. But the order is yours and it may change every fortnight.
How fast do you respond to an outage?
An outage takes priority over everything in the sprint. If you want hard response times in writing, with availability outside office hours, that calls for an SLA. We can agree that separately alongside the development.
Do we speak to the developers themselves?
Yes. There is no project manager in between passing things on internally. You are in contact with the people building it, and in practice that removes most of the misunderstanding.
What happens if you stop?
Everything is in your name and written down so another party can take it over. That is not us being casual: we add to the documentation every sprint precisely so you do not become dependent on us.