Case Study
From Stalled to Shipped
How Medeq took a long-stalled product to its customers, and the partnership structure that made the final attempt different.
Marnus van Staden
Product & Process
TL;DR
Medeq had been trying to build the platform they sell to their customers for years, and two development partners had failed to get it functional. For the third attempt, Medeq agreed an unusual arrangement: a sweat equity partnership in which ReadyRun would share the risk of failure and the rewards of success. The platform now serves Medeq's customers in the field, and the team that built it is the team keeping it running.
The Starting Point
Medeq is a South African software business serving the medical equipment servicing market. Their customers are hospitals, clinics, and service providers whose technicians log every device they service: ticketing, job cards, checklists, parts, customer sign-off, against an existing ITSM platform (iTOP) that holds the customer, device, and asset data.
Kevin Joubert had been trying to bring this product to market for a long time. Two development partners had taken on the build before us, and neither had delivered a functional platform. Each engagement had been a fixed-price contract; each had ended with money spent and nothing shippable to show for it. A third attempt on the same commercial basis would have meant gambling more cash on the same pattern.
So Medeq took a different route. Instead of a third fixed-price build, Kevin agreed to a sweat equity partnership with ReadyRun. We would invest engineering time at our risk, in exchange for a share of the platform's revenue once it was earning. The structure meant the next attempt would not deplete the cash reserves Medeq needed for everything else. For us, having skin in the game meant we could not afford a shallow read of the problem. That alignment is what licensed the depth of investigation the previous engagements had not been able to support, and it is why this attempt made it past the line the others did not.
The Approach
Every ReadyRun engagement follows a four-stage methodology designed to eliminate guesswork and deliver systems that hold up under real conditions.
Lab / Think, Explore, Imagine
The Medeq problem space had defeated two prior teams, so the first job in Lab was to understand why. Sitting with the workflow (the technician's day, the iTOP integration surface, the signing scenario, the calibration rules) revealed a system with more interlocking requirements than a standard scope document could carry. We mapped the full technician workflow with BPMN diagrams and worked through every edge case.
Two Lab investigations changed the shape of the platform. The brief asked for a customer signature as proof of delivery, easy to meet on the surface. But sitting with the scenario revealed the weakness: if a Medeq customer ever disputed a signed job, the existing approach would not hold up. So the work expanded to a full legally binding signing workflow. The second investigation was about where Medeq's technicians would actually be working. Mobile readiness was not in the requirements, but understanding the technician's day, moving between sites, working on hospital floors and in patient rooms, made it obvious that a desktop-first app would fight the user. Both decisions came from the same pattern: explore the problem in depth, and the platform fits the reality, not the brief.
Forge / Build with Precision
With the Lab specs signed off, the build moved fast. The platform was constructed as an integrated system: technician workflow, job card engine, dynamic checklists, signature capture, calibration tracking, iTOP integration. Every task was tracked against the agreed specs in a project management tool both sides could see, so Medeq always knew what had landed.
Sim / Push Limits, Find Truth
Before the platform reached real technicians, it was put through a structured User Acceptance Test Plan covering the full workflow from login to closure. Edge cases, audit trail events, and the rules around signed and closed job cards were validated in a simulated environment. The platform that landed in technician hands was the platform that had already survived its first day.
Base / Run Steady, Evolve Fast
Base is the operating reality Medeq now lives in. Production servers, networks, access controls, the CI/CD pipeline, and scheduled backups are all provisioned and co-managed by ReadyRun. Medeq does not have a DevOps function and does not need one. When an issue surfaces in the field or a release needs to ship, the team that built the platform is the team keeping it running. Medeq onboards customers at their own pace, and the platform stays out of the way.
"They integrated the new app with the existing ITSM application, written in a different language and running on a different DBMS, effortlessly and securely, and in the process taught me a few things about that system that I have been using for years."
Kevin Joubert
Managing Director, Medeq
What Medeq Now Has
Seven capabilities, each closing a specific gap in how the business runs.
- A mobile-ready technician app. Field agents log in on tablet or phone, work only their assigned tickets, and complete the full service workflow in one flow. This is the design decision that has drawn the strongest feedback from technicians in the rollout.
- iTOP integration that holds together. Customer, service, and device details flow from iTOP into each job card. Make, model, and serial number are validated against the CMDB, and the workflow continues when a match is not found.
- A court-defensible signing process. Technician and customer signatures are captured on-screen and saved as a flattened PDF. Signed job cards cannot be edited; closed job cards cannot be modified. If a Medeq customer ever needs to produce evidence of a signed job, the document will hold up.
- Dynamic checklists that adapt to the equipment. The right checklist appears automatically based on the service type, sub-category, make, and model of the device on the job card. Field agents no longer work from a generic list. Only published templates are selectable, so Medeq controls what "done" looks like for every class of equipment.
- Calibration-aware test equipment tracking. Servicing medical equipment requires test equipment that is itself within valid calibration. A technician cannot complete a job card using test equipment whose calibration has expired, closing a compliance risk that paper workflows leave open.
- Service items with device-level rules. Generic items like cleaning cloths can be added to any job card, while device-specific items like a spring for a particular model are only selectable on jobs for the devices they fit.
- Production infrastructure they don't have to run themselves. Servers, networks, access controls, CI/CD, and scheduled backups, all co-managed. No second contract, no separate operations partner.
The Results
- A product Medeq can sell. After two partners could not deliver, the platform is in the hands of paying customers. Medeq is onboarding their customer base rather than explaining why the product is not ready.
- Evidence that holds up. Every job card has a complete, auditable trail from ticket to closure, and the signed PDF is the kind of document a lawyer would be happy to work with.
- Service quality built into the workflow. Dynamic checklists, calibration checks, and device-aware service items mean the right procedure, equipment, and parts are applied every time. Consistency no longer depends on what a field agent remembers.
- A commercial arrangement that worked for both sides. The sweat equity structure made the build possible at a moment when another fixed-price contract would not have been. Risk and reward now align across the partnership.
"I had a previous app that required a customer signature as proof of delivery. The team not only got this right in the new app, but also added a professional, legally binding signing process that will stand up in court if needed. I never even considered that aspect when I gave them the brief."
Kevin Joubert
Managing Director, Medeq
Lessons Learned
One thing this engagement reinforced for us, worth recording honestly: the traditional split where one developer works the front end and another works the back end does not hold up once AI is a serious part of the toolkit. The productivity gains only land when engineers move across the whole stack fluidly, bringing AI in at every layer rather than as a helper bolted onto one side. Medeq is the engagement where we retired that pattern in our own practice.
Ready to Build Yours?
Every business has a version of the Medeq story: a product that should be shippable but is not, previous attempts that did not get there, and a market waiting for the version that works. If that sounds familiar, we would like to hear from you.