Skip to content
willowark

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.

Illustrative: a plant floor dashboard on a wall-mounted TV beside production equipmentSystems Integration

How 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.

  1. 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
  2. Build with checkpoints

    Working results, not slide decks

    • Test suite pinning observed interface behavior
    • Deployment with monitoring, logging, and version detection
  3. 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

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.

Four systems behaving as oneserialRESTRESTSQLRESTLegacy machineserialERPVision cellIntegration layerthe seamUnified dataPeopledashboards, alerts

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:

  1. Legacy machine (serial): A 1998 controller with an RS-232 port and no documentation.
  2. ERP: Orders, inventory, costing.
  3. Vision cell: Inspection results per part.
  4. Integration layer (the seam): Translates, validates, and stores once. This is the work.
  5. Unified data: One record per part, per order, per event.
  6. 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
A typical architecture, drawn to explain the pattern — not a specific client's system.

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.