Workflow automation · Integrations · Internal software
I help production teams improve the systems and workflows they rely on every day. I came into software through print production — prepress, operations, customer-facing technical roles, and solution engineering — before going deeper into software delivery.
Most of my work sits between people, systems, and production constraints. Sometimes that means building a tool, sometimes connecting systems, sometimes helping a team define the right thing to build before development starts.
Reduce repetitive work across approvals, prepress, routing, reporting, and production handoffs without adding unnecessary process.
Good fit when manual coordination, recurring exceptions, and repetitive tasks slow down production or customer delivery.
Build focused software for operators, specialists, support teams, and other users who need clear workflow support rather than feature-heavy platforms.
Good fit when operators or specialists work around the software instead of with it, and off-the-shelf tools do not match the process.
Connect APIs, cloud services, file-driven workflows, and legacy systems in a way that respects how the operation already works.
Good fit when work moves between cloud tools, file-based processes, internal scripts, and production platforms, and people are still the glue.
Shape vague operational pain into a sensible scope and a realistic implementation plan before anyone writes code.
Good fit when the pain is clear but the scope is not, and the project needs someone who understands the workflow itself, not only the code around it.
Many projects start with “something has to change”, a limited budget, and no clear idea where the answer is. Often it is not in the client’s own domain, and it is rarely head-on. I am comfortable in exactly that situation: a vague brief, real constraints, and a solution that has to be found rather than bought. The one that works can look like nonsense at first glance.
Replace the web store, the platform, or the automation system. Months of migration, a large invoice, and a team learning new tools while production keeps running.
A piece of custom code on top of the existing system, a cleaned-up automation setup, and a couple of well-built workflows. The client keeps what it has, without breaking the bank. That is how the web-store case below was solved.
Some for production companies and software vendors, some for myself. Client and product names are left out on purpose — I am happy to walk through the details in a conversation.
Building automation workflows in a prepress system takes an expert who knows hundreds of tasks and their dialogs by heart. Here a prepress engineer describes the workflow in plain language; an LLM agent behind the chat works through a task taxonomy, asks for every missing decision instead of guessing, validates the draft, and compiles a package that imports straight into the engine. The hard part is knowing what the real system accepts: a harvesting fleet drives live installations through their accessibility and vision layers to record actual ticket and dialog structures, and that knowledge ships as an immutable artifact inside the server image, with a strict boundary that keeps harvesting code out of anything a customer runs. Two MCP servers split the work: a cross-platform product server and a thin agent on the Windows host that talks to the engine. Delivered as a web app and a desktop app for macOS and Windows, with its own identity layer, admin console, and recipes portal. Eight weeks in: 2,700 commits and a test suite of 900 files.
Designed and built solo, with AI coding agents as the implementation crew under a spec, review, and verify chain.
A multi-tenant portal where a print business builds its own intake forms, wires them to node-based workflows, and manages files and users — with connections into prepress systems. I designed the product and the architecture and wrote the entire backend platform: a dozen services around a task-queue engine, an integration broker that keeps credentials out of the main API, authentication, a fleet admin portal, and the CI/CD that ships it all — plus the first generations of the frontend, later handed over to a dedicated developer.
My part: idea, architecture, backend, infrastructure, and the original frontend.
The first, admittedly rough version of what later grew into the platform above: a form builder for order intake with artwork upload, a production board that tracks every job from printing to cutting to lamination, and a small API that lets downstream automation pull new orders together with their files. Used in daily production.
Built solo, end to end.
Every order, item, and press sheet carries a QR mark; at each production stage an operator — or an automated station connected through a scoped API key — scans it, and the item moves along a lifecycle defined per product type. Batches advance whole sheets of mixed orders in one scan, skipped steps require explicit confirmation, defects can be rolled back or reissued, and a risk engine flags jobs as at-risk or overdue against their due dates. The scanner runs as an installable web app on whatever phone is at the station.
Designed and built solo — backend, frontend, and the scanner app.
An online customizer exported artwork as SVGs no print workflow could digest: text shattered into per-letter fragments, curved text baked into rotation matrices, screen-only effects, sizes that did not match the physical product. The obvious fix was a new web store or a new automation platform — slow and expensive either way. Instead, a pipeline on top of the existing setup repairs each product structurally, generates cut lines, remaps colors to spot inks, renders true-to-size PDFs, and hands everything to the prepress automation system, cleaned up and given a couple of new workflows. A manual per-order chore became a batch process, and the client kept the shop and the engine it already had.
Design and implementation of the whole pipeline.
A toolbox of small services an automation workflow can call mid-flight: ink coverage per separation, barcode reading per ink, OCR and text extraction with geometry, visual PDF comparison, and a plate library that matches new jobs against existing printing plates by perceptual hash. Results come back as XML the workflows read natively, so operators get answers inside the tools they already use.
All services, from the first version to the rewrite.
When Pantone libraries disappeared from Adobe tools, a client’s older problem surfaced: every department had its own idea of what each ink was. A central portal became the single source of truth — ink books with Lab, CMYK, and RGB definitions, CxF import and export, per-user access — and Illustrator panels consume it: they create real spot swatches, find the closest ink to any selected object by ΔE2000, and place approved artwork from a shared asset library with visual search — select something in the document, and perceptual hashing finds the matching asset. The panels sync over a lightweight change marker, cache for offline use, and update themselves from the portal.
Portal, server, and both Illustrator extensions.
It started as a lazy idea — I was tired of walking over to read my own meter at home — and ended up as a working solution for a client who installs fountains and needs to meter their water. Their analog meters were already in place, and swapping them for digital ones would have meant tearing into working infrastructure — slow, expensive, and messy. Instead, a fixed camera points at what is already there: classical computer vision finds and unwarps the counter, a compact neural network reads each digit drum, and validation logic rejects implausible values. The digit model was trained on 50,000 synthetic images and needed only 31 real photos to adapt to the actual meters. And cost matters: everything runs on off-the-shelf Raspberry Pi and ESP32 boards with their stock cameras, so instead of a proprietary system the client got something they can buy, replace, and live with for years — with no dependency on the implementer.
Model, training data, and pipeline.
My own device, from concept to working prototype: a battery-powered fog generator with an OLED-and-encoder interface, single and rapid burst modes with enforced cooling cycles, battery monitoring without a dedicated sensor, deep sleep, and a randomized PIN lock so it cannot fire in a bag or in kids’ hands.
Idea, electronics, PCB, enclosure, and firmware.
I do write software, but the bigger advantage is that I have spent years in production, support, product, and customer-facing roles. That gives me a better sense of where workflows break, what people actually need, and what will still be in use a year later.
Workflow automation, integrations, and internal tools for production companies. Long-term engagement with Significans Automation since 2025, alongside other project work.
Working across cloud workflow, technical discovery, demos, architecture discussions, and solution fit for real customer scenarios.
Nine years across sales-facing technical work, support, and product expertise around established print and packaging systems.
The large repro group that later bought FlexoPartner. The same scope, scaled up: a team of forty to lead, and production, logistics, and customers to keep in sync.
A trade shop making flexo plates and prepress for printing houses. Platemaking was only part of it: going to the press to show the plate was fine and the problem sat with the press crew, the machine, or the substrate, standing by for the start-up of difficult jobs, and, when a printer forwarded a brand owner's job to us in full, picking the inks, anilox rolls, and mounting tape along with the prepress.
The first stage of my career, built directly in prepress and production work rather than in software alone.
If you think I could be useful for your team, send me an email. A short description of the workflow, bottleneck, or system boundary is usually enough to start a conversation.
West Flanders, Belgium
Consulting, implementation, and longer technical collaborations.
I am especially interested in work where domain knowledge matters, the process is already established, and the challenge is to make the supporting systems clearer, more reliable, and easier to live with, usually on a budget that rules out the obvious answer. Some of the most useful conversations happen on site, close to the production floor, where the process can be seen directly.