Skip to content
Max

Full-stack Engineering Case Study

Legacy modernization for BattleTech platform

Re-architected a legacy PHP/MySQL BattleTech platform by stabilizing the backend, optimizing advanced search, restructuring database relationships, standardizing delivery workflow, and moving the UI into a reusable component system.

My role

Full-stack Engineer owning the core technical implementation

I audited the legacy architecture, mapped the highest-impact refactor areas, prioritized MySQL and search bottlenecks, coordinated backend/frontend changes, and turned the redesign into reusable component patterns.

PHPMySQLDockerJavaScriptTailwind CSSGitHub WorkflowService WorkersPDF / Card Generation
BattleTech Master Platform unit search interface with advanced filters and unit results table

Context & Ownership

A custom BattleTech platform built around units, rules, and admin workflows.

The product centered on tens of thousands of BattleTech units and their relationships: variants, eras, factions, sources, rules, roles, availability, force-building data, cards, PDFs, and generated player assets.

The system was already in a C-to-PHP migration state when I joined. My work focused on the core technical layer: PHP structure, MySQL optimization, search behavior, authentication, admin workflows, Docker setup, GitHub workflow, and reusable frontend patterns.

My ownership

Full-stack

Backend, database, admin tools, and frontend modernization.

Role

Full-stack Engineer

Owned the main technical implementation across PHP, MySQL, Docker, JavaScript, Tailwind, admin tools, and release workflow.

Scope

BattleTech Master Platform

Advanced unit search, admin CMS workflows, force building, generated cards, PDFs, file handling, and unit detail pages.

Challenge

Active legacy migration

Modernized the existing system while preserving years of BattleTech unit logic, relationships, and internal workflows.

Technical Decision Log

Key architecture decisions behind the modernization.

The work centered on four decisions: modernize the PHP platform incrementally, rebuild unit search as a connected system, optimize MySQL around real data relationships, and move repeated UI work into reusable components.

Decision framework

Architecture

Each decision connected product behavior with backend, database, and frontend structure.

Modernize the PHP platform incrementally

PHP stabilizationmodular refactoringcontrolled migration

Compared against

full rewritepatch-only maintenanceframework replacement first

Why this direction

The application already contained years of BattleTech unit logic, admin workflows, generated assets, and public search behavior. The modernization needed to improve the codebase while preserving existing product functionality.

Trade-off

Incremental work required careful changes across existing PHP modules, routing, controllers, models, and templates instead of replacing everything at once.

Impact

The application became easier to run, debug, extend, and refactor while active product work continued.

Rebuild unit search as a system

faceted filterssession stateAJAX resultspredictive search API

Compared against

simple keyword searchstatic filter pagesclient-only filtering

Why this direction

Users needed to combine filters across units, eras, factions, rules, technologies, sources, tonnage, BV, PV, intro year, availability, and unit type. Search state also needed to work across URLs, sessions, result tables, and admin-managed data.

Trade-off

Search logic had to be handled across backend queries, session state, AJAX responses, sorting, and UI rendering rather than inside a single component.

Impact

Filtering, sorting, result counts, autocomplete, and unit lookup became part of a more predictable search experience.

Rework MySQL around real data relationships

query optimizationindexesfield-size tuninglean text searchrelationship cleanupdata integrity

Compared against

UI-only fixesmanual database cleanupoversized generic fieldsduplicated derived data

Why this direction

The product depended on relationships between units, factions, eras, categories, rules, files, generated cards, and admin-managed metadata. The database needed to support complex filtering, frequent unit lookups, autocomplete, admin edits, and generated outputs.

Trade-off

Database changes required careful handling of existing records and relationships. I optimized queries, added indexes around frequently filtered fields, reduced oversized column definitions, and separated lightweight text search from the full advanced-search flow.

Impact

The platform gained faster lookups, fewer expensive queries, more predictable advanced search behavior, cleaner unit data, and safer admin operations.

Move UI work into reusable components

Tailwind CSScomponent patternsdark themeprint-aware layouts

Compared against

legacy Sass continuationone-off screen stylinglarge component library

Why this direction

The interface repeated patterns across filters, tables, admin forms, force builder views, cards, modals, generated assets, and dark theme states. Reusable components gave the redesign a cleaner implementation structure.

Trade-off

The frontend required shared UI rules for spacing, states, layout, and print behavior instead of continuing with screen-specific styling.

Impact

Frontend work became easier to extend across public search, admin screens, force builder views, dark mode, and printable/PDF-ready outputs.

Architecture Foundation

Backend and MySQL work formed the core of the implementation.

The BattleTech Master Platform combined advanced unit search, admin workflows, generated cards/PDFs, force-builder logic, and large relational datasets across units, factions, eras, rules, and sources.

The work centered on two main tracks: restructuring the PHP application layer and optimizing the MySQL/search system behind the core product flows.

Backend application layer

Backend

Environment, PHP structure, and admin workflows.

Environment and delivery workflow

Moved the project into Docker, reduced local setup conflicts, updated PHP runtime paths, and established a clearer GitHub-based workflow for versioning and collaboration.

PHP application structure

Restructured custom routing, controller, model, and database-object layers to improve code organization, maintainability, and backend consistency.

