Custom software that accelerates your processes

Off-the-shelf is the better choice as soon as your process looks like that of thousands of other companies: bookkeeping, email marketing, time tracking. Custom pays off when your way of working is the distinguishing part of your business, or when you currently glue three packages together with exports and manual checks. If you are unsure, there is a third route that wins most often in practice: hybrid. You buy what is commodity and have only the core built custom. In discovery we put those three options side by side with five-year costs, so the decision rests on numbers rather than preference.

Yes, and we recommend it more often than fully custom. Slack or Teams for communication, Stripe or Mollie for payments, your accounting package for invoices: those parts are cheap to buy and do not need reinventing. What we build custom is the layer in between that makes your process unique: the planning, the case structure, the calculation rules, the client portal. That core becomes your property, the surrounding systems stay subscriptions you can swap out. This keeps the investment limited to what genuinely has to be yours instead of recreating existing tools.

We only name a figure once we understand the problem. Discovery therefore produces not a single end price but a breakdown: per module, per integration, per user role, with the assumptions attached. You see which parts drive the investment and can move things around before a line of code exists. Scope often halves that way, because two of five modules can wait for phase two. For a first range, use the calculator at /calculator. Also budget for ongoing hosting, monitoring and maintenance; we put those in the same breakdown so the total picture stays honest.

We work with fixed sprint budgets and flexible scope rather than one fixed total price on a specification nobody can fully foresee. Per two-week sprint the budget is fixed; what goes into it you decide with us based on the priority list from discovery. If a feature turns out to matter less after a demo, that budget moves to something with more return. This avoids the two classic outcomes of a fixed price: change-request arguments or quiet cuts in quality. You can stop after any sprint, and what has been built until then works and is yours.

A subscription looks cheap at five users and becomes a fixed burden at fifty. Per-user prices rise, the module you need sits in a more expensive tier, and after three years you keep paying without owning anything. Custom costs more upfront and then produces an asset: an application that belongs on your balance sheet, that you can extend, include in an acquisition or hand to another team. In the projects we run, the tipping point usually sits between year three and year five depending on user growth. In discovery we calculate that through with your own licence costs included.

Mostly logistics and transport (planning, trip registration, carrier integrations), healthcare (records and processes where GDPR and data minimisation shape the design), legal and financial services (where every action must be traceable through audit trails and roles) and e-commerce (stock, order flows, marketplaces). What those sectors share is not the technology but the detail: a gap in the business logic shows up immediately in daily operations. That is why discovery spends relatively much time on your exceptions, because they decide whether software actually gets used or whether a spreadsheet keeps living next to it.

Yes, and that starts with reading rather than building. We first map the existing architecture, data models and dependencies and work out which assumptions the previous builders made. A module bolted onto the side works for six months and then produces duplicate truths in the database. So we follow existing patterns where they are sound, and isolate cleanly where they are not. You hear upfront what we find, including the parts we would leave alone. When the intervention is larger, it runs through our software redevelopment approach instead.

Within a running sprint we keep scope stable, because switching halfway produces exactly the defects you later see as bugs. New insights land on the priority list and go into the next sprint, unless something is blocking: then we swap it for work of similar size. With every change you get the same two numbers, impact on timeline and impact on budget, before anything is decided. Because you see a working version every two weeks, those insights usually arrive early enough to be cheap. Changing requirements are not the problem; requirements that surface at delivery are.

That is the normal situation for us. You are the expert in your process, we are in the technology, and discovery exists to line up those two languages. Instead of architecture diagrams you get clickable designs and a working version every two weeks where you can check yourself whether an order behaves correctly. Decisions are presented as choices with consequences, not as technical options. Delivery includes documentation and hands-on onboarding: a short walkthrough for an internal tool, several sessions per role for a larger platform. The aim is that your team can carry on without us in daily use.

More important than who administers the repository is what you are left with. Custom software is a business asset: it is in your name, you set the roadmap, you can have it developed further by whoever you want, and it carries value in an acquisition or funding round. So we set everything up on your own accounts and organisation, with us as developer holding access you can revoke. Delivery includes not just the code but what is needed to understand it: documentation, decision notes and a handover document. If you stay with us, it is because it works, not because leaving is expensive.

Yes, and usually that is the part that pays back fastest. A custom application sitting beside your packages means double entry; one that hangs off them pulls data from where it already exists. Which systems we encounter and how we connect them is on /software-koppelingen, with per-system guides on /api-koppelingen. In discovery we settle three things per integration: which side is authoritative for which field, how often data must synchronise, and what happens when the other system is temporarily unavailable. Those three answers prevent most of the trouble integrations normally cause.

Three phases. Discovery: we map process, goals, risks and exceptions and deliver scope with a breakdown and priorities. Design: clickable designs for the key screens, so flow discussions happen on drawings instead of in code. Sprints: every two weeks we build, test and deliver to an environment you log into yourself. That last part is the difference clients mention most: you assess the software itself with your own data in it, not a progress presentation. Whatever does not work you see within two weeks instead of at delivery. At the end come migration, onboarding and a decision about maintenance.

That depends less on our build pace than on how much existing reality we have to unpick first. Discovery takes one to two weeks, mapping the current process, the exceptions to it and the data sitting in other systems. After that a well-scoped internal application or portal often goes live within three months, while a platform with multiple modules, roles and integrations runs to four to seven months. The biggest variable then sits on your side: who decides, who tests, and how quickly you can get access or an export out of another system. We put those dependencies on paper upfront with a name and a date attached, so a plan is not wishful thinking.