How to Build an Interactive Platform: Profiles, Activities, Points, and AI Integration

This is an anonymised case study; client and product details are omitted for confidentiality. The architecture and product decisions are public: how to build an interactive platform with many activities without losing control over access, scoring, content, and support.

The product centred on one account that could work with several separate participant profiles. Each profile had its own age context, available activities, progress, point history, and ranking position. For the user, it was one clear journey. For the business, it was a complete digital product with rules, scheduling, and operations.

What the project included

The platform brought several connected product and operational areas together, so it was designed around one user and content lifecycle rather than a collection of unrelated pages.

• Profiles and access. One main account, several participant profiles, context switching, and permissions based on the active profile.
• Themed zones. Games, quizzes, tests, matching tasks, creative activities, and joint activities. Each activity had its own completion rules, result, and scoring.
• Progress and motivation. A content calendar, attempt history, accumulated points, and ranking. Points were recorded as transactions, so the history could be explained and audited instead of showing only one mutable number.
• Materials and events. Separate parent-oriented materials and online sessions with their own schedules, registrations, and statuses.
• Administrative operations. Content, users, schedules, support, and exports were managed from an operational contour instead of by editing the database manually.

How product and technical responsibility were split

React handled the live interaction: quick state changes, game interfaces, tests, and visual feedback stayed responsive. Laravel remained the source of truth for authentication, availability, attempts, results, points, rankings, and the API.

This boundary protects business rules from client-side manipulation. The interface can show the next step immediately, but the server makes the final decision about access, result, and scoring. That matters when content opens on a calendar, an attempt cannot be repeated, or scoring rules change during a season.

The shared user journey

1. Sign-in and profile selection. The user authenticates through the main account and selects a participant profile. The server returns only the allowed context: age group, available zones, and current progress, so switching profiles does not require a second registration.
2. Available activities. The platform checks the content calendar, season rules, age restrictions, and attempt history. A locked activity therefore stays hidden until it opens, and a completed task cannot be started again by an accidental click.
3. Completing a mechanic. React owns the live state of a game, quiz, test, or creative task: steps, timers, hints, and immediate feedback. The client can make the interface feel instant, but Laravel remains the authority for answers, rules, and the final check.
4. Saving the result. Once the task is complete, the client sends the activity identifier, profile, and attempt data to the API. The server rechecks availability and idempotency, stores the result, creates a point transaction, and updates progress without awarding points twice.
5. Operations and support. Administrators can see content, user, attempt, and event states in a separate operational contour. That makes it possible to investigate a disputed result, open the next scheduled material, or prepare an export without editing internal tables.

What the activities looked like

A focused technical episode: AI image generation inside the product

One activity added image generation: a user selected a server-defined base, uploaded their own illustration, and received a result tied to their progress. The interface was simple, but behind it was a full asynchronous production flow.

1. Laravel validates input. The backend confirms permission, the selected base, and the image format. The prompt and other critical parameters remain server-side.
2. The image is normalised. The file is converted to a predictable format and size before it reaches the external service.
3. A generation record is created. The API quickly returns an operation identifier instead of keeping the browser open while the model works.
4. Queue and polling. A worker performs the call while the interface polls only a safe status: pending, processing, success, or failure.
5. The result returns to the platform. The final file is stored through the main file layer and linked to the right profile and activity.

Why a narrow secure proxy was the right boundary

The main application owns users, rules, queues, storage, and progress. We moved the OpenAI Image Edits call into a separate no-store proxy. It accepts one known signed server-to-server request with two images and server-owned settings, calls the provider, and returns a standardised result.

• the key and prompt never reach the browser;
• only signed requests with replay protection are accepted between services;
• both images are validated before the provider is contacted;
• source and result files are not retained in permanent proxy storage;
• Laravel receives a safe JSON contract instead of a raw external response body.

The AI feature therefore remains part of the platform: the user sees a clear outcome and updated progress, while the team gets an observable process, defined responsibility boundaries, and controlled costs.

What makes the platform resilient

The important checks happen at the seams: a profile can be switched in another tab, an activity can close while it is open, a result can arrive twice, or a schedule can change availability. The server rechecks context, operations are idempotent, and points are written as an event history.

For the AI flow, queue, application, and proxy timeouts are aligned, readiness is separate from a basic availability check, and diagnostics keep only safe data: operation identifier, duration, HTTP status, and error code.

The business result

Instead of a collection of temporary mechanics, the team received a managed platform: profiles and permissions, content zones, progress and rankings, events, and administrative tools. The AI activity strengthened the experience without breaking the shared data and process model.

This approach fits educational and family platforms, engagement programmes, interactive specials, clubs, and services with many user scenarios. When a project must launch quickly and remain calm to operate, the architecture should be built around business rules and the user lifecycle, not around one flashy feature.

Read more about why AI accelerates delivery only under engineering control in When AI Development Really Speeds Up a Project.