Problem
The client's platform let users complete structured betting challenges to earn a funded account, similar in spirit to a prop-trading challenge but built around sports betting instead. It had been in development for a while under a previous team, and by the time it reached me it didn't run at all. Every request came back as a 500 error. There was no way to tell, from the outside, whether that meant the whole codebase needed to be rebuilt or whether something small and stupid was quietly breaking everything downstream of it.
That distinction matters enormously to a client deciding what to do next. Rebuilding from scratch and fixing a handful of broken files are very different conversations, and neither one should get decided before someone's actually looked.
Architecture
The intended shape of the system was reasonable: a Laravel API backend with models for challenges, bets, withdrawals, rewards, coupons, and an affiliate program, a bet-resolution service to settle outcomes, PayPal for payments, and a Vue frontend consuming the API. Nineteen migrations, a dozen-plus Eloquent models, a real domain underneath the failures.
The audit itself followed a simple structure: get the application running locally first, since nothing else is diagnosable from a dead server, then work outward from there. Entry point and environment, then the database layer, then the models sitting on top of it, then the frontend's assumptions about where the API actually lives.
Implementation
The root cause of the total outage turned out to be almost embarrassingly small: the Laravel entry point (public/index.php) and its .htaccess rewrite rules were simply missing from the repository. No bootstrap, no routing, nothing to catch a request before it hit a 500. Restoring both got the server responding for the first time.
From there the failures moved down a layer. Migrations were failing because a paypal_payments table referenced billing_details before that table existed, and a duplicate sports migration was fighting itself. Fixing the ordering and removing the duplicate got the schema to actually apply.
Once the schema existed, model mismatches surfaced next: a Sport model declared a SoftDeletes trait against a table with no deleted_at column, and several models' fillable fields didn't match their actual columns. Each of these had been silently swallowed by whatever came before it in the chain, so none of them were visible until the layer above got fixed first.
On the frontend, the API base URL was hardcoded to the client's production domain instead of reading from local configuration, which meant every request during development was quietly leaving the machine and hitting a server it had no business talking to. That got pulled out into proper environment configuration, along with the other hardcoded production URLs scattered through the login and account flows.
With the stack actually running, I seeded realistic test data (users, an active challenge subscription, sample bets across several sports) so the client's team could exercise real flows instead of staring at an empty database.
Challenges
The genuinely hard part wasn't any single fix. It was that the failures were stacked. A missing entry point hides migration ordering bugs, which hide model mismatches, which hide frontend misconfiguration, and each layer looks like "the app is just broken" from the outside until the layer underneath it gets fixed. Diagnosing this kind of system means resisting the urge to patch the first error you see and assume you're done, since the next error down the stack is often unrelated to the one you just fixed.
The other real challenge wasn't technical. Once the platform was actually running, it became clear that "broken" had been covering for a much bigger gap: no live betting execution, no user dashboard, no withdrawal flow, security gaps that needed closing before this could take real user funds. Telling a client that clearly and specifically, instead of quietly patching what was in front of me and letting them assume the platform was closer to done than it was, was the more important deliverable.
Results
The platform went from returning a 500 error on every request to running locally with seeded test data the client's team could actually work with. More importantly, "it's broken" turned into a concrete, prioritized list: what already worked, what was structurally missing, and what needed fixing before any of it could safely reach production. That gave the client a real basis for deciding how to spend their next development budget instead of guessing at it.