Could ads pay for a news app? Testing the model with an MVP

Testing the business model with a working product

A department head at an advertising agency was testing product ideas. One was the agency's own news app: paid campaigns would bring in users, and in-app advertising would cover acquisition and development costs. I had worked with this client before, building a competitor ad monitoring service.

We needed to answer two questions: would users want the app, and would advertising generate enough revenue to cover its costs? Spreadsheets alone could not answer them. We needed a working product that people could install, use to read current news, and see ads managed through a dashboard.

A separate mobile developer built the app. I handled the entire backend: news collection and processing, the app API, the advertising system, and its web dashboard.

Separating new stories from repeated coverage

The aggregator collected news by scraping some sources and using APIs for others. This brought the same story into the feed several times as publishers wrote their own versions, republished articles, and added follow-up coverage. Without processing, the feed would have been full of repetition.

I developed custom deduplication and news analysis algorithms using specialized libraries for vector representations of text. The system detected duplicates across sources and recognized follow-up coverage of existing stories, distinguishing it from new stories.

Processed articles were categorized, stored, and delivered to the mobile app through an API. The aggregator reliably supplied the app with news.

Managing ads and connecting external networks

I built an initial ad-serving platform for the app, the first version of its DSP. The app had several ad slots in different locations. A web dashboard let the client configure placements and select ad creatives; the backend handled impression allocation and ad rotation.

The client also wanted to choose between its own ads and ads from external networks based on which option offered a better return. To test this, I built an MVP integration with two external ad platforms. Their ads could run alongside the client's own ads.

Fast ad selection and impression tracking

Impression tracking needed particular attention. The system had to decide quickly whether to show the client's banner or a partner's, while recording every impression. I worked on the architecture and performance so that processing these records would not slow down ad serving.

The goal was not to build a high-volume platform with open registration. If the business model proved viable, the product would need to support a larger user base. I allowed for some of that growth in the architecture, but full preparation for scale was deferred until the economics had been tested.

What installs and financial analysis showed

Once the MVP was ready, the department head ran paid acquisition campaigns to test whether people would install the app. Installs confirmed demand. The technical components also supported the test: the deduplicated news feed, ad placements, dashboard, ad rotation, and selection between the client's own ads and external ads all worked.

However, the financial analysis showed that the app and its advertising system would deliver weak returns. The department head decided to stop the project. We did not proceed to build a high-volume platform: actual installs and the financial analysis provided enough evidence to decide against scaling.

The client was satisfied with the work and assigned me the next project.