Product first, budget second: how I work with mobile startups

My ideal work partner is not a lone visionary who sees everything but doesn't want to change anything. I'm more comfortable working with a strong technical team: 5–20 people who understand the product and can rebuild it quickly. Not just add features, but change the logic based on data.

My benchmarks are teams like Telegram or the creators of Flo: they build complex products, build them well, and are still ready to discuss pivots constructively instead of defending the original idea to the end.

For me, a good sign is when a team doesn't defend its original idea at any cost. It can argue, ask questions and test hypotheses, but in the end it looks at the facts:

• how users behave,
• where they drop off,
• what they pay for,
• which flows bring them back to the app.

I don't expect founders to set up marketing perfectly on their own. That's my area of responsibility. What matters much more is their willingness to change the product if the numbers show it can't withstand scaling. We look at the numbers and the market together and decide what to do next — refine product features, test new segments or hypotheses.

Work usually doesn't start in the ad account. First, we get to know the team, go through the current version of the app, and look at the metrics, the market and competitors. Then we define what needs to be tested:

• what to simplify in the product;
• which flow to strengthen;
• which features to drop;
• which segments to test;
• which markets to try;
• how to change the paywall, pricing or onboarding.

Next, we look at acquisition cost, early returns, payback dynamics and user behavior. If the economics don't work, we refine everything, go back and test again. This cycle can take a year, two, sometimes three.

When the product starts paying back within the targets set at the start, the real scaling phase begins. At that point, you've earned the right to increase the budget two, three or five times. For me, such a case is the joint work of product and marketing, not a win for one department.

Another telling case is a network of productivity apps and utilities: translators, call recorders, scanners, weather apps, weather radars. About 10–15 products in total, all on a subscription model.

For several years, we improved monetization every day and shifted our marketing focus. We followed this logic: if one app shows better economics, we push it harder. If tomorrow another one starts performing better, we switch to it.

Gradually, ad budgets grew to $3–5M a month. It wasn't a sudden breakthrough. We got this result through years of work with the numbers, the product and attention to detail.

A separate story within this case is the document scanner. Work on this product took about 2.5 years. At some point, the economics finally came together the way we wanted, and within a month we increased the ad budget 15 times. Thanks to this approach, revenue grew roughly 7–10 times.

But growth like this has a downside.

The platform where we promoted the products noticed the sharp spike and blocked the account. At the same moment, the huge influx of users caused the product to go down. It's an unpleasant but important part of the experience: when you work with large volumes and sharp jumps, you need to think about the risks of such rapid growth in advance. For example, you need to:

• have backup accounts;
• diversify channels;
• not bet everything on a single traffic source;
• not scale as if the platform won't notice.

This case showed us that growth isn't only about increasing the budget. You also have to account for the infrastructure that will withstand that growth.