Personal Fitness Tracker

Three audiences needed different views of the same data. A member logs a workout and watches a chart move. A trainer answers that member's question and adjusts their plan. An admin publishes the routine both of them are looking at. Building three applications would have meant writing the rules about who may see and change what three times, and keeping them in step forever. The hosting made it harder. Shared hosting runs PHP and MySQL and nothing else — no Node process, no background worker, no container. That rules out the way a Next.js application is normally deployed, and it is not a constraint you can design around later. Payment was the third problem. A membership gate that lives in the interface is not a gate: the API is still there, and anyone who has opened developer tools can call it. Two providers had to be supported, and both had to be verified somewhere a browser cannot reach.

The API came first, and everything else is a client of it. Forty-plus REST endpoints in PHP over MySQL, described in one OpenAPI document, so the member app, the admin panel and any future mobile client read the same contract rather than each inventing their own. Roles — admin, trainer, member — are enforced at that layer, once. The member app is Next.js 16, built as a static export. It compiles to files, which is precisely what shared hosting is good at serving, so it needs no Node process at runtime. CI builds it and copies the output into the PHP application's public directory, so a deployment is one bundle rather than two coordinated ones. The admin panel is PHP, running where PHP already runs. Content, users, categories, classes, challenges, moderation and settings are managed there, with TOTP available on admin accounts. Stripe Checkout and PayPal both settle server-side, through webhooks the browser never touches, and the membership gate is checked in the API on every protected request. The interface hides what a non-member cannot use; the API is what actually refuses it.

Twenty core entities and forty-plus endpoints run the whole platform — activities, goals, plans, challenges, feedback, trainer Q&A, favourites, achievements, classes, notifications and the audit trail behind them — from one documented contract. The member app ships as static files. Nothing on the server runs Node, which is what makes the whole thing deployable on ordinary shared hosting rather than requiring a VPS. Playwright covers the paths that matter end to end: signing in, browsing content, the member flows, and the return journey from a payment provider. PHPUnit, PHPStan and a dependency audit run alongside them, and GitHub Actions builds the deployable bundle on every change. Security was built in rather than added: CSRF protection, rate limiting, HTML sanitisation on everything the CMS accepts, a content security policy, token authentication on the API, and TOTP for admin accounts.