Skip to content
Back to overview

September 21, 2026

How we approach a new project

From first conversation to launch: how we structure scope, technology, and communication so a project doesn't produce surprises.

A project rarely goes wrong at the point of writing code. It goes wrong when scope was never really pinned down, when a technical decision was never explained, or when three weeks of silence pass between "we're starting" and "here's the first version." Our process is built to remove exactly those failure points.

1. Explore, don't assume

Before a single line of code gets written, we map out what the problem actually is — not the first solution someone had in mind. That means concrete questions: who uses this, how often, what happens if it goes down, and what's the minimum that counts as "done." Most scope disasters trace back to these questions never having been asked out loud.

2. Architecture fits the situation, not the other way around

We don't pick a technology because it's trending. An internal tool for ten users has different requirements than a client portal that spikes around deadlines. The architecture — monolith or services, which database, which hosting — follows from those requirements, and we explain why, in plain language.

3. Build in visible steps

We work in short sprints with intermediate, shippable results — not a black box until the deadline. That doesn't mean daily standups for a small project; it means you never wait three weeks to see whether things are headed in the right direction.

4. Testing isn't a separate phase

Code that "works on my machine" isn't finished work. Automated tests and an explicit CI/CD pipeline belong to the build phase, not a checklist tacked on afterward — so a release is a routine action, not a risk.

5. Launch is the beginning, not the end

Software that's never touched again after delivery ages fast: dependencies fall behind, requirements shift, and small bugs pile up. That's why we stay involved after launch — monitoring, maintenance, and iteration based on what actually happens in production, not on upfront assumptions.

This isn't a theoretical process — it's the same discipline applied to enterprise systems like billing platforms and Online Charging Systems, scaled down to fit a Dutch SME project.