Zion Ajibodu
There is a category of engineering problem that doesn’t announce itself until it becomes a crisis. Slow database queries, unoptimised data fetching, pages that bloat with every new feature added individually each one is a performance debt item that gets deprioritised. Together, compounded over time, they become the thing that makes your product unusable.
That is what Gerocare was facing. Nigeria’s leading subscription-based elderly healthcare service. A platform that connects elderly patients with doctors for home visits, health checkups, and remote consultations had grown faster than its infrastructure. The product worked. People used it, trusted it, paid for it. But the technical foundation had not kept pace with the growth, and the numbers were stark.
On average, a single page was firing over 5,000 database queries. Page sizes had ballooned to 45MB. Load times sat at 4 to 5 minutes, on a healthcare platform where doctors and administrators needed to access patient records, appointment schedules, and consultation histories reliably and quickly.
This is the story of how Gerocare fixed it: the hire, the diagnosis, and what a single well-chosen engineer accomplished in under 90 days.
What Gerocare doesand why performance matters more here than most
Gerocare is not a general-purpose health information platform. It is a subscription-based service built around a specific, high-stakes use case: providing Nigeria’s elderly population with reliable access to medical care through regular doctor home visits, health monitoring, and remote consultations.
The people using this platform; doctors conducting visits, administrators coordinating care, family members monitoring health reports, are not browsing casually. They are doing time-sensitive work. A doctor preparing for a home visit needs to pull up a patient’s history quickly. An administrator scheduling a consultation needs the system to respond. A family member checking a medical report needs to be able to actually access it.
When load times hit 4 to 5 minutes, none of that works the way it needs to. The performance problem was not a UX inconvenience. It was a functional breakdown in the delivery of a healthcare service.
The technical state of the platform: what the numbers actually meant
Understanding why the platform was slow requires understanding what 5,000 database queries per page actually means in practice.
The 4–5 minute load time is the result of those two problems compounding each other. The server is hammered by thousands of queries. The response, when it eventually arrives, is a 45MB payload the browser has to parse and render. At every step, time is being wasted.
This kind of technical debt tends to accumulate invisibly. In the early stages of a product, when the dataset is small, 5,000 queries might still return in a few seconds — slow, but not catastrophic. As the platform grows and the dataset expands, the same inefficient queries take exponentially longer. By the time Gerocare’s team identified the problem as their top priority, the numbers had reached the point where the platform was genuinely difficult to use.
Platform performance holding back your healthtech product? We can help.
Gerocare went from 5-minute load times to under 300ms in 3 weeks. If you need a senior engineer who can diagnose and fix a performance problem — and keep shipping product after — talk to our talent team. Shortlist in 5 business days.
The brief: find someone who can fix it and keep shipping
Gerocare’s technical team knew what needed to happen. The challenge was finding someone with the specific combination of skills to do it: deep enough in backend and database performance to diagnose and fix a systemic query problem, but also capable of continuing active product development once the immediate crisis was resolved.
There was also urgency. This wasn’t a speculative infrastructure project that could run in parallel with business as usual. The performance problems were affecting the platform’s usability in production, for real users, right now. The hire needed to happen quickly, and the new developer needed to be productive quickly.
Gigson’s recruitment process matched Gerocare with shortlisted candidates from the top 4% of the Devcenter-assessed developer network — engineers who had passed a rigorous technical assessment, not simply self-selected from a marketplace. Within two weeks, Gerocare had made a hire and begun onboarding.
What the engineer actually did: three weeks, three transformations
The results from the first three weeks are worth examining in detail, because each metric tells a different part of the same story.
1. Queries reduced by 99.8%
Reducing 5,000+ queries per page by 99.8% means taking it to approximately 10 queries or fewer. That is not an incremental improvement. It is a fundamental rearchitecting of how the application retrieves data.
The most common cause of this kind of query explosion is the N+1 problem: a query that fetches a list of records, then runs an additional query for each record to fetch related data. On a page showing 100 appointments, this becomes 1 (fetch appointments) + 100 (fetch doctor for each) + 100 (fetch patient for each) + 100 (fetch location for each) = 301 queries for what could be a single joined query. Multiply that across multiple relationships and multiple components on the same page, and 5,000 queries is not only plausible — it’s predictable.
Fixing it requires auditing every data access pattern, replacing loop-based fetching with eager loading or batch queries, introducing query caching where appropriate, and restructuring the data access layer so it fetches what it needs efficiently. It is meticulous, unglamorous work that requires a thorough understanding of both the ORM layer and the underlying database.
2. Page size reduced by 88%: from 45MB to ~5.4MB
A 45MB page is carrying a significant amount of unnecessary weight. The sources are typically a combination of: uncompressed or poorly compressed assets, images that are larger than the viewport requires, JavaScript bundles that include code not needed for the current page, and data payloads returned from the server that include fields the frontend never uses.
Reducing that by 88% — to approximately 5.4MB — involves working across multiple layers: server-side response trimming, asset optimisation, and ensuring that what gets sent to the browser is proportionate to what the browser actually needs to render the page.
3. Load time from 4–5 minutes to under 300ms
This is the outcome of the first two. When you remove 99.8% of database queries and 88% of the data payload, the server spends far less time processing requests and the browser spends far less time parsing responses. Sub-300ms load time on a platform of this complexity, handling real healthcare data with real users, is a professionally executed result.
“Within the first three weeks, our developer improved the queries by 99.8%, reduced the load time to less than 300ms, and decreased the average page size by 88%.”
Gigson — Gerocare case study
Phase two: new features, not just fixes
The performance work took three weeks. It did not take the whole engagement. Once the acute problems were resolved, the developer moved to the product roadmap — the backlog of features Gerocare’s team had been unable to prioritise while the platform’s fundamentals needed attention.
The first major new feature was a self-service registration flow for doctors. Previously, the process of onboarding a new doctor to the platform required manual intervention from Gerocare’s administrative team at every step. The new self-service flow allows doctors to register autonomously through the platform — submitting their credentials and information independently, with Gerocare’s admin team retaining approval rights before any doctor goes live.
This is the kind of feature that sounds small but has compounding operational value. As Gerocare scales the number of doctors on its network — which it needs to do to serve more elderly patients across more locations — a manual onboarding process becomes a bottleneck. Self-service registration removes that bottleneck without removing oversight.
The full outcome: under 90 days
Everything described above — the performance overhaul and the new feature development — happened within 90 days of the Gigson developer joining the Gerocare team.
What this means for healthtech teams facing similar problems
Gerocare’s situation is not unusual. It is the predictable consequence of a healthtech product that grows faster than its engineering capacity. The platform works well enough to attract users. Users generate data. Data accumulates. Queries slow. The team, focused on shipping product, does not have the bandwidth to stop and fix the infrastructure. Technical debt compounds quietly until it reaches the point where the platform is noticeably, seriously slow.
The Gerocare case demonstrates that this is recoverable — but the recovery requires the right engineer. Not a generalist who can patch symptoms, but someone who can read a query log, identify the root causes, and systematically eliminate them. That profile is specific, and finding it quickly through conventional hiring is hard.
Gigson’s model — a pre-assessed talent pool where only the top 4% of applicants qualify, matched by a talent manager who understands the brief at a technical level — is designed precisely for this kind of hire. Speed matters when the platform is struggling in production. The shortlist was ready within days, not weeks. Gerocare was onboarding within a fortnight of submitting their brief.
A note on remote onboarding for senior engineering roles
The Gerocare hire was fully remote, as most Gigson placements are. The talent success manager’s involvement in the early onboarding period — aligning company goals with the developer’s task list, managing the integration process — is what makes this work. A senior engineer dropped into a new codebase without proper context and clear priorities can spend weeks finding their footing. With active onboarding support, Gerocare’s developer was working on the highest-priority problems from the start.
For healthtech teams in Nigeria, the UK, or elsewhere considering a remote engineering hire from Africa’s developer talent pool: the Gerocare outcome is a useful benchmark. Three weeks to resolve a systemic performance crisis, under 90 days to new features. That is what a well-matched, properly onboarded senior hire delivers.
