Systems that were never meant to be reached
Software from 2009 with no interface, still running the business. I put a documented layer in front of it and leave the original untouched.
IT consulting · APIs & systems integration
Two systems. One conversation that has to work every time.
I build the interfaces between software: opening up systems that were never meant to be reached, handling incoming events properly, and giving your clients somewhere to look things up themselves.
Where I concentrate
Three problems I keep being called about
Plenty of people can call an API that behaves. These three are the situations where that stops being enough — and where most projects quietly go wrong.
Events that arrive once, twice, or never
Webhooks look simple until a sender retries, duplicates or goes quiet. Validation, deduplication and a queue that survives a restart.
Clients who email to ask what they could look up
A private area reading live from the systems you already run — orders, documents, status — with an audit trail of who saw what.
In detail
What the work actually involves
Three sections, one per problem. If you recognise the situation described, the rest of the page will make sense; if you do not, you are probably better served by someone else, and I would rather you found that out here than after a call.
01 — Legacy access
Reaching a system that was built before anyone thought you would need to
Most companies have one: the software that runs a critical part of the business, was installed years ago, and offers no way in. The vendor has moved on, the original developer is gone, and the documentation is a PDF somebody scanned.
The instinct is to replace it. That is usually the wrong call — it works, people know it, and a migration costs ten times what the problem does. The alternative is to build a layer in front of it that speaks a modern interface on the outside and talks to the old system on its own terms underneath.
How that layer reaches the system depends on what it exposes. A reachable database is the easy case. Failing that, a scheduled file export, a report it can print, or in the worst case a controlled screen interaction. Each has different limits and I will tell you which one applies before you commit to anything.
The original system is never modified. Nothing is patched, no files are
replaced, no database schema is altered. If your vendor inspects it, they
find it exactly as they left it — which matters on the day you need their
support.
What you receive
- A documented interface, with a reference your own developers can follow
- The mapping between old fields and new ones, agreed before building
- Rate limits and safeguards so the old system is not overwhelmed
- A test environment, so nobody experiments on live data
The layer sits between. Nothing below it changes.
02 — Event infrastructure
Receiving events from someone else's system, reliably
A webhook looks like the simplest thing in the world: they post, you receive, done. It stays simple until the sender retries a message you already handled, or fires three at once, or goes quiet for an hour and then delivers everything at the same moment.
By then the damage is quiet and cumulative. Duplicate orders, a customer charged twice, a stock figure that drifted three weeks ago and nobody knows when. The failure mode of a badly built webhook endpoint is not a crash — it is silence, followed by a discrepancy somebody finds later.
Doing it properly means verifying the signature before trusting anything, recognising an event you have already processed, queueing so a restart does not lose what was in flight, and retrying with backoff rather than hammering a service that is already struggling.
The measure of a good endpoint is not that it never fails. It is that when
it does, you find out the same hour and you can see exactly which message
was refused and why.
What you receive
- Signature verification and payload validation on every request
- Deduplication, so the same event is never processed twice
- A queue that survives a restart, with retry and backoff
- A readable log of what arrived, what was accepted, what was refused
Four states, and the retry loop most builds omit.
03 — Customer portals
Giving clients somewhere to look instead of somewhere to ask
A large share of the email a small company receives is people asking for something the company already knows: where is my order, can you resend the invoice, what did we agree in March. Every one of those costs somebody ten minutes and arrives at an inconvenient moment.
A portal answers them without anyone being involved. The hard part is not the login page — it is that the portal must read from the systems you already run, live, rather than becoming a second copy of your data that drifts out of step within a month.
Which means the interesting work is underneath: permissions per account so nobody sees another client's documents, an audit trail of who opened what, and a design that degrades sensibly when one of the underlying systems is briefly unavailable.
No second database. The portal holds accounts and permissions, and nothing
else. Every figure it shows is read from the system that owns it, at the
moment it is shown.
What you receive
- Accounts, roles and password recovery, built properly rather than bolted on
- Live reads from your existing systems, with no duplicated data
- Per-account document permissions and a full audit trail
- A layout you can restyle without touching the logic underneath
The change is in who does the looking.
Engagements
Six ways I am usually brought in
Each one is scoped after a conversation, in a written proposal that fixes the scope, the price and the date before anything begins. Delivered first, invoiced afterwards. No deposit.
Legacy system access layer
An old system with no usable interface, made reachable by modern tools — without touching the system itself.
- Read and write access exposed as a documented interface
- The original system left untouched and unpatched
- Field mapping and data types agreed before we build
- Runs alongside the existing software, not instead of it
From€1,800
Request a proposal
Webhook infrastructure
Receiving events properly: validated, retried, deduplicated and logged, so nothing disappears when a sender has a bad afternoon.
- Signature verification and payload validation
- Retry with backoff, and a queue that survives a restart
- Duplicate events detected rather than processed twice
- Readable log of what arrived, and what was refused
From€900
Request a proposal
Customer portal
A private area where your clients see their own orders, documents and status — instead of emailing you to ask.
- Accounts, roles and password recovery done properly
- Reads live from your existing systems, no second database
- Document access with per-account permissions
- Audit trail of who saw and downloaded what
From€2,400
Request a proposal
API design and build
Your customers or suppliers are asking for an interface. We design one that will still make sense in three years.
- Endpoint design, naming and versioning strategy
- Authentication, scopes and rate limiting
- Reference documentation your integrators can follow
- Sandbox environment for the people consuming it
From€1,600
Request a proposal
API version migration
A supplier is retiring the version you depend on and has given you a date. We move you across before it arrives.
- Inventory of every call your systems make today
- Difference report between the old and new version
- Migration on a copy first, with a rollback path
- Cutover planned around your quiet hours
From€1,200
Request a proposal
Technical second opinion
You have a proposal, an architecture or a supplier estimate in front of you, and nobody in-house who can judge it.
- Written review of the approach and its assumptions
- What it will cost you later if it goes ahead unchanged
- Alternatives, where a workable one exists
- Questions to put to the supplier before you sign
From€450
Request a proposal
Entry prices. All prices include VAT. The firm figure is the one in the written proposal, prepared once I understand the work. Nothing is invoiced before delivery.
Fixed price
Five smaller pieces of work
Not everything needs a project. These five are scoped tightly enough to quote at a fixed price, and each is the small version of something larger — a way to find out whether we work well together before committing to anything.
API connection check
Send us your credentials or documentation. You get back a written report on what works, what is slow, and what will bite you later.
- Every endpoint you rely on, called and timed
- Error codes and rate limits observed, not assumed
- Authentication and exposure reviewed
- Ranked list of what to fix first
€90
Request this
Written advice on one question
One decision, answered in writing: which approach to take, whether an estimate is reasonable, or why something keeps failing.
- You send the context, systems and constraints
- A reasoned answer, not a verdict
- The alternative, where a workable one exists
- No call to schedule and no sales pitch attached
€140
Request this
Webhook monitor
Attaches to a webhook you already have and tells you when deliveries fail or stop arriving — instead of you finding out from a customer.
- Delivery and failure tracking on an existing endpoint
- Alert by email or to your chat tool
- Readable history of recent events
- Fits an endpoint whoever built it
€120
Request this
Legacy export tool
Gets your data out of a system that has no proper export, in a format you can actually open and check.
- Extraction from database, file store or screen output
- Clean CSV or JSON with the structure documented
- Row counts reconciled against the source
- Repeatable, so you can run it again next month
€149
Request this
Customer portal starter
A working login area with accounts, document access and a client overview — the foundation, ready to build your own case on.
- Accounts, roles and password recovery already wired
- Document access with per-account permissions
- Layout you can restyle without touching the logic
- Notes on connecting it to your own systems
€249
Request this
Fixed prices. All prices include VAT. These are supplied within a written proposal rather than sold at a checkout: you confirm the scope in writing, the work is delivered by email, and the invoice follows. Nothing is paid before it has been received.
How this works
Four steps, and you can stop after any of them
Nothing is invoiced until it has been delivered and you have looked at it. That is the whole arrangement, and it is why the steps run in this order.
01
A conversation
Twenty minutes on which systems are involved, what has to happen between them, and what breaks today. No charge, no commitment.
02
A written proposal
Scope, price, delivery date and exclusions on one document, valid thirty days. Anything not on it is not billed without a new one.
03
Access and build
You hand over credentials and a test data set. The clock starts there, not at signature. I build, test against your data and put it in service.
04
Delivery, then invoice
Code, configuration, documentation and rights hand over. The invoice follows delivery, payable within fourteen days. Fifteen days to raise anything.
FAQ
The questions people actually ask
What does an engagement cost?
It depends on the systems and the state they are in. Putting a layer in front of a documented database is nothing like reverse-engineering a system whose author left in 2014, and no honest number exists before someone has looked.
So every request gets a free written proposal fixing the scope, the price and the date before anything begins. The entry prices on this page give you the order of magnitude; the proposal gives you the figure.
The five fixed-price items are the exception: those are scoped tightly enough to quote without looking.
When do I pay?
After delivery. No deposit, no advance, no staged payments. The invoice is issued once the work is in service and is payable within fourteen days, whatever the amount.
That applies to the fixed-price items too. There is no checkout on this site and no payment is taken through it.
It is a deliberate arrangement rather than a courtesy: it means the most common thing that goes wrong in this trade — paying for something that never arrives — cannot happen to you here.
Why is the company registered in Hong Kong?
That is where the company is incorporated. The registration number, the registered office and the date of incorporation are all published in the legal notice, and invoices are issued in euros.
For you it changes little in practice: European consumer law still applies if you are buying as a private individual, and the contract says so explicitly rather than trying to sign it away. Where your rights are concerned, the Privacy Policy sets out which rules apply and why.
Can you work with a system that has no API?
Usually, yes — that is a large part of what I do. A system with a database, a file export or even a printable report can be reached without modifying it.
What I will not do is patch or alter the original system. Anything that changes it becomes your vendor's problem the moment they see it, and that is a bad place to leave you.
What happens when the other side changes their interface?
Publishers change their interfaces and no supplier can promise otherwise. What can be done is to build so that a failure is loud rather than silent: everything I deliver logs its runs and alerts on the first failure.
Faults against the agreed scope are corrected free of charge for fifteen days after delivery. Adapting to a change a publisher makes later is separate work, quoted separately. Nothing renews automatically and there is no retainer to cancel.
Who owns what you build?
You do, once the invoice is paid — together with the documentation another developer would need to take it over. Holding a client's systems hostage is a business model, just not this one.
I keep ownership of my own pre-existing components and libraries, and you get a free, perpetual licence to use them as part of what is delivered.
What happens to our credentials?
Identifiers and keys are held in an encrypted secrets manager, separate from anything else, and deleted when the engagement ends.
Where the work involves personal data belonging to your customers, you remain the controller and I act as processor: a data processing agreement is signed before anything moves.
Do you resell the software you connect?
No. No reseller agreement with any publisher, and no commission from one. Your subscriptions stay contracted directly between you and them.
That matters when you ask which tool to use: there is nothing on my side pushing the answer one way.
Am I dealing with one person or a team?
One person, from the first call to delivery. Nothing is passed to a colleague halfway through and nothing is subcontracted without telling you.
The trade-off is honest: work I cannot deliver within the time I quoted gets declined rather than accepted and delayed.
Start here
Tell me what has to talk to what
Which systems, what has to move between them, and what happens today when it fails. That is enough for me to say whether it is feasible, how long it takes and what it costs. I reply within two working days.