Overview
A web backend and testing layer already existed. Our scope was the middleware that ties the ticket-machine devices and the software layers into one working system, delivered by a team of four with one dedicated C++ engineer alongside an electrical engineer, QA and project management.
The challenge
Live binary-packet communication with several physical devices, including invoking Windows communication channels for a custom-built card reader. This is engineering well outside standard web and mobile work, and there is no framework that abstracts a card reader that does not behave the way its documentation claims.
What we built
C++ with 32-bit x86 assembly where the protocol demanded it, binary packet protocols over Windows communication channels, against custom card reader and ticket-machine hardware.
Outcome
A production ticket-machine ecosystem delivered between 2023 and 2024. We name our scope precisely here: the web backend and testing layer were not ours, and we do not present them as such.
Frequently asked questions
Why would a software company do assembly work?
Because the product needed it. Some hardware protocols cannot be driven from a managed runtime with acceptable timing, and pretending otherwise produces a system that fails intermittently in ways nobody can reproduce.
Do you take on hardware integration work generally?
Yes, where there is a defined protocol and physical access to the device. Smart locks, card readers and ticket machines are all work we have shipped.
What was your scope exactly?
The middleware layer only. The web backend and the testing layer already existed and belonged to others.
How large was the team?
Four people, of whom one was the core C++ engineer. Alongside that an electrical engineer, QA and project management.
Further reading
Working on something similar?
We are always open to a short conversation about a project, even when the brief is still rough.