Aptoide runs a white-label store network for OEMs and regional operators. Connect is the developer layer: one APK reaches 20+ partners, each with its own approval pipeline, metadata requirements, and country filters.

The economics are real — up to 90% revenue share vs. 70% on Google Play. Evony: 15× RPD. Infinite Magicraid: 10× RPD. Lords Mobile: +24% revenue from distribution expansion alone.

Developers weren't accessing that value because the interface failed to surface it.

• Apps felt lost. Developers described submissions as "stuck" or "disappeared." Status labels used internal system language with no developer-facing translation.
• Analytics opened once, never again. The data was accurate. It gave no direction, no comparison, no next step.
• First submissions rarely completed. One ticket: "I submitted three weeks ago. I still don't know if it's live." That became the design brief.

• Each partner store has different approval states, metadata requirements, and country rules. Nothing simplifies at the system level — only how it's presented.
• Same interface for first-time submitters and experienced publishers. Fundamentally different needs.
• The data was correct. Making analytics useful required changing what was surfaced, not fixing quality.
• B2B developers require control. Removing options carelessly breaks trust.
• Projecting earnings without credible basis destroys trust faster than not showing them.

Lead Product Designer — end-to-end. Research synthesis, problem framing, UX strategy, flows, UI design, prototyping.

Team: 4 engineers, 1 data analyst. No dedicated researcher, no content strategist. Discovery to handoff.

One principle: the system should explain itself.

Every decision ran through one test: does this make the system more legible, or less? That meant understanding over control, progressive disclosure over full feature exposure, system state over status codes.

The original flow required full configuration before submission — store preferences, metadata templates, partner agreements. We cut it to one goal: first live app. Everything else deferred.

• Non-essential steps removed from first-run — under 15 minutes to first submission
• Advanced configuration surfaced contextually after activation
• Progress indicator shows what becomes available at each step, not just current position
• Every step closes with an explicit confirmation and clear next action

The old version put everything on one page. Developers either pushed through on instinct or stopped.

• Split into three scoped steps: upload, metadata, distribution targeting — each with a defined end state
• Store and country selection rebuilt as a visual matrix with smart defaults from prior submissions
• Inline validation on every field — no surprise errors at submit
• Partner metadata surfaced conditionally — appears only when a relevant store is selected
• Post-submission screen explicit: channels pending, channels live, estimated review timeline

Trade-off: Smart defaults and progressive disclosure over full control on step one. Power users reach everything. First-time developers aren't blocked by choices they don't yet understand.

The previous experience exposed the system without explaining it — a 40+ row table of status codes and country flags developers had to interpret themselves.

• Reframed distribution around system state: live, pending, blocked
• Introduced a "distribution gaps" view — every missing channel with an actionable reason
• Layered detail: overview → partner → store-level, on demand

Most coverage improvements came from the gaps view — not new features, but making existing problems visible.

Accurate data, unused. Developers opened it once and left — not because it was wrong, but because it didn't answer anything.

• Replaced raw tables with key metrics tied to decisions: downloads, revenue, transactions
• Segmentation by store, country, and partner
• Directional indicators — values and movement, not just snapshots
• Auto-surfaced insights: "Downloads in Germany up 34%"

Trade-off: Reduced flexibility over raw data exploration. Faster understanding for most users. Analytics engagement: 20% → 60% of active users in Q1 post-launch.

90% revenue share — most competitive in the market. Most developers on the platform never enrolled. The product worked. The interface didn't surface it.

• Earnings estimates integrated into the distribution flow — after going live in a new region, developers see a revenue range based on comparable apps in that market
• Estimates framed as a range, not a guarantee
• Payment section redesigned around trust: payout timeline, per-app transaction history, earnings projection
• Monetization entry points at distribution moments — not siloed in a separate menu

Result: +28% monetization enrollment — highest increase since the feature launched.

The problem wasn't distribution.

It was that developers couldn't see the system working.

Measured in the six months post-launch:

• +40% app submissions — driven by simplified onboarding and the submission flow redesign
• 3× distribution coverage per app on average — developers could see their gaps and close them without support
• 20% → 60% analytics engagement — share of active users engaging with the section, first quarter post-launch
• −55% support tickets — tickets about distribution status and analytics interpretation, first 90 days
• +28% monetization enrollment — highest increase since the feature launched

• Smart defaults need explanation. First-time developers didn't understand why stores were pre-selected and either accepted blindly or changed everything. The logic behind a default is part of the design.
• Insights without a feedback loop are hard to improve. We had no signal on which observations developers found useful. A simple "was this helpful?" would have been enough.
• Legibility is a strategy, not a feature. Naming the core problem clearly made every subsequent decision easier to evaluate.
• In B2B, trust comes before comprehension. If developers don't believe the data, they won't act on it. Credibility has to be designed in.
• Deferred complexity works until it surfaces unexpectedly. Progressive disclosure requires careful thought about when and how hidden options appear.

The platform had real capability. Developers just couldn't see it. The most valuable work here was making a complex system feel obvious — not building something new.