1. Design-to-code, with an architecture that survives contact with real content
The static mockups styled each page independently, which meant a shared component (navigation, footer, modals) could look perfect on the one page it was designed against and break silently on every other page that reused it. I established a standing rule — every shared component owns its own complete styling rather than inheriting from a specific page's CSS block — and rebuilt the shared layout components against it. This class of bug came up repeatedly early on; fixing the architecture instead of each individual symptom stopped it from recurring.
2. Systematic QA over spot-checking
Rather than testing pages one at a time as they were built, I ran full Playwright-driven sweeps across the entire student journey and the entire admin panel — every page, checking for console errors, failed network requests, broken images, and dead links. This surfaced real, previously-invisible issues, including:
- A session-state bug where a logged-in user could still be sent to the login page from the account menu.
- Course listings silently falling back to a placeholder image instead of showing the real thumbnail.
- A navigation dropdown rendering behind page content on one specific dashboard, caused by a legacy CSS rule from years earlier.
- Two "add material" admin workflows whose file-upload feature was completely non-functional in production — the API route had drifted out of sync with a method rename.
Each fix was verified by reproducing the actual user flow, not just by reading the code that changed.
3. Performance and reliability under real data volume
One admin report — a purchase/order listing — was crashing with an opaque server error. I traced it to a query that eagerly loaded several nested relationships across the full table with no upper bound, which worked fine in development and exhausted PHP's memory limit against production-scale data. After fixing it, I used the same diagnostic pattern to proactively check the rest of the codebase and found four more queries with the identical latent issue — fixed before they had the chance to fail the same way in front of a user.
4. Turning "it feels broken" into a concrete fix
Users reported that actions like checkout and course registration "felt like nothing was happening," even though they were working correctly underneath. I audited every async action across the application and found the pattern: most gave no visual feedback beyond a barely-noticeable text change while a network request was in flight, so a normal 1–2 second wait read as a frozen page. I added consistent loading-state feedback across every one of these actions, closing a real trust gap without touching the underlying visual design.
5. A full security and data-integrity audit of the admin backend
Before treating the admin system as trustworthy infrastructure, I ran a systematic audit covering authentication coverage, credential handling, file-upload safety, data-referential integrity, and dead/duplicate code — verifying every finding against the running system rather than relying on a read-through alone. This surfaced issues across a full range of severity, from immediately fixable (hardcoded credentials in source, a debug statement left live in a production code path, PII-bearing log files about to be committed to version control) to structural (authentication coverage gaps needing a coordinated, planned fix).
I fixed every issue that was safe to resolve immediately and produced a written, prioritized report for the rest — distinguishing clearly between "broken and needs fixing," "a real risk that needs a proper plan," and "fine to leave for now" — so the client has an honest, actionable picture rather than either false confidence or an unusable wall of findings.
Tech stack
| Layer | Technologies |
|---|---|
| Frontend | Vue 3, Vue Router 4, Pinia, Bootstrap 5, SCSS |
| Backend | Laravel 10, MySQL, Laravel Sanctum |
| Admin tooling | jQuery DataTables (Bootstrap 5 integration) |
| Testing & QA | Playwright — automated browser testing, network/console auditing, visual verification |
| Practices | Component-driven architecture, systematic audits over spot-fixes, written technical documentation |
Outcomes
- A public course platform rebuilt from static design to a fully functional Vue application, with a documented component architecture to prevent the class of cross-page styling bug that would otherwise keep resurfacing.
- A dozen-plus concrete, previously-invisible bugs found and fixed across the full user journey — session handling, broken images, dead links, and a stacking-context bug affecting every page in the application.
- A production-crashing performance bug diagnosed to root cause and fixed, plus four latent instances of the same issue caught and resolved before they could fail the same way.
- Two admin workflows' file-upload features restored from silently non-functional to working.
- A consistent loading-state pattern applied across every async action, closing a real, user-reported "feels broken" trust gap.
- A full security and data-integrity audit of the admin backend, with immediate fixes applied to every safe-to-fix issue and a clear, prioritized, written remediation plan for the rest.
The common thread across this engagement was replacing assumptions with verification: instead of trusting that a component "should" look right on every page, checking it on every page; instead of guessing why a report crashed, reproducing it and reading the actual failure; instead of describing a security posture in the abstract, testing it against the running system and reporting exactly what was found.