Software and data analytics
Mobile Development Team Augmentation Case Study
Sagacity Software
The challenge
Sagacity Software, founded in 2012, builds advanced software applications and delivers data analytics work for its clients, including Tableau reporting. It had taken on a project with a fixed timeline that its in-house team could not deliver against, and the shortfall was not general capacity but a specific set of skills needed at once and needed briefly. Recruiting to fill it carried two costs that were each worse than the problem, the weeks that sourcing, interviewing and onboarding would take out of a timeline that had none to spare, and the permanent positions that would still be on the payroll once the concentrated phase of development was over.
The approach
Sagacity selected the people it wanted from an existing pool of pre-vetted developers and had the work under way within a couple of days rather than after a hiring cycle. The team was composed against the actual shape of the build, three React Native developers with a senior iOS developer and a senior Android developer alongside them where platform-specific work was required, two PWA developers, and a junior Tableau analyst for the reporting side. That combination let the mobile and the analytics strands run in parallel instead of one waiting for the other. As with the rest of these engagements, the size of the team was treated as adjustable, so it could be scaled to the phase of the project rather than held at its peak.
The outcome
Eight developers were augmented into Sagacity's delivery over roughly a year, and the advanced software the engagement was set up to deliver was delivered. The team was scaled up and down against the requirement across that period rather than fixed at the size it started at. Sagacity avoided both the delay of recruiting and the permanent positions it would have been carrying afterwards, and the deadline that prompted the engagement was met.
The instinct when a deadline outruns the team is to hire, and by the time the hire is productive the deadline has passed. Sagacity’s requirement was a named set of skills for a defined window, which is a different problem with a different answer.
Why a fixed deadline makes recruiting the wrong instrument
A recruitment cycle spends its first weeks producing nothing at all. Sourcing, screening and notice periods happen before any code is written, and on a project whose end date is already fixed those weeks come straight out of the build.
The second cost is the one nobody prices at the start: the positions are still there after the peak. A concentrated development phase needs a shape of team that the steady state does not, and hiring to the peak means carrying the peak permanently.
What “pre-vetted” has to mean for a two-day start
Selecting people in a couple of days is only possible if the vetting has already happened, and the word is worth being precise about. It means the technical assessment is done, the work history is verified, English and working-hours overlap are established, and the person has already worked in a client’s delivery process rather than only on their own.
Done properly, that is weeks of work per developer. It has to be paid for before any client asks for it, which is why an outsourced pool that has genuinely done it looks expensive on the day and cheap on the timeline.
Why React Native still needed a senior iOS and a senior Android developer
Three React Native developers covered the shared surface — screens, navigation, state, the majority of the application by volume. That is what React Native is good at and it is why it was the base of the team rather than two separate native builds.
It is not the whole job. Anything that touches the platform rather than the interface tends to fall outside the shared layer, and someone has to be able to open the native project and work in it. Put plainly: a cross-platform framework reduces how much native code you write, not whether you need someone who can write it. Discovering that in the last fortnight of a fixed timeline is the expensive version of that lesson.
How the mobile and analytics strands ran in parallel
Two PWA developers and a junior Tableau analyst worked alongside the mobile group rather than after it. Reporting is the strand that most often gets sequenced last and then compresses, because it appears to depend on the application being finished.
It mostly does not. What reporting depends on is the data model being settled, and that is available long before the screens are. Starting the analytics work against the model rather than against a finished product is what let both strands land in the same window — the same reason we treat data capability as part of an AI-ready ODC delivery team, and what makes custom software delivery schedulable at all.