A handheld reader in the field, a phone that may have no signal, and firmware that has to reach readers already out there. The software has to work where the animal is, not where the Wi-Fi is.
Purpledecks built the software behind Sidekick, Epona Biotech's veterinary diagnostic reader, from the first line of code. Purpledecks has developed and maintained it for years and is still building it.
Purpledecks built all of the software behind Sidekick: the native iOS and Android apps, the Bluetooth link to the reader, the machinery that carries Epona's firmware out to it in the field, the backend server and the internal admin portal.
The reader, the biomarker science and the assay are Epona's. So is the software. Purpledecks built it.
Sidekick is on the App Store and Google Play, working with Epona's reader in the field, and Purpledecks has kept the apps updated ever since.
Epona Biotech is a veterinary diagnostics company in Sligo, in the west of Ireland. They had the science, and a handheld reader of their own for testing horses where they stand. What they did not have was everything around it: the app a vet holds, the link between the phone and the reader, a way to get new firmware onto readers already in the field, the server behind it all, and a portal to run it. Purpledecks has built that software for Epona since 2018.
Before Purpledecks wrote the first line of code, it did the discovery. Requirements, user stories, the architecture, the risks and the estimates, worked through with Epona and put in writing before any build was proposed. Epona committed on that basis, and only then did the code start. That order is the point. It is how a science company ends up with software that fits its business rather than a demo that fits a pitch.
Each Sidekick app finds nearby readers over Bluetooth and shows the vet a live list to choose from, rather than grabbing the first one it sees. That was a decision Purpledecks made once and built twice, because the first reader found is not always the vet's own. Once connected, the app reads the reader's identity, remembers it, and pulls the stored results across, so the next time it reconnects without being asked.
The firmware on the reader is Epona's. Purpledecks built the machinery that carries it out to readers in the field. The app checks the backend for a newer image, downloads it, and sends it to the reader over Bluetooth a row at a time, checking each row before it sends the next, so a completed update is never confused with an attempted one. When the reader reboots, the app reconnects and re-reads the version the reader reports before it records anything. The transfer finishing is not proof the new firmware is running. The reader saying so is.
A vet does not choose where the horse is, so the Sidekick apps Purpledecks built keep working with no signal. Results, notes and changes are stored on the phone and sent when a connection comes back. If the server cannot take one, the app tries again. If the server rejects one, the app keeps it and shows the vet it has not synced, rather than dropping it quietly. Nothing a vet recorded disappears because the field had no coverage.
Purpledecks built the iOS and Android apps as two native codebases with no shared layer between them, and keeps them behaving the same by hand. That was a decision made for Sidekick at the time, not a rule. The cross-platform tools were younger then, and the hard part of this app, the Bluetooth link and the firmware delivery, runs at the native level on both platforms whatever sits above it. It could have been built cross-platform with native modules for the Bluetooth work. Purpledecks chose fully native so that the part that mattered most lived in one layer on each platform.
Behind the apps sits a backend Purpledecks built for Epona, running in the cloud. Every result the app pulls from a reader becomes a record that carries which reader produced it, which test batch it belongs to and when it was taken, and the phone knows whether it has synced yet. The backend keeps those records, the accounts, the paired readers, the configuration for each test batch and the firmware releases, sends the push notifications, and exports results as a server-side job rather than an on-device one. An internal admin portal, also built by Purpledecks, is where Epona uploads a firmware release, manages configuration, sends a notification and exports data.
The mechanisms above are Purpledecks' work. The reader, the science and the assay they serve are Epona's.
The reader, the science inside it and the assay it runs are Epona's, and Purpledecks makes no claim on any of them. The firmware is Epona's too. Purpledecks did not write it. Purpledecks built the software on the phone's side of that link, and the machinery that carries Epona's firmware out to the field.
So is the software. The code, the repositories and the accounts are in Epona's name. Purpledecks built it, and Purpledecks is still building it.
Sidekick is on the App Store and Google Play, and Purpledecks has kept the apps updated since they first shipped. Purpledecks shipped a release of the Sidekick apps to both stores in August 2026.
That release was asked for on a Friday morning. Purpledecks got the builds into review, then advised against releasing on a Friday, because the people who would notice a problem are not around at the weekend. Epona moved it to the Monday. That is what a software partner is for: saying the true thing, including when it is no.
Sidekick has been carried by more than one Purpledecks engineer over its life. That is by design. The knowledge lives in the code and the written record Epona holds, not in one person's head.
The relationship is the same shape it was at the start. Epona keeps the science. Purpledecks builds the software. Neither has needed to change that.
A handheld reader is half of a product. The other half is software: an app for the person holding it, a reliable link between the phone and the reader, a way to get new firmware onto readers already in the field, a backend to hold the results and the accounts, and a portal to run it all. For Epona's Sidekick reader, Purpledecks built every one of those and keeps building them.
The way the Sidekick apps do a firmware update, as Purpledecks built them: the app fetches the new image from the backend, sends it to the reader a row at a time, checks each row before sending the next, waits for the reader to reboot, reconnects, and reads back the version the reader reports before recording the update as done. The firmware itself is Epona's. The delivery is Purpledecks' work.
Nothing bad, if the app was built for it. The Sidekick apps Purpledecks built store results and notes on the phone and send them when a connection returns. A result the server cannot take yet is retried. A result the server rejects is kept and marked as not synced, so the vet can see it and nothing is lost. No signal here means no internet on the phone. The Bluetooth link to the reader works either way.
For Sidekick, because the hard part is native whatever the screens are built in. The Bluetooth link and the firmware delivery run at the native level on both platforms. It could have been done cross-platform with native modules for that piece. Purpledecks chose fully native for Sidekick, at the time, so the part that mattered most lived in one layer on each platform. That was a decision for this product, not a rule Purpledecks applies to every app.
It started with discovery, before any code: Purpledecks worked through requirements, user stories, architecture, risks and estimates with Epona and put them in writing before proposing the build. Then the build. Then years of maintaining and extending it, and the next thing when it comes. Purpledecks does not publish prices. It publishes the shape: understand the business first, build what fits, and stay for what comes next.
Because where there is more than one reader, the first one found may not be yours. Purpledecks built both Sidekick apps to show a live list and let the vet choose. It costs a tap, and it stops the app pairing with someone else's reader.
No. The firmware on Epona's reader is Epona's, and Purpledecks has never claimed it. Purpledecks builds the software that talks to it: the apps, the delivery of new firmware to the field, and the backend behind them. Where a device already has its firmware and someone who owns it, that is exactly the shape Purpledecks works in.
Nothing on this page was rebuilt from scratch. It was built once, for Epona, and it has been kept working, extended and updated by Purpledecks since it first shipped.
If you have a device with real science inside it and no software around it yet, or a connected product whose software has to keep working where the signal does not, that is the shape of work we do. Talk to the senior engineers who would do the work.
Technical review by Brian Egan, founder, and Barry Gough, CTO, who works on the build.
Purpledecks is a senior software engineering firm based in Ireland, in the EU, working since 2012. We build and rescue software that has to work.