Authentication, admin access, and CMS workflows

Supported login, role-aware access, and CMS-style workflows for units, categories, metadata, files, emails, and internal records.

Database and search performance

MySQL

MySQL optimization around real unit relationships.

  • Query optimization: reworked advanced-search queries so filtering, sorting, result counts, and unit lookups required fewer expensive database operations.
  • Indexes: added and adjusted indexes around frequently filtered fields such as unit attributes, factions, eras, rules, technologies, sources, tonnage, BV, PV, and intro year.
  • Field-size tuning: reduced oversized column definitions to better match real data limits, lowering memory usage and reducing table weight.
  • Lean predictive search: separated autocomplete from the full advanced-search flow using a lighter text-focused search path for fast unit suggestions.
  • Relationship cleanup: improved handling of related records across units, factions, eras, categories, files, cards, PDFs, and admin-managed metadata.
  • Caching direction: prepared the search layer for future external caching such as Redis for repeated unit lookups and common search patterns.

Implementation Scope

The modernization connected search, admin tools, force building, and generated outputs.

The unit database powered the main product flows: public search, unit detail pages, admin edits, autocomplete, force builder tables, card generation, record sheets, file handling, and PDF outputs.

Advanced unit search

Multi-filter search across unit types, eras, factions, subtypes, technologies, rules, years, tonnage, BV, PV, sources, and Alpha Strike abilities.

Admin CMS workflows

Internal tools for managing units, categories, metadata, files, relationships, emails, permissions, and platform records.

Force builder

Interactive force tables with editable skills, recalculated PV/BV totals, unit removal, grouping, and BattleTech / Alpha Strike outputs.

Cards and PDFs

Generated Alpha Strike cards, record sheet downloads, printable layouts, PDF workflows, and unit-linked gameplay assets.

Client-side data flows

API and service-worker-backed unit downloads with progress state, chunked data loading, and IndexedDB storage support.

Reusable UI patterns

Shared frontend patterns for filters, result tables, cards, admin forms, dark theme states, and print-friendly views.

BattleTech advanced search filter panel
Image description

Logical ERD showing how the BattleTech platform connects the canonical unit catalog to era/faction availability, searchable taxonomy, source assets, admin audit trails, and generated gameplay outputs such as Force Builder tables, cards, record sheets, and PDFs.

BattleTech Platform Data Model

Frontend Modernization

Design-system implementation for search, admin, force builder, and generated outputs.

I led the move from older styling patterns to a Tailwind-based component system. The work covered reusable filters, result tables, force-builder views, cards, admin forms, dark theme states, interactive JavaScript behavior, and print-ready layouts.

I worked closely with the creative team to translate Figma designs into production-ready UI: design tokens, reusable components, semantic HTML, accessibility states, responsive behavior, and native browser functionality where it made the interface simpler and more reliable.

Frontend highlights

  • Design system: translated Figma direction into reusable Tailwind components, shared UI patterns, design tokens, spacing rules, typography, and state styles.
  • Component architecture: standardized filters, chips, result tables, action buttons, cards, admin controls, detail sections, and generated-output layouts.
  • Accessibility and semantics: used semantic elements, clear interaction states, keyboard-friendly controls, readable contrast, and native browser behavior where possible.
  • SEO-aware structure: kept public unit pages, headings, links, metadata patterns, and content structure clean for search visibility and shareable unit references.
  • Interactive JavaScript cleanup: modernized existing UI behavior around filters, tables, force-builder actions, autocomplete, and dynamic page updates.
  • Dark theme and responsive states: aligned surfaces, contrast, hover/focus states, mobile layouts, and repeated visual patterns across the interface.
  • Print and PDF constraints: structured unit cards and generated outputs around browser rendering, print styles, page sizing, and downloadable assets.
BattleTech unit discovery and availability architecture diagram
Image description

Architecture diagram illustrating the search domain model and query resolution flow. User requests pass through a centralized query layer that combines full-text search, dynamic filtering, taxonomy data, and era-faction availability rules to produce accurate, gameplay-valid results. The resulting read model supports advanced search, unit discovery, Force Builder workflows, and generated output assets across the platform.

BattleTech Unit Discovery & Availability Architecture

Outcome

A modernized PHP/MySQL platform for BattleTech unit workflows.

The project delivered cleaner backend structure, faster search behavior, stronger MySQL relationships, reusable frontend patterns, and generated outputs connected to unit data.

The final system supported public search, admin CMS workflows, force building, card/PDF generation, file handling, dark theme states, and a more consistent design-to-code process.

What changed

Core technical improvements across backend, database, and frontend.

  • Standardized the local development setup with Docker and a clearer GitHub workflow.
  • Restructured PHP routing, controller, model, and database-object layers for cleaner backend work.
  • Improved MySQL performance through query optimization, indexing, field-size tuning, and relationship cleanup.
  • Separated lightweight autocomplete from the full advanced-search flow for faster unit suggestions.
  • Modernized repeated UI patterns with Tailwind, design tokens, semantic HTML, accessibility states, dark theme, and print/PDF-ready layouts.
  • Connected public search, admin workflows, force builder, cards, PDFs, and file handling around consistent unit data.