When no connector exists, we engineer one
Custom integration engineering is what happens after the survey of off-the-shelf options comes back empty: the device speaks a proprietary protocol, the software's API was never documented, the vendor is out of business, or the combination you need has simply never been built. It removes the dead end — the point where every catalog and marketplace says no and the project stalls.
Willowark approaches these as investigations before builds. We instrument the boundary — packet captures, serial sniffing, API traffic through a proxy, database schema inspection — until the undocumented interface is documented, by us. Only then do we design the integration, because the biggest risk in custom work is building on an interface you only think you understand.
Systems IntegrationHow the work gets done
The same way every time: scope, build, hand over.
The engineering spans whatever the problem demands: custom protocol drivers written from captured traffic, wrappers around ancient vendor DLLs so their functionality is reachable from modern services, file-format parsers for proprietary binary outputs, and middleware that mediates between systems with incompatible models of the world. When the target is a legacy application that must eventually be replaced, we often apply a strangler-fig approach — routing traffic through a facade we control, so functionality migrates piece by piece while the old system keeps running. Everything we reverse-engineer gets written down as a specification, with test fixtures that pin the observed behavior.
Production-readiness is where custom work either pays off or haunts you, so we build in the unglamorous parts: defensive parsing that treats every input as hostile, logging rich enough to debug a failure from the record alone, version detection so a silent firmware update is caught rather than misinterpreted. Success is a connection that behaves like a product — documented, monitored, and maintainable by whoever comes after us.
The investigation phase ends with an integration map, not just a protocol note: every system involved, every interface we intend to use, the direction and volume of data at each, and who owns the component on either side. Where a vendor still exists but will not open their interface, we work at whatever they do document and keep a clear line between their responsibility and ours — the spec records what was observed, what was inferred, and what remains unknown. That honesty about boundaries matters more in custom work than anywhere else, because there is no product documentation to fall back on later.
Every custom interface is tested in isolation before anything depends on it: the driver against recorded traffic, the parser against a library of real files, the middleware against both systems in a staging environment. Deployment is phased — read-only first, then a single low-risk write path, then the full integration — with the previous arrangement left intact so rollback means switching off the new component. Where a strangler-fig migration is involved, each routed function is cut over separately and can be routed back. The handover package lists every connection, its interface specification, its monitoring, and the named owner on each side.
Scope it in writing
What we agree before work starts
- Interface investigation report documenting the reverse-engineered protocol or API
- Custom driver, parser, or middleware with source code and ownership transferred to you
Build with checkpoints
Working results, not slide decks
- Test suite pinning observed interface behavior
- Deployment with monitoring, logging, and version detection
Hand over something you own
Documentation, source, and training
- Maintenance documentation written for engineers who were not on the project
- Phased rollout plan with isolated interface testing and per-function rollback
Sound familiar?
Where custom integration engineering earns its keep.
A discontinued instrument whose binary data files are the only record of ten years of tests
Two acquired companies' homegrown systems that must share orders with no API on either side
A machine vendor's proprietary network protocol that has to feed a standard MES
A critical legacy application being retired gradually while dependent systems keep working
Ask about Custom Integration Engineering
Describe the problem. Get a straight answer.
One line is enough. An engineer replies within a business day.
Related work
Radar centering system for steel mills
Components:
- Radar sensors (strip position): Non-contact radar reading strip edge position in a hot, dusty, vibrating environment where optical sensors fail.
- Edge controller (signal processing): Turns raw radar returns into a clean lateral offset in real time.
- Mill PLC (centering actuators): The mill's existing controller: receives the offset and drives the centering actuators.
- Operator HMI (live position): Live strip position for the operator.
Connections:
- Radar sensors to Edge controller (raw returns)
- Edge controller to Mill PLC (offset)
- Edge controller to Operator HMI
A steel-mill systems provider · Steel manufacturing
Radar-based centering system for steel mills
End-to-end engineering of a radar sensing system that measures and centers material on steel mill lines — from equipment assessment through hardware selection, electrical engineering, software, installation, and commissioning.
Read the case study →Common questions
Asked before every custom integration engineering project.
Is reverse-engineering an interface legal for our situation?
Interoperability work on equipment and software you own is generally well-trodden ground, but license terms vary, and we review the relevant agreements with you before starting. Where a vendor is still reachable, asking for documentation is always step one — the friendly path is cheaper than the clever one.
How do you keep a custom integration from becoming an unmaintainable black box?
By treating documentation as a deliverable, not a courtesy: the reverse-engineered interface gets a written specification, the code gets tests that encode every observed behavior, and you receive the source with full ownership. The goal is that a competent engineer who has never met us can pick it up from the repository alone.
What if the target system changes after the integration is built?
We assume it will. Version detection and contract tests are built in so a change breaks loudly and specifically instead of corrupting data quietly. From there, we can update the integration under a support arrangement, or your team can, using the test suite as the safety net.
How do you estimate custom integration work when the interface is unknown?
In two stages. The investigation is scoped as a short, fixed engagement whose output is a written interface specification and an honest assessment of what is feasible, so the uncertainty is paid for once and bounded. The build is then estimated from that specification like any other software project. We would rather tell you after a couple of weeks that an interface is not worth pursuing than discover it halfway through a larger commitment.
Can you work within our own repositories and deployment process?
Yes, and we prefer it. Working in your repository, with your CI and your deployment tooling, means the integration is already where your engineers will look for it and there is no handover migration at the end. We follow your branching and review conventions, and where you do not have a process yet we set up a straightforward one and document it. The goal is that ownership transfers on the last day without a separate transfer project.
Where this sits
Custom Integration Engineering, inside a systems integration system.
The lit component is the part of the system this service delivers; the rest is what it has to work with.
Hover or focus a component to see what it is and what it talks to. Arrow keys move between them.
A legacy machine, an ERP, a vision cell and a quality database are joined by an integration layer so the data exists once and the people who need it see it.
Components:
- Legacy machine (serial): A 1998 controller with an RS-232 port and no documentation.
- ERP: Orders, inventory, costing.
- Vision cell: Inspection results per part.
- Integration layer (the seam): Translates, validates, and stores once. This is the work.
- Unified data: One record per part, per order, per event.
- People (dashboards, alerts): Production, quality and the office see the same numbers.
Connections:
- Legacy machine to Integration layer over serial
- ERP to Integration layer over REST, both directions
- Vision cell to Integration layer over REST
- Integration layer to Unified data over SQL
- Unified data to People over REST
Strategy. Software. Systems.
Have a system that should exist?
Tell us what your operation is doing manually, what isn't connected, or what you're trying to build. We'll tell you plainly whether and how we can help.
