How we build reliable software
Companies entrust us with their most important software. When the whole business depends on it, you want to know how we work and what you can expect. That has to be clear from the first conversation, and that is what our approach is built around.
Insight into scope, progress, and trade-offs
Quality assurance in code, tests, and releases
Clear agreements on ownership, hours, and handover
Why this matters
Trust comes from process and transparency
We see many organizations that have lost some trust in their software, or in the processes used to develop it. That does not mean they have come to a full stop. More often every change moves painfully slowly, it is unclear where the risks sit, or nobody can properly explain why certain decisions were made.
We work to rebuild that trust through direct contact, clear explanations of decisions, and visible progress. We maintain software quality through Glossary · In briefcode reviewA code review is an assessment of a code change by another developer. They check its behaviour, readability, and maintainability, among other things, before the change is merged.Read more, Glossary · In brieflintingLinting automatically checks source code for potential errors and violations of agreed coding rules, without running the application. The tool that performs these checks is called a linter.Read more, Glossary · In brieftype safetyType safety is the extent to which a programming language prevents values from being used in ways incompatible with their types. Checks can identify such errors during coding, compilation or execution.Read more, tests, and Glossary · In briefCI/CDCI/CD is a way of working in which teams frequently merge software changes, check them automatically and use a defined sequence of steps to prepare or deploy them to production.Read more.
Topics
The pillars of our working methods
We make sure requirements are properly structured, that uncertainties are made visible, and that the choices that follow from them stay discussable before a single line of code is written.
We also make clear right away what a project looks like, which roles you will meet, and how sprints, alignment moments, and budget management work in day-to-day practice.
How we check and monitor quality with linting, type safety, tests, CI/CD, release management, and monitoring.
We handle the financial side transparently. We account for hours, lock in intellectual property clearly, and preferably put infrastructure directly in the client's name.
We explain why time and materials is our default, how it differs from fixed fee, and how monthly planning works.
Those exist, but we do not make empty absolute promises. How we handle audit findings: clearly, with direct and honest communication.
Before building starts
Scope and estimation
We make sure requirements are properly structured, that uncertainties are made visible, and that the choices that follow from them stay discussable before a single line of code is written.
Our principles
Visibility into decisions and progress
Trust does not occur by accident, and neither does good software.
That is why we show our estimation process and how we weigh priorities from the start. Before a new version is released, the code has to pass several quality gates. We also give concrete detail on how we keep stability and security under control after go-live, and we spend real time explaining where uncertainty remains and what that means for planning, budget, and risk.
There is a core value in the collaboration itself too. You are in direct contact with the people who understand and build the system, you keep ownership of code and infrastructure, and you can easily track hours spent. That is what we believe in.
It is the first time I experience software development as simple, transparent, and measurable.
Viktor Mirovic
Owner at TasteIndex
What we especially appreciate is that 10KB dares to push back and takes responsibility.
Antoon Scheffers
IVBB
Communication is open and transparent, including on the technical side.
Roos Rietveld
Director at Planned Culture
The fast and clear communication via Slack works perfectly, and they deliver what they promise.
Stefan Kroesbergen
Owner at Getsby
What this gives you
Honest advice: you want to start from a shared picture. So before a project begins we map all questions, software states, risks, and objectives properly. We turn that into scenarios, including pros and cons.
Transparent communication: you talk directly with whoever builds your software, and that short line means less noise and faster alignment.
Predictable results: we make it visible whether choices turn out as you hope, and you follow the hours worked. That way you do not run into later surprises.
Flexible contracts: things can shift, so our starting point is monthly cancellation, and you can scale up or down without hassle.
Full ownership: we transfer copyrights to you by default. All infrastructure we set up securely, directly in your own organization's name.
Quality as a process: not a set of vague promises, but a seamless fit between our process, how we communicate, and solid technical work.
Our work
Our working methods in practice
Examples of projects where transparent collaboration, quality assurance, and clear decisions helped improve business-critical software.
Go to our cases
Frequently asked questions
Our working method is not something we tack on the side. It is the core of our service. Especially with business-critical software you need to understand upfront how a project is set up, how we keep things under control, and how the handover will work later.
Yes, absolutely. Depending on how large the project is, you get direct contact with a lead engineer, a project lead, and the engineers who work on your system in substance.
We work with fixed technical and process controls: linting, type safety, tests, reviews, CI/CD, environment validation, and monitoring. Every one of them is standard for us.
The principles are fixed. But how we fill them in exactly, such as team size, role split, sprint focus, or hosting setup, we align to your situation.
Because time and materials usually shows more clearly where time, risk, and trade-offs really sit in custom projects. We explain that in more detail on the page about time and materials.
Yes. A collaboration often starts with an inventory, a first improvement track, or a few targeted changes. That way you can experience how we work before the collaboration expands further.
Is your question not listed here?
Get in touch