2026
Padel-IN Qatar v.2
End to end, solo. I designed Padel-IN across two versions and built and deployed both myself, from the flows and interface to the front-end build and a live URL. Both are proposals, taken to a working product instead of left as mockups.
Sports
Conceptual
Proposal
Know More
Padel is booming in Qatar, and getting on a court is more work than it should be. You juggle venues, open times, and the problem of rounding up enough people to actually play. Padel-IN set out to handle all three in one app.
I designed v1, built and deployed it, then used that working version to push the idea further in v2. Both are proposals, but I took them all the way to a live build instead of stopping at Figma.
v1 answered the question of how to book a court fast. v2 had to answer a harder one: what makes someone open the app again next week. The honest answer was other people, not the calendar.
A reservation is a transaction, while a regular game with people you know is a habit. So v2 was rebuilt around the social side and deployed as a working proposal.
The Hard Part
A booking tool only gets opened once you already want to play. That is a thin reason to come back, and a thin foundation to build a product on. v2 had to make finding and organising games the reason to open the app at all.
It had to do that without slowing down the one-minute booking that v1 got right. A social layer usually means more taps and more screens, so this one had to earn its place rather than add noise.
What I Did
I moved players, games, and who is around right now to the centre of the app. Booking became the last step of a social decision instead of the first screen you see. Then I designed it, built the front end, and put it live.
The home screen now leads with games to join and people you play with, not an empty court search, and booking is reached from inside a game. Rather than hand off a spec, I deployed it to a URL anyone can open.
What Changed
The result is a working, deployed product, not a slide deck. You can open the proposal and actually use it, which argues the case far better than a mockup could. It reframes Padel-IN from a booking utility into a small community that books courts as a side effect.
It is a proposal and not yet approved, and it makes its argument by being real. The pull to open it shifts from needing a court to seeing who is playing.
The Call
The easy path was to keep refining the booking flow on screens. I judged booking solved and retention the real problem, and rebuilt the product around that instead. Owning design through deployment is what let me make that call and prove it.
Re-centring a product is harder than polishing one, especially one you have already built once. Doing it in a live build rather than a pitch is what made the argument credible.
More Works
FAQ
01
Are you available?
02
Full-time, freelance, or both?
03
What kind of work do you take?
04
Remote, on-site, or both?
05
Bilingual?
06
What do I need to get started?
07
What about unpublished or NDA work?
08
How long does an engagement take?
2026
Padel-IN Qatar v.2
End to end, solo. I designed Padel-IN across two versions and built and deployed both myself, from the flows and interface to the front-end build and a live URL. Both are proposals, taken to a working product instead of left as mockups.
Sports
Conceptual
Proposal
Know More
Padel is booming in Qatar, and getting on a court is more work than it should be. You juggle venues, open times, and the problem of rounding up enough people to actually play. Padel-IN set out to handle all three in one app.
I designed v1, built and deployed it, then used that working version to push the idea further in v2. Both are proposals, but I took them all the way to a live build instead of stopping at Figma.
v1 answered the question of how to book a court fast. v2 had to answer a harder one: what makes someone open the app again next week. The honest answer was other people, not the calendar.
A reservation is a transaction, while a regular game with people you know is a habit. So v2 was rebuilt around the social side and deployed as a working proposal.
The Hard Part
A booking tool only gets opened once you already want to play. That is a thin reason to come back, and a thin foundation to build a product on. v2 had to make finding and organising games the reason to open the app at all.
It had to do that without slowing down the one-minute booking that v1 got right. A social layer usually means more taps and more screens, so this one had to earn its place rather than add noise.
What I Did
I moved players, games, and who is around right now to the centre of the app. Booking became the last step of a social decision instead of the first screen you see. Then I designed it, built the front end, and put it live.
The home screen now leads with games to join and people you play with, not an empty court search, and booking is reached from inside a game. Rather than hand off a spec, I deployed it to a URL anyone can open.
What Changed
The result is a working, deployed product, not a slide deck. You can open the proposal and actually use it, which argues the case far better than a mockup could. It reframes Padel-IN from a booking utility into a small community that books courts as a side effect.
It is a proposal and not yet approved, and it makes its argument by being real. The pull to open it shifts from needing a court to seeing who is playing.
The Call
The easy path was to keep refining the booking flow on screens. I judged booking solved and retention the real problem, and rebuilt the product around that instead. Owning design through deployment is what let me make that call and prove it.
Re-centring a product is harder than polishing one, especially one you have already built once. Doing it in a live build rather than a pitch is what made the argument credible.
More Works
FAQ
01
Are you available?
02
Full-time, freelance, or both?
03
What kind of work do you take?
04
Remote, on-site, or both?
05
Bilingual?
06
What do I need to get started?
07
What about unpublished or NDA work?
08
How long does an engagement take?
2026
Padel-IN Qatar v.2
End to end, solo. I designed Padel-IN across two versions and built and deployed both myself, from the flows and interface to the front-end build and a live URL. Both are proposals, taken to a working product instead of left as mockups.
Sports
Conceptual
Proposal
Know More
Padel is booming in Qatar, and getting on a court is more work than it should be. You juggle venues, open times, and the problem of rounding up enough people to actually play. Padel-IN set out to handle all three in one app.
I designed v1, built and deployed it, then used that working version to push the idea further in v2. Both are proposals, but I took them all the way to a live build instead of stopping at Figma.
v1 answered the question of how to book a court fast. v2 had to answer a harder one: what makes someone open the app again next week. The honest answer was other people, not the calendar.
A reservation is a transaction, while a regular game with people you know is a habit. So v2 was rebuilt around the social side and deployed as a working proposal.
The Hard Part
A booking tool only gets opened once you already want to play. That is a thin reason to come back, and a thin foundation to build a product on. v2 had to make finding and organising games the reason to open the app at all.
It had to do that without slowing down the one-minute booking that v1 got right. A social layer usually means more taps and more screens, so this one had to earn its place rather than add noise.
What I Did
I moved players, games, and who is around right now to the centre of the app. Booking became the last step of a social decision instead of the first screen you see. Then I designed it, built the front end, and put it live.
The home screen now leads with games to join and people you play with, not an empty court search, and booking is reached from inside a game. Rather than hand off a spec, I deployed it to a URL anyone can open.
What Changed
The result is a working, deployed product, not a slide deck. You can open the proposal and actually use it, which argues the case far better than a mockup could. It reframes Padel-IN from a booking utility into a small community that books courts as a side effect.
It is a proposal and not yet approved, and it makes its argument by being real. The pull to open it shifts from needing a court to seeing who is playing.
The Call
The easy path was to keep refining the booking flow on screens. I judged booking solved and retention the real problem, and rebuilt the product around that instead. Owning design through deployment is what let me make that call and prove it.
Re-centring a product is harder than polishing one, especially one you have already built once. Doing it in a live build rather than a pitch is what made the argument credible.
More Works
FAQ
Are you available?
Full-time, freelance, or both?
What kind of work do you take?
Remote, on-site, or both?
Bilingual?
What do I need to get started?
What about unpublished or NDA work?
How long does an engagement take?