HorizonVale Holdings HorizonVale Holdings BV
A rack wall of unlit patch ports inside a Belgian systems integration workshop, lit from above by overhead strip lighting.

Delivery approach

From scoping call to a system you can run

We draw the cable between your systems. This page walks through how a HorizonVale project actually runs — scoping, architecture, build cycles, integration testing, data protection and the handover you keep.

Book a scoping call See the handover

Hybrid cloud and on-premises environments, Belgian enterprises. Written for the person who will run the thing, not for the pitch deck.

The written assessment you receive 1–3 weeks

Systems in scope

The exact list of applications, databases and services the first slice touches.

Data flows

Which direction data moves, on what trigger, at what frequency.

Options

At least two ways to build the slice, and what each one costs you later.

Rough effort

An honest range for the first release, not a fixed number printed before we read the data.

Risks

Named, with the failure mode we expect to see and how we would know.

Assumptions

Where we think we're right, written down so you can argue with it before we build.

Request an assessment If we're wrong about something, it's in writing where you can argue with it.

The decision that matters

Architecture before code

The architecture decision that matters most is where the business logic lives. Put too much in the integration platform and you're locked in; put too little there and you reimplement connectors forever. We draw the line explicitly and document why.

For hybrid environments, this stage also settles connectivity: which on-premises systems are exposed, through what gateway, with which credentials, and how secrets are managed. Getting that wrong is expensive later, so we spend time here even when it feels slow.

On-premises

Keeping the core

Systems you cannot move stay where they are. ERP, warehouse, and record stores keep their authority; nothing gets duplicated to satisfy a trend.

  • — Named owner per system
  • — Explicit interface list

Hybrid bond

The seam we argue over

Gateway, credentials, secret management and the exact firewall rules — the parts where hybrid goes wrong. Written down so we can revisit them.

  • — Credentials named
  • — Environment split

Cloud

Where logic earns its keep

Orchestration, process logic and the endpoints around it. The layer where the platform adds value without becoming the whole system.

  • — Portable by design
  • — Testable in isolation

The aim is not the shortest drawing. It is the one your team can still explain two years from now, when a new integration arrives and nobody remembers why a boundary was drawn where it was.

Two-week cycles

Build in short cycles

Two-week cycles, each ending with something you can look at. We work alongside your team rather than disappearing for three months, which means questions get answered while they're still cheap to answer.

Firewall rules

Requests raised by your network team, reviewed by ours, applied on a change window that is often weeks out. Start this on day one.

Not technical

Service accounts

The identity the integration runs under. It belongs to you, not to us — we're careful about who can do what with it.

Yours to hold

VPN and test access

Who on our side can reach which environment, on what basis, for how long. Revoked at handover.

Scoped and dated

Test data approval

Legal and privacy sign off on what leaves production for testing. Masked or synthetic by default; copies only by exception.

Signed, on file

We handle environment access early because it's the most common cause of delay on Belgian enterprise projects. None of these are technical problems we can solve for you — but they are problems we plan around, and we know how long they take.

Contract first

Testing an integration properly

Testing a connector is different from testing a screen. We test the contract: what happens when the field is empty, when the downstream system is down, when a message arrives twice, when the payload is twice the expected size.

Those cases are the ones that wake people up at night, so they get tests. Every flow runs in a pipeline. If a change breaks a data contract, you find out before it reaches production — and you find out from a red build rather than a support ticket.

A technician's hands fitting a small adapter into a patch bay on a brushed-steel rack wall.
Every flow runs in a pipeline. A broken data contract shows up as a red build, not as a call from the warehouse.
What runs before production

  • Contract tests on every API and message

    The shape of the payload is asserted on both sides of the wire, so a field rename or a type change fails before it ships.

  • Failure-path tests: timeouts, duplicates, malformed payloads

    The four cases that hurt in production. Each one is tested on purpose, and the expected behaviour is written down.

  • Monitoring and alerting configured before go-live, not after

    By the time the first real message flows, someone will already know if it fails — and what the failure means.

Which platforms we support Contract tests are the entry point, not the whole story.

Data protection, per flow

Data protection through the lifecycle

Personal data gets minimised at the boundary. If a downstream system needs to know that an order belongs to a customer, it usually doesn't need the customer's full record. We design flows to move references rather than copies wherever the business logic allows.

