Shipping 5 HTML5 games to the Microsoft Store as a solo dev: distribution lessons

Outside of my day job I run a small game-development handle called Kelby. Over the last couple of years I have shipped five HTML5 games to the Microsoft Store, working alone — software architecture, asset integration, screenshots, store listing, the entire chain. This is a write-up of what I learned, not as a tutorial but as a PM-shaped set of observations about a distribution channel almost no one talks about.

The headline finding is unflattering to my younger self: shipping was roughly 15% of the actual distribution work. The remaining 85% — store listing optimization, screenshot iteration, policy compliance, responding to category churn — was where outcomes were actually decided. It is a lesson I would not have absorbed from reading about it. You absorb it by clicking "submit" five times and watching what happens.

Why HTML5 + Microsoft Store at all

The conventional wisdom is that HTML5 games belong on the open web, not in app stores. That wisdom is mostly correct for big games with their own audience. It is less correct for small games trying to reach an audience that does not exist yet. The Microsoft Store is one of the few distribution surfaces where a tiny developer can put a polished MSIX in front of users who are casually browsing "Games I might install on my work laptop on a Friday afternoon." The intent profile is excellent for HTML5 games — short sessions, low-commitment installs, low expectations on graphical fidelity.

Microsoft has also, quietly, made the path easier than people assume. PWABuilder will take a competent web app with a manifest and a service worker and produce an MSIX package suitable for the Store with very little manual work. The free Store ID program for PWAs further removes the cost barrier. The technical lift is genuinely small. The lift is in everything that comes after the package builds.

The submission process, honestly described

Each submission involves five clusters of work: package preparation, store listing, screenshots and trailer assets, age-rating questionnaires, and policy/compliance attestations. None of these are hard individually. Collectively they took longer than expected on every single submission, because each one has small surprises that you only discover after running into them.

Package preparation surprised me with the icon requirements. The Store wants a square logo, a wide logo, a small logo, a splash screen, and a store logo, each in specific resolutions, and each rendered to specific safe zones. The first game I shipped, I underestimated this and spent a full evening regenerating assets because Microsoft's preview rejected my icons for cropping outside the safe zone. Now I have a template.

Store listing copy is the underrated lever. The first three lines of the description are visible without the user clicking "read more" on the listing card. Almost no one writes those three lines for the listing card. They write them for SEO or for the full-description view. After the second game I started writing those three lines specifically as a hook for someone scanning a category, and install rates moved meaningfully on the games where I updated listings retroactively.

Screenshots are the single highest-leverage asset on the Store, more than the description and more than the logo. The Store renders screenshots large; the user spends most of their decision time on them. I learned to treat screenshots as marketing pages, not gameplay captures. The best-performing screenshots had captions explicitly burned into the image — "Match 3 colours to clear the board" — because the user cannot zoom in or replay them.

Policy compliance, especially around ads

The Microsoft Store has detailed policy requirements that are easy to misread on a first pass. The ones that bit me hardest:

· Ad disclosure must be in the listing. If your game contains ads — even if the ads are AdSense or an ad network loaded inside a WebView — that fact has to be disclosed in the listing copy, not just in the in-game settings.
· Privacy policy URL must resolve. The Store validates this. It must be a real, accessible page covering data collected by the app, including any ad networks. Pointing to a generic Pages template will pass technically but causes problems later if a user complaint flags it.
· Age rating must be accurate. The Store uses IARC. The questionnaire has questions that look benign but have downstream effects on which categories your game is eligible to appear in. Being conservative on one question knocked a game out of the family-friendly category and noticeably reduced installs for a couple of weeks.
· Don't name competitor products in your listing. "Like Candy Crush but free" is a rejectable phrase. "Match-3 puzzle with daily challenges" is fine.

What the data taught me about discoverability

The Microsoft Store reporting is leaner than mobile-app-store reporting. You get installs, uninstalls, basic demographics, and a crude geography breakdown. You do not get search-keyword data, which is frustrating. Within those constraints I learned a few things by triangulating.

First, category placement matters more than I expected. Games that ranked even modestly in their category produced installs that were not visible from any specific search; users were just browsing the category. The implication is that the "categories you appear in" question on submission is a strategic decision, not an administrative one.

Second, the first 14 days post-launch are disproportionate. The Store appears to surface new games in a way that decays quickly. Games that did not break out in the first two weeks rarely picked up afterwards. The implication is to time your asset polish so it is ready at launch, not iteratively over the first month.

Third, uninstall rate is the metric I should have watched from day one. Three of my five games had install spikes that looked great in isolation but were paired with high uninstall rates inside the first 24 hours — clearly users who had been mis-sold by my listing. The net was negative for those games because the Store appears to deprioritize listings that produce fast uninstalls. After noticing this, I started writing more conservative listing copy and the net installs improved on subsequent games even though the install spikes were smaller.

Solo dev lessons, beyond the Store

· Build the asset pipeline before the first game. The minute you ship two games, you will have the same screenshot, icon, and listing problems again. Investing in a template the first time saves hours each time after.
· Treat your store listing as a product, not paperwork. The listing is where 100% of pre-install conversion happens. It deserves the same iteration discipline as a checkout flow.
· Plan for uninstalls as a first-class metric. The temptation to chase install counts is huge. Resist it. A game with 1,000 installs and a 70% retention curve is materially better than one with 3,000 installs and a 30% retention curve, both in store ranking and in long-term economics.
· Time your release for the dead zone. The first two weeks of any month have less new-release competition in the Store than the last two. Submitting around the 3rd of a month gave me better surface-level visibility than submitting around the 25th, holding all else constant.

What I would do differently next time

Two things. First, I would invest much earlier in a proper PWA manifest and service worker before letting PWABuilder touch the project. The auto-generated MSIX is fine but inherits whatever quality is in your web app at the moment of packaging. Polishing the web app first compounds across every game you build.

Second, I would treat the first game as a learning artifact and budget zero growth expectations for it. The first one is where you figure out the asset pipeline, the listing voice, the policy gotchas, the post-launch update flow. Games two through five benefit enormously from that learning. Trying to make the first one a commercial success simultaneously with all the learning is how solo devs burn out.