Way of working · Sprint-based

Our process.

From the first introduction to live software and ongoing maintenance. No six-month waterfall method without a demo, and no vague 'agile' talk; instead, short sprints with real deliverables, open communication, shared access from day one and code ownership for your organisation. On this page we explain the seven phases, what we pay particular attention to and what we deliberately do not do.

TypeSprint-based project
First callFree & non-binding
Sprint cadenceShort & iterative
DemoEvery sprint
CodeIn your repo
Lock-inNone

Client-focused, honest about what works.

We work in short sprints with a fixed rhythm of planning, building, demo and retrospective. Every sprint delivers something that works: no surprise launch after half a year of silence, and no 200-page report without any code. We put your goals first and tell you straight if an approach won't work or a feature isn't worth the effort. That is where the value of a senior team lies: you get people who dare to think along with you, not just carry out instructions.

From day one, you have access to the repository, the project board and the design files. We are vendor-independent: no reseller deals with platform providers, and no disguised lock-in through a proprietary platform that only we can operate. What we build belongs to you. If you want to continue with a different team tomorrow, you can do so without a migration headache. That attitude runs through every phase: in the choice of stack, in how we document, and in which dependencies we do or don't bring in.

What you won't get from us: secondments with juniors learning on your budget, no-code wonder promises for situations where no-code is not the answer, or upfront time and price guarantees without us knowing the context. What you will get is a senior team that takes responsibility for what goes live, with an ongoing security baseline and compliance as a standard layer under every project, not as an extra line item on the invoice afterwards.

The page below walks you through all seven phases: from a no-obligation introductory conversation, through discovery and design, to building in sprints, testing and the pilot, the rollout and the ongoing management afterwards. We then explain what sets us apart, what we deliberately don't do, which tools we work with, and how we handle compliance and confidentiality. If, after reading, you have questions that aren't covered in the FAQ, the easiest way to reach us is a short introductory call: no intermediate step, no sales layer.

7
Phases: from introduction to ongoing development
Sprint-based
A fixed rhythm of planning, demo and retro
Senior
No learning-on-your-budget with juniors
Your own repo
Code ownership stays with you, no lock-in

The first four phases.

01
Phase 1 — Introduction

A conversation with no obligation

A short first call, free and non-binding, at an unhurried pace. You tell us about the challenge and we ask questions to properly understand the context. No sales pressure, no quote form, no sales tricks. Together we establish whether there is a fit in terms of sector, complexity and approach. If it doesn't click, we will say so honestly and, where possible, point you in the right direction. The next step is a discovery project, or no step at all.

02
Phase 2 — Discovery

Workshop, pain points and scoping

A workshop with your team to get clarity on pain points, business goals and stakeholders. We map the technical, data and IT landscape and, where useful, speak with end users or the service desk. This is followed by MoSCoW prioritisation, in which must, should, could and won't items are explicitly recorded. The result: a scope document, a target architecture and an honest quote with assumptions per phase.

03
Phase 3 — Design

From wireframe to architecture

UX research, wireframes and interactive Figma prototypes: you review and steer before a single line of production code is written. In parallel we work on the technical architecture: services, data models, integration patterns and a security baseline. The compliance overlay (GDPR, sector-specific where needed) runs through this from the start, not as a separate step at the end. The result: design files and an architecture document.

04
Phase 4 — Build

Short sprints with demo and review

We build in short sprints with sprint planning, sprint review and retrospective at fixed moments. Every sprint includes a demo of working software in your own repository, with no waiting for the final delivery. Pair programming and code review are standard, with test-driven development where it makes sense. Communication runs via Slack or Teams with a weekly stand-up; questions are answered quickly and decisions are recorded openly.

Testing, rollout and ongoing development.

Phase 05

Testing & pilot

A test suite of unit, integration and end-to-end tests that evolves alongside the code, rather than being a separate step at the end. Performance measurement with Lighthouse, k6 or JMeter, and security scans via SAST, DAST and dependency checks built into the pipeline. First a beta with your own team, then a pilot with a group of end users, and a bug-fix loop for the issues that only surface in real-world use. The result: production-ready software with a candid overview of what has and hasn't been tested.

Phase 06

Rollout & go-live

A rollout plan suited to your situation, whether big-bang or phased, depending on risk and your organisation. Data migration where needed, training for your team, a roll-back plan worked out in advance and clear responsibilities during go-live. We stand by during the first hours and days live, with a direct line to the people who wrote the code. You won't go live alone: we remain on standby until the system runs stably and operations can be handed over to your team.

Phase 07

Maintenance & further development

Optional managed services with a bug-fix SLA, 24/7 monitoring where required, and alerting through your own channels. For ongoing development, a fixed feature velocity per sprint, monthly reviews with your stakeholders, and always the option of a phased handover to your own team. No contract lock-in and no mandatory minimum monthly commitment: you pay for what you use and can scale up or down whenever the business requires it.

What sets us apart, and what we don't do.

An honest overview of where our value lies and where other parties are a better fit. We aren't the right partner for everyone, and we're upfront about that from the outset so you don't lose time to a mismatch.