Minimisation at the boundary References instead of copies wherever the business logic allows it. By design

What we ask of the flow

Does the receiver need the person, or only their identifier? If it's the identifier, the record stays where it lives.

What you keep

One authoritative system holds the personal record. The rest of the chain works off a key that points back to it.

Where it stops

Some flows genuinely need the full record. In those cases we say so and design the retention around it.

Retention decided per flow Documented with you, not defaulted by the platform. With you

Where it's written

Every flow has a stated retention period in the runbook — the same document your operators will use at 2am.

Where it's enforced

Where the platform enforces retention, we configure it. Where it doesn't, we write the check that does.

What changes it

A new legal basis, a new downstream system, a new data category. We revisit retention when the flow changes, not on a yearly calendar.

Production data in testing Restricted, and where feasible replaced with masked or synthetic data. Masked

Default posture

Test environments carry masked or synthetic records. If we cannot mask a field, we say so before testing begins.

Exception handling

When a copy of production is unavoidable, access is time-boxed, logged, and revoked as soon as the test cycle ends.

Who can see it

Named engineers on our side, on the relevant project, for the relevant window. Not the whole team, not indefinitely.

Handover

Handover that means something

Handover is a set of artefacts, not a meeting. Documented connectors and data contracts, a runbook covering the failures we expect, credentials transferred to your vault, and a walkthrough with whoever will own it.

If you want your team shadowing ours during the last cycle, we build that in. We'll say it plainly: a handover nobody can follow is a future support contract. We'd rather it be readable.

What leaves with you

  • Documented connectors and data contracts

    Every interface, in the form a new engineer can read on day one.

  • A runbook for the failures we expect

    Timeouts, duplicates, credential rotation, downstream outages. Symptom and remedy, side by side.

  • Credentials moved to your vault

    The service accounts return to you, along with the record of what each one can reach.

  • A walkthrough with the new owner

    Usually two to three sessions. We only sign off when your team can run the thing without us.

After go-live

Running it afterwards

After go-live you can take it in-house, keep us on a support retainer, or ask us to keep building. There's no forced path. If we stay, it's for specific work: new integrations, platform upgrades, capacity issues, or the next slice of the process.

In-house

You take it over

The handover artefacts are designed for this outcome. Nothing in the stack quietly requires us to keep the wheels on — nothing depends on a private tool of ours.

Suits teams with a standing in-house engineering function.

Support retainer

We keep an eye on it

Support agreements specify response times and what's covered before anything is signed, so there are no surprises in month three. Retention and incident handling sit in the same document.

Request the terms before you decide — we'd rather you read them first.

Keep building

The next slice

New integrations, platform upgrades, capacity issues, or the next process in the same business chain. Same delivery shape as the first release — short cycles, live environments, real users.

For organisations that decided one slice was enough to want the next one.

Compare engagement models Ask about support terms

Planning for the usual

What tends to go wrong, and how we handle it

Three things reliably come up on enterprise projects. We plan for all three, so none of them turn into surprises at the wrong moment.

  1. Source data is worse than anyone thought

    Three versions of the same customer, a field that means two different things in two systems, an identifier nobody has cleaned since a merger. Data profiling happens in the first cycle so bad data surfaces early — while it is still a decision, not an emergency.

  2. A system owner is unavailable for two weeks

    A holiday, a migration, a reorganisation. We name a decision-maker on your side at scoping and write down who stands in for them, so the project does not stall on an out-of-office reply.

  3. The scope grows because a related process looks easy to add

    Scope additions go into a list with effort estimates rather than quietly into the current cycle. You see the cost of the addition — in effort, in risk, in the release date — before you say yes, no, or not yet.

None of these are glamorous. All three are the reason projects slip quietly, so on our side they get a name and a plan before the first build cycle closes.

Next step

Start with one narrow slice

A scoping call is thirty minutes. Bring the process that bothers you most and the systems it touches — we'll say early whether the first slice is worth building, and what it would take to get there.

HorizonVale Holdings BV — Leuvensebaan 184, 1930 Zaventem, Flemish Brabant. Weekdays 9:00 to 18:00.

Book a scoping call Contact the team See what we build