WORK 01 Production platform · original frontend · 2016–2017

EazeGames - Original Web Platform

I designed the frontend architecture and implemented the original web application for a real-time skill-gaming platform with multiplayer competitions, payments, role-based access, a webshop, and multilingual UX.

Explore the original product architecture ↓

The screenshots below show the Version 1 frontend from my 2016–2017 engagement.

Version 1 competition and game-discovery hub. Account details have been replaced with test data.

Role: Senior Frontend Developer
Employer: SharpMinds
Client: EazeGames
Engagement: 2016–2017
Scope: Original web frontend
Starting team: Two people
Expanded team: Six frontend contributors after the prototype phase
Delivery: Original frontend launched during the engagement

PROOF Original engagement

What I delivered.

01Frontend created from scratch
02Real-time WebSocket product flows
03Shared component and utility library
04Production delivery from a two-person frontend starting team
05Frontend CI, candidate interviews, and junior mentoring

01 Product context

Competitions, balances, payments, and live account state.

EazeGames combined HTML5 skill games with player-versus-player competitions, practice and money balances, rankings, payments, account verification, and multilingual user journeys. Live events changed competition progress, balances, and rankings, so those states had to stay clear throughout the interface.

02 Original Version 1 evidence

Six views of the implemented product.

These Version 1 screenshots use sanitized test identities. Signup and email-confirmation screens are omitted.

Archival EazeGames Version 1 public landing experience — Version 1 landing page for the mobile apps and HTML5 game catalog.

Sanitized archival EazeGames onboarding explaining practice currency and money play — Onboarding explained the distinction between practice currency and money play before users entered the competition experience.

Sanitized archival EazeGames authenticated navigation drawer — The authenticated navigation covered competitions, games, payments, verification, profile, and settings.

Sanitized archival EazeGames competition and ranking interface with synthetic player identities — Competition discovery and searchable ranking interface. Player identities and account information are anonymized.

Sanitized archival EazeGames live competition activity table with synthetic player identities — Live competition activity updated player results and rankings. Player identities have been replaced with test data.

Sanitized archival EazeGames contextual notification center — Notifications covered game reminders, account actions, app downloads, and product guidance.

03 Architecture & ownership

My frontend scope.

I joined the initial two-person team and worked on the frontend from an empty repository through production. I also created the shared component and utility library used as the frontend team grew to six.

Frontend architecture and delivery

Frontend architecture and application structure
Core React and Redux implementation
Shared UI component and utility library
WebSocket updates for competitions, rankings, and account state
HTML5 game integration inside the product shell
Payment, role-based, webshop, onboarding, and localized UI flows
Frontend CI and delivery workflow
Client meetings, estimation, code review, candidate interviews, and junior mentoring

Connected systems

Backend and WebSocket services
HTML5 game providers
Pay.nl payment services
Compliance and regulatory workflows

BROWSER SPAReact · Redux · JavaScript

FRONTEND SCOPEShared UI foundationReusable components · Utilities and interaction conventions

FRONTEND SCOPEAuthentication and RBAC surfacesProfile · Verification · Settings

INTEGRATION BOUNDARYCompetition and catalog stateEntry by code · Tournament and ranking views · HTML5 game boundary

INTEGRATION BOUNDARYWebSocket event boundaryPlayer activity · Results and rankings · Account and competition updates

INTEGRATION BOUNDARYPayments and wallet UIMoney and practice states · Pay.nl service boundary

FRONTEND SCOPEDelivery foundationInternationalization · Frontend CI · Production delivery

Architecture map reconstructed for this case study from my original frontend scope.

Text equivalent: the React and Redux browser application contained the shared UI, account and role screens, competition and game catalog, WebSocket-driven updates, wallet and payment UI, internationalization, and frontend delivery setup. It integrated with backend APIs, WebSocket services, game providers, and Pay.nl.

04 Original user journey

From the landing page to a live competition.

01Public landing
02Sign up or log in
03Account validation and age consent
04Practice currency or money-play onboarding
05Competition and game discovery
06Enter a competition or join by code
07Play an integrated HTML5 game
08Live result, rank, and winnings state
09Wallet, verification, profile, settings, and notifications

05 Real-time product complexity

Keeping live competition state understandable.

WebSocket updates changed player activity, rankings, balances, and competition progress.
Money and practice currency, user roles, and account status each changed what the interface displayed and allowed.
Integrated HTML5 games and interrupted connections needed clear loading, error, and recovery states inside the same product flow.

06 Reusable foundation

A shared component and utility library.

I created the shared library as the product expanded. It gave the growing frontend team one place for reusable components, utilities, and interaction conventions.

07 Delivery & team growth

The frontend team grew from two to six.

I joined a two-person frontend team. After the prototype phase, the client expanded it to six contributors. I set up frontend CI, joined client planning and estimation, reviewed code, interviewed candidates, and mentored junior developers through production delivery.

08 Delivery record

What shipped during the engagement.

ProductionOriginal frontend launched during the engagement

2 → 6Frontend team expanded after the prototype phase

Version 1Shared components and utilities for the growing frontend

Frontend CIAutomated frontend delivery workflow

09 Historical retrospective

What I learned about live state and bundling.

WebSocket events changed competition progress, rankings, wallet balances, and account state as players used the platform. Redux gave those updates a predictable data flow. I kept game, competition, wallet, and account state in separate parts of the store so the team could add features within clear areas of the application.

Webpack bundled modules, split code into smaller chunks, processed images and other assets, and minified production JavaScript and CSS. Code splitting reduced the initial download, while the asset pipeline kept the growing frontend practical to load and ship.

What I would change today

Typed contracts for WebSocket and API events
State machines for competition, wallet, and verification flows
Integration tests and monitoring around WebSocket and Pay.nl failures