Discovery sprint
Two to four weeks, one small team, a fixed fee, and a scoped backlog you can take to your own management. Also where we find out whether the project is worth doing at all — several engagements end here.
Fixed fee
Engagement Model
Brussels · Antwerp · Ghent · Liège
Brussels — engagement in four shapes
Four ways to work with Bluehaven
The engagement model is the part of a software project clients most often get wrong, and it is not really about contracts. It is about how much of the problem is already understood, who carries the risk of a wrong assumption, and how decisions get made when the requirements move.
Berths that hold, systems that ship.
Four working shapes
Four shapes, one question
Each shape answers a different question about how much is known and who should carry the risk of an unknown. Read the rows as a comparison of fit, then follow the one that matches your situation into its spot on the rail.
Fixed-scope project
For a bounded, stable requirement: you know the total, we carry the estimation risk, and change requests are handled through a written mechanism rather than a conversation.
Total fixed
Dedicated delivery squad
A squad of Bluehaven engineers working as an extension of your team, with a monthly cost and a rolling backlog. The most common shape for engagements that run beyond six months.
Monthly
Time-and-materials with a cap
Neither bounded enough for fixed-scope nor long enough for a standing squad. Work runs against an agreed ceiling with a checkpoint where both sides decide whether to continue.
Capped rate
A single discovery sprint costs less than the meetings an unclear scope generates.
Delivery sequence
From scoped backlog to running system
The engagement changes shape as the work moves. In a squad engagement the rhythm is planning, demo and review; in a fixed-scope build it is milestones and written changes; in every shape, an engagement includes the handover phase in the plan rather than as an afterthought.
The walk through
How the team is shaped
A typical squad is three to six people, and the same structure shrinks to two or three for a discovery sprint. We tell you who is on your project by name before the contract is signed, because "the team will be confirmed later" is how projects lose their best people to another client.
-
01
Discovery sprint — fixed fee
Scoping the berth before the ship
Two to four weeks, one small team, a fixed fee. The output is defined: a scoped backlog, an architecture sketch, an integration assessment, and a cost range you can take to your own management. It exists because buying software without it means pricing a guess. Discovery is also where we find out whether the project is worth doing at all, and we will say so if the answer is no. Several engagements end here, and that is a legitimate outcome rather than a failed sale.
Duration
2–4 weeks
Defined output: backlog, architecture sketch, integration assessment, cost range.
-
02
Fixed-scope project — total fixed
When the requirement already holds
Where the requirement is bounded and stable, fixed-scope pricing works well for both sides. You know the total, we carry the estimation risk, and change requests are handled through a written mechanism rather than a conversation. It suits replacing a defined workflow, building a connector between two known systems, or delivering a specific integration. It does not suit anything exploratory. If a vendor offers you fixed-scope pricing on a genuinely uncertain problem, they have either misunderstood it or priced in a large cushion.
Suits
Bounded work
Replacing a workflow, a known connector, one specific integration.
-
03
Dedicated delivery squad — monthly
A bench kept at your cadence
For ongoing development, a squad of Bluehaven engineers works as an extension of your team, with a monthly cost and a rolling backlog. You set priorities, we run the delivery, and there is a shared rhythm of planning, demo, and review. This model suits companies with a product roadmap that keeps moving, or an internal IT team that needs capacity rather than a one-off deliverable. It is the most common shape for engagements that run beyond six months.
Common for
Beyond 6 months
Rolling backlog, monthly cost, shared planning and demo rhythm.
-
04
Time-and-materials with a cap — capped rate
Flexible with an honest ceiling
Sometimes a project is neither bounded enough for fixed-scope nor long enough for a standing squad. In that case we work time-and-materials against an agreed ceiling, with a checkpoint at a defined point where both sides review and decide whether to continue. It keeps flexibility without an open-ended commitment, and it forces an honest conversation at the checkpoint rather than at the end of the budget.
Checkpoint
Agreed ceiling
Both sides review and decide whether to continue at a defined point.
-
05
Handover and what happens after — scoped in
A codebase someone else can run
Every engagement includes a handover phase in the plan, not as an afterthought. That means documentation produced during the work, a runbook for operations, and a period where your team shadows ours on deployments. Some clients take the system in-house at that point. Others keep a support arrangement, either for the whole system or for defined hours. Both are fine. What is not fine is an engagement that ends with a codebase nobody else can run, which is why the handover is scoped and priced from the beginning.
Includes
Runbook + shadowing
Runbook for operations plus a shadowing period on deployments.
Who decides what, and when
Priority on your side, technical approach on ours
Requirements change. The question is not whether that happens but how it is handled. In our engagements, the client owns priority: what gets built next and what waits. We own the technical approach and the estimate for any change.
Decisions that affect cost or timeline go through a written change note, short enough to read in two minutes, so there is a record without a bureaucracy. Weekly checkpoints keep the small decisions small. Escalation, if it is ever needed, goes to named people on both sides rather than to a support queue.
Choosing between them
If you are unsure, discovery comes first
The honest answer is usually the same: start with discovery regardless of which model looks like the final shape. It is small, it is bounded, and it produces the information needed to pick between fixed-scope and a squad. Clients who skip it and go straight to a large fixed-scope contract are the ones who end up renegotiating in month four.
A single discovery sprint costs less than the meetings an unclear scope generates — which is also why an engagement can change shape mid-flight. A fixed-scope project that reveals a larger problem can move into a squad model once discovery is complete; a squad engagement can narrow into a fixed-scope phase when the roadmap settles.
A working relationship
How the team is built
A typical squad is three to six people. That is a lead engineer, one or two developers, a tester where the quality bar justifies it, and a delivery lead who is your single point of contact. Specialists in data, cloud or security join for the phases that need them rather than sitting on the engagement full time — a bench kept at the shape of the work, not at a fixed headcount.
For discovery, the same structure shrinks to two or three people. We will tell you who is on your project by name before the contract is signed.
- On the client side
- Priority, business context, and a named contact who can say yes and no on scope and sequence.
- On the Bluehaven side
- Technical approach, estimation, delivery management, and the written change note for anything that moves cost or timeline.
Where an existing vendor relationship is difficult, we plan around it with adapters and documented interfaces rather than depending on their cooperation.
Practical questions
What clients ask before signing
Four questions that come up in most first conversations. If yours is not here, the fastest route is a short call — we will answer plainly, including when we are not the right partner.
Can we change the engagement model partway through?
Yes, and it happens often. A fixed-scope project that reveals a larger problem can move into a squad model once discovery is complete. A squad engagement can narrow into a fixed-scope phase when the roadmap settles. The change is handled at a checkpoint with a written note, not by renegotiating the whole agreement.
Who owns the code we pay for?
The client owns the deliverables. That is stated in the agreement before work starts, along with what happens to source, documentation, and infrastructure on handover. We do not treat client code as leverage in a renewal conversation.
Do you work with our existing vendors?
Frequently. Modernisation and integration work often sits between two systems from different suppliers, and we coordinate with them directly when that helps. Where a vendor relationship is difficult, we plan around it with adapters and documented interfaces rather than depending on their cooperation.
How are invoices handled?
Invoices are issued by bank transfer against agreed milestones for fixed-scope work, or monthly for squad and time-and-materials engagements. Payment terms and the milestone schedule are set out in the agreement. No work is invoiced before it has been demonstrated.
Next step
Pick the shape, then start small
Bluehaven Maritime Services BV works out of Brussels, with project teams across Belgium. If you already know the shape you need, the contact page carries the form; if you do not, discovery is the right first move and everything else follows from it.