Vendor-independent

No reseller deals with Mendix, OutSystems or SAP. We recommend what fits, not what earns us a commission; the choice of platform or stack is your decision, with our reasoning alongside it.

Code ownership

All code in your own GitHub or GitLab from the very first commit. No black box, no exit fee if you choose to leave, and no hidden licences on 'proprietary frameworks'.

Senior team

We don't send a junior along to learn on your budget. The people you meet during the introduction are the ones who actually build the system with you.

Pragmatic

Working software over thick reports. We write documentation where it helps, for onboarding, security reviews or handover, rather than to fill hours.

Not advice only

We build as well. A report without working code isn't a deliverable in our book; pure strategy consultancy is a different discipline, and other firms are better at it.

Not light secondment

We are a development team, not a staffing agency. Don't expect a junior wandering around with your badge and sending you a monthly timesheet without context or direction.

Not a no-code miracle

No-code has its place for simple internal tools. It isn't the answer for a complex domain with integrations, strict security requirements or large user numbers.

No blind timeline promises

We don't give hard week or month guarantees without understanding the context. First a discovery phase, then an honest plan per phase with assumptions we state openly.

Communication, tools and guarantees.

Communication

Slack, Teams and a weekly stand-up

Daily contact via Slack or Teams: no ticketing system for simple questions, and no email chain for decisions that can be made in five minutes. One fifteen-minute weekly stand-up and a sprint review with a demo at the end of every sprint. The backlog is visible to everyone in Jira or Linear, and decisions are recorded openly so that colleagues who join later can follow what was chosen and why.

Tools and access

Code in your repo, design in your Figma

GitHub or GitLab with your organisation as the owner of the repository. Figma with your team as editors, not just viewers. Sentry or Datadog for monitoring and alerting through your own channels. You have access to everything from day one: no detour via us, no queue for a password reset. We work in your environment, not the other way round.

Compliance

GDPR, NEN 7510 and ISO 27001 practices

We work in line with the GDPR and, where relevant to the sector, NEN 7510 or ISO 27001 practices, with attention to data classification, access control and logging from the first sprint. Penetration testing on critical components, client audit rights written into the contract, and dependency scans as a fixed part of the CI pipeline. For us, compliance is a design layer, not an audit exercise after the fact.

Frequently asked questions.

How long does a typical project take?
That depends heavily on scope, integrations and the level of compliance required. A first working version can be in place after a few sprints; a full enterprise project runs over several sprints followed by ongoing development. After the discovery phase we give you an honest plan for each phase, not before. We deliberately avoid promising a timeline before we understand the context, as in our experience that tends to lead to disappointment rather than a healthy project.
What determines the cost?
Scope, complexity, the number of integrations, security requirements and sprint cadence together determine the budget. We work with a fixed sprint budget so you can steer from sprint to sprint: smaller if the business needs it, larger ahead of a go-live. After the discovery phase you receive a concrete quote with scope and assumptions for each phase. No open-ended commitments, no surprises along the way and no hidden extra-work tricks.
Which tools do you use?
Slack or Teams for day-to-day contact, Jira or Linear for the backlog, GitHub or GitLab for code, Figma for design and Sentry or Datadog for monitoring. The application stack itself depends on the project, often TypeScript with Node or Python, and PostgreSQL or a similar database. We never steer you towards a specific platform vendor for commercial reasons; we choose what fits your context and team.
Will we own the code?
Yes, always. The code lives in your own GitHub or GitLab organisation, and you own it from the first commit. We don't build on a platform that only we can access: no lock-in, no exit fee, no disguised licensing structure. If you want to continue with a different team after handover, that can happen without a migration headache; all documentation lives in the repository, not in our heads.
Can you work alongside our in-house team?
Yes, and we often do. Pair programming, shared code reviews, joint sprint planning and a phased handover to your own team are standard parts of many projects. We're not afraid of making ourselves redundant; in fact, a successful project often ends with a team on your side that can carry on independently. We adapt to your situation anywhere between those two extremes.
What about confidentiality and data?
We sign an NDA as standard before the discovery phase begins. Employees and freelancers work under a confidentiality clause that continues beyond the project. Client data stays in your environment: we only get access to what is strictly necessary and only for the duration of the project. In sensitive sectors (healthcare, finance, government) we work with separate test data, masked production copies or synthetic datasets.
How do we get started?
The easiest route is an introductory call: half an hour, free, no obligation. We listen to the challenge and decide together whether a discovery project makes sense. Book a conversation via the contact form or email Fabian directly. You'll get a reply within one working day, and if we turn out not to be the right partner, we'll say so too.

Talk to us about your project.

A half-hour introductory conversation in which we go through where you are now, what you want to achieve and whether our approach suits your situation. No sales pitch, no obligation, no pre-cooked proposal, just an honest conversation in which we take the time to understand your context. If it's a good fit, we'll look together at a discovery project; if not, we'll say so and help you on your way.

Response within 1 working day
No-obligation conversation
Westerdoksdijk 599, Amsterdam

Edit content