ONETAPP is a cross-platform desktop gaming rewards platform — landing site, Electron app, user panel, admin dashboard — shipped from concept to live cohort in ten weeks. We were given a one-line brief and a blank repo. These are the four decisions that defined the build and the three features that did not make it.
The founder's problem was real: gamers complete challenges across titles — Steam achievements, in-game tasks, competitive placements — with no single system to recognise that value and convert it into real-world rewards. The market had loyalty programs and gaming peripheral sponsors, but nothing that treated the completion itself as the asset.
Why desktop-first and not mobile?
The brief did not specify platform. The founder assumed mobile. We spent the first three days of week one challenging that assumption.
Gaming is a desktop activity. Gamers sit at a desk, have their Steam client open, and leave it running in the background. A background app that tracked challenge completion without requiring the user to navigate to a separate tab — that was the product. A mobile companion could come later. Starting on mobile would have inverted the use case.
We proposed Electron as the shell, with a React frontend on our standard stack and Postgres on Supabase. The founder took two days to sign off. We started building in week two.
That call was right. Every piece of user research run after launch confirmed it: users kept the app open during sessions. It never competed with the game for attention. A browser tab would have been closed.
What was in scope from day one?
Four surfaces in ten weeks:
- Landing site — acquisition and onboarding entry point
- Desktop app — cross-platform macOS and Windows via Electron, with live challenge tracking
- User panel — profile, reward history, redemption interface
- Admin dashboard — challenge configuration, reward inventory, user management
We cut two mobile builds, a social leaderboard, and a publisher API. None of those cuts happened under pressure. They were made in week one, in the scope session, before a line of code was written.
Which features did we cut, and why?
Mobile app. The brief mentioned it. We removed it after the platform decision. Building Electron and React Native simultaneously would have halved the quality of both. If the desktop launch proves the hypothesis, mobile is the second engagement.
Social leaderboard. The founder wanted a public leaderboard comparing all users across challenges. We declined for one reason: a leaderboard's value is determined by volume, and at launch there is no volume. A leaderboard with forty entries reads as abandoned — which is worse than no leaderboard at all. We built the data infrastructure. The UI ships when there is enough activity for it to read as alive.
Publisher API. The long-term vision includes game publishers adding challenges directly through an API, removing the need to maintain the catalog manually. That is a real product need — and a six-week build with no users yet to validate it. We documented the intended schema and deferred the build entirely.
The cuts are not concessions. A feature deferred until it has users to validate it is not a feature removed. A feature built at launch that no one uses is scope that slowed everything else. Four of forty-two features we have deferred across builds have never been rebuilt — the users those features were meant for never appeared.
What shipped on day one?
Landing site live. Electron binaries signed and packaged for macOS and Windows. User panel behind authentication. Admin dashboard running on production. The founder's initial cohort of thirty-two users were invited before our final commit landed.
We hit the ten-week date. The only internal deadline we missed was the leaderboard data backfill — which was never on the external scope.
What would we do differently?
Two things.
First, the challenge library took three weeks because we underestimated how editorial it was. The founder needed to configure challenges with custom rules, completion conditions, and reward tiers. That is a configurable CMS, not a data table. We should have spec'd the admin challenge flow in week one, not week four.
Second, we over-built the Electron packaging pipeline too early. Getting macOS and Windows code-signing working correctly took two and a half days — it should have been one — because we automated the signing ceremony before the binaries were stable. The rule: build the packaging pipeline once the app is stable, not before.
What does this build confirm?
- Build where your user is already sitting. If the product works alongside something else rather than instead of it, the platform that user already has open is the right starting platform.
- Cut features in week one, not week six. The cheapest cut is made before the feature is written.
- The admin is half the product. Founders who manage a live platform without a proper admin console are doing operations manually. Build the admin as if it is user-facing — because the founder is a user.
The scope decisions behind ONETAPP follow the same principle we apply on every build: the MVP too big test that asks each proposed feature to earn its place before we write a line.
Written 2026-07-05 by Naman Barkiya.