Custom integrations and tool development
The connective tissue: systems that should talk to each other and do not, and tools that do not exist yet. Templates, exporters, webhooks, two-way alerting, database work and the small custom tools that remove a manual process entirely.
What you get
This is the connective tissue work: the things that should talk to each other and do not,
and the tools that do not exist yet.
- Templates and exporters for devices, APIs and applications that
nothing off the shelf covers.
- Alerting in both directions - SMS, voice and webhook delivery out,
and acknowledgement coming back in, so people can act from their phone.
- Integrations between monitoring and the systems you already run: ticketing, chat,
on-call rotas, inventory, billing.
- Custom tools where a manual process has outgrown a spreadsheet.
Usually small, usually the highest return per day of work.
- Database and platform work, including MySQL to PostgreSQL with
TimescaleDB - audited, rehearsed on a copy with measured timings, and verified so
history and trends survive.
- MCP and AI integrations over your monitoring data, where that genuinely earns its
place rather than being a demo.
- Source, documentation and the reasoning, handed over. No black boxes.
The honest filter: if an integration already exists and works, I will point you at it
rather than rebuild it. What I am useful for is the case where it does not exist, or
where the one that exists does the wrong thing.
How it works
- Describe the gap
What the two systems are, what needs to pass between them, and what someone is
currently doing by hand to bridge it.
- Fixed scope, fixed price
A written scope before any work starts. Integration work goes wrong when nobody
wrote down what "done" means.
- Build against real data
Temporary access to the systems involved, so it is tested against what you actually
have rather than against documentation.
- Deliver and hand over
Working code, deployed, documented, with the source yours. One revision round after
you have run it.
What it costs
No price list here, because the same sentence can describe a two-hour job and a two-week
one. A webhook into a documented API is not the same work as an exporter for a device that
answers in undocumented binary. Here is what actually decides it.
Drives it up
Unknowns
Undocumented or proprietary protocols, systems nobody can get test
access to, and requirements that are still being decided while I build.
Drives it down
A clear definition of done
API docs, credentials for a test environment, and agreement up front
on what finished looks like.
How you find out
One conversation
Most of this I can scope from a description and a link to the API
docs, then quote a fixed price against a written scope.
Describe the gap and I will tell you what it takes. If it is small I
will say so. If something off the shelf already does it, I will point you there instead
of quoting for it - that happens often enough to be worth promising.
Tell me what needs connecting
Why me
I worked at Zabbix itself, not just with the product. For integration work
that means I know where the API is pleasant and where it is not, which saves the days
usually lost finding out. Nine years on the product, and a Zabbix Certified Trainer,
Expert, Professional and Specialist.
Most of this work also has a public example. The guides below are the written half of
integrations I have actually shipped, which is a better credential than a case-study page,
and the YouTube channel has years more of the same.