Selected Project
Kickd
Documenting my process on building and launching an eFootball app to market, and what I'm learning along the way.
01
It started with a scoreline
Every FIFA session with friends ended the same way — arguments about who was actually better over time. We'd trash-talk, forget results, and have no way to settle it. The stats on-screen disappeared the moment the console turned off.
I started wondering: what if there was a simple way to log scores between friends, track head-to-head records, and surface the kind of stats that made sessions more fun? Winning streaks. Comeback ratios. Who chokes under pressure.
That question became Kickd — a social network for eFootball players. Not a streaming platform. Not a news aggregator. A place where the social fabric of playing FIFA with your mates gets a digital home.
02
Scoping with constraints
The temptation with a first product is to build everything. Social feeds, live match tracking, tournament brackets, leaderboards, coaching tools. I'd been here before with other projects — ambition expanding faster than execution speed.
So I worked backwards. What's the smallest thing that makes FIFA sessions between friends measurably better? Score logging with smart stats. That became version one. Everything else was a "later" problem.
"Do one thing extremely well. The product should make FIFA sessions more fun for friends — everything else is noise."Design principle, Kickd v1
03
Designing for the couch
The context mattered. People would use Kickd immediately after a match — often still on the couch, controller in hand, emotions high. The input flow needed to be under 15 seconds. No sign-up friction. No complex navigation.
I built a design system in Figma first, then started working with a third-party developer to implement it in React Native. The stack: Expo for the build pipeline, Supabase for the backend, Clerk for authentication.
As development progressed, I noticed gaps between my design intent and the implemented UI. Spacing was off. Component states were inconsistent. Button variants didn't match the system. This is where I started using Cursor to make refinements directly in the codebase — bridging the gap between design file and production code.
04
Designer touching code
I had no formal coding background. Ten years of UX and product design, but I'd never opened a terminal and pushed a commit. Kickd changed that.
I started with Cursor as a communication tool — generating code suggestions that I'd pass to the developer. Over time, it became a direct editing tool. Small refinements at first: spacing tokens, color values, component props. Then bigger moves: setting up Storybook for the design system, auditing component consistency across the entire app.
The transition wasn't dramatic. It was incremental. Each small edit built confidence for the next one. The design system I'd built in Figma was now something I could also enforce in code. That felt like a genuine shift in capability.
05
Shipping to real players
Beta invites went out to a small group. The signup form was deliberately simple — name, email, device type, phone number for WhatsApp feedback. We promised access within two weeks and a follow-up conversation about their experience.
The early feedback confirmed the core assumption: people wanted a dead-simple way to track scores and flex stats on their friends. What they didn't need was a social feed, live match integration, or tournament features — at least not yet.
Bringing Kickd to market means navigating app store submissions, managing a small founding team across time zones, and making hard decisions about what to cut from the roadmap to ship something people can actually use.
06
What I've learnt so far
Kickd is still in progress. I don't have a neat ending or a hockey-stick growth chart. What I do have is a clearer understanding of what it takes to move from idea to shipped product — and the humility that comes with realising how much I still don't know.
Key reflections
Scope is the hardest design decision
Knowing what to leave out required more conviction than knowing what to include. Every feature cut felt wrong in the moment and right in retrospect.
The gap between design file and code is where quality lives
Pixel-perfect Figma files mean nothing if the implementation drifts. Being able to touch the codebase — even lightly — changed the quality of the final product.
AI tools lower the floor, not the ceiling
Cursor and Claude helped me do things I couldn't do before. They didn't replace the need to understand what I was building. Design judgment still drives the decisions — the tools just expanded how far I could take them.
Treat side projects like companies
Equity agreements, option pools, beta processes — the operational scaffolding forced me to make better decisions and take the work seriously.
Ship the uncomfortable version
The version that felt "not ready" was the version that got real feedback. Waiting for polish would have meant waiting forever.