From Prototype to Production: Building a Revenue-Critical Mobile SDK

In the beginning, a mobile SDK is built to prove an idea can work. At that early stage, that’s perfectly fine. But when that same SDK becomes directly involved in how publishers make money, and any problems with it immediately impact their income, faith in you, and willingness to launch things, things change.    
   
That was happening with the US AdTech company that provides systems publishers use to monetize their digital content. Their mobile traffic was steadily increasing, and it was becoming their main source of revenue. However, the first version of the SDK was created as a working example for a few initial partners, not a solid, reliable foundation for many publishers, complex ad types, and consistent growth.   
   
As publishers began to expect more, the SDK’s underlying flaws became obvious. Adding features was doable, but the way it was built didn't allow for careful, step-by-step improvement. A change in one place could unexpectedly cause problems in another, increasing the chance of things going wrong and making each launch more worrying.   
   
And the product itself was asking for more. Support for in-stream video, ads that adjust to different screen sizes, specifically positioned ads, and ads that don’t track individual users meant much stricter rules for how ads look and act, how the SDK starts and stops, and how it adheres to privacy rules. These aren’t just cosmetic; they strain the SDK’s internal workings and reveal weaknesses in how it tracks things, how its different parts connect, and how often it's updated.   

FIVE STEPS TO NEW SDK ARCHITECTURE

One particularly noticeable technical issue was the old automatic ad refresh system. Depending on how people were using it, ad refreshes weren’t happening consistently. In the world of advertising, this creates issues for both your earnings and the user experience. The SDK also had very large releases, with many features released simultaneously. This made testing take much longer, increased the risk at release, and, crucially, occurred as the amount of money from mobile was rising.    

The team didn’t just fix the obvious issues; they took a technical approach to rearchitecting the SDK. This is important because problems from the prototype stage won't disappear with a few bug fixes. If the instability is caused by overly linked components, unclear actions, or complex releases, the fix must be a design change.   
   
First, the SDK's core was reorganized into separate modules. Different functionality areas were isolated, allowing each part to be developed independently. This reduced the extent to which different features interfered with each other, making it easier to prevent problems when changes were made. Instead of one section of the SDK unexpectedly affecting another, the new design made the responsibilities and impacts of each section clearer.   
   
Second, they added more automated tests and improved the continuous integration/continuous deployment (CI/CD) system. They managed to test over 50% of the code, which gave them a measurable level of security for the basic functionality. This doesn’t eliminate all errors, but it changes how things are delivered. The team can review important actions more quickly, find errors earlier, and receive faster feedback before sending versions to publishers.   
   
The third thing they did directly addressed the most important issue for revenue: the refresh mechanism. The old, unreliable auto-refresh was replaced with a new, internal ad-refresh system designed to be much more predictable. This sort of change is about more than just neat coding; in a system used to make money, being able to rely on how often ads refresh is key to stable performance and control over advertising availability.    
   
The fourth improvement wasn’t purely about design. It was equally important: they moved from releasing large batches of changes all at once to smaller, more frequent updates. This reduced testing workload, reduced the risk of release, and allowed the team to respond more quickly without making things less stable. Releases became much more manageable.   
   
Fifth, a special demo application was created. This gave publishers a way to test the integration in a controlled environment before deploying it in their live applications. This made it more likely to work when they first started using it and reduced confusion during setup - and it’s during setup that publishers first encounter problems with an SDK.   

RESULTS: MORE SPEED, FEWER PROBLEMS 

The results show what happens when you treat a prototype as a proper foundation. For both iPhones and Androids, the team released over 50 versions to the public while working with older versions and adding more advanced ad types without breaking what existed. This shows the SDK was stable enough to continue developing safely while in use in the real world.    

This improved the process, giving them releases 4 times faster, 30-40% fewer messages from publishers with integration problems, and publishers using the SDK 35-50% faster. Within the team, fewer errors and quick fixes meant that around one-third of the team’s time in each development cycle was available for creating new features. And financially, mobile became a more dependable way to make money, giving the sales team and the publishers more confidence.   
   
Modularization, CI/CD, and testing are all good ideas, and everyone knows that. The key takeaway is that when an SDK becomes essential to how money is made, focusing on reliability becomes a product strategy. How the design is put together affects how trustworthy the company appears. How often you release affects how quickly publishers can get started. And how predictably the software works affects how much money is made.   
   
SDK went from being a prototype to a reliable system for making money from mobile without needing to rewrite it. The technologies it used included SwiftUI, Kotlin, the Google Mobile Ads SDK, the Prebid SDK, and Amazon Transparent Ad Marketplace. These technologies enabled and powered the great business decision to rebuild the SDK from the inside, focusing on separate modules, predictable behavior, and controlled releases.   
   
Mobile became a stable way to get money, and could reliably support the client’s 500 million+ users at the scale they needed.