E-commerce platform stabilization, performance optimization & growth engineering

Intro:

Client: JLI Trading LTD
Industry: E-commerce / re-commerce, auction-based
Scope: Application engineering, infrastructure optimization, platform stabilization, ongoing
feature development

Background:

Jobalots.com is a UK-based re-commerce platform with an auction-driven business model, handling
thousands of requests per minute across browsing, bidding, checkout and payments. When we took over the
platform, it was profitable and operationally critical to the business, but engineering ownership had effectively
lapsed – the original development house was no longer actively improving the system, and the platform had
outgrown what the existing setup could safely support.

Challenge:

The client first reached out because of sharp, unexplained spikes in infrastructure costs that the previous
team was unable to diagnose or contain. A short audit confirmed that the cost spikes were the visible tip of a
much larger picture: the codebase did not follow Laravel conventions, there was no CI/CD, no clear branching
strategy, no automated tests, and no meaningful documentation.

Releases were manual, deployed instance by instance. There was no production error or performance
monitoring. The payment integration was rated “poor” by the operator, with quantifiable revenue leakage
attached. Uptime sat below 95%, and revenue-impacting incidents were a regular occurrence. The platform
needed to be stabilized and modernized while continuing to serve live traffic and ship the features the
business depended on for growth.

Objectives:

Solution:

We took on full engineering ownership of the platform – codebase, infrastructure, releases, incidents, and
technical roadmap – and worked as an embedded team alongside the client’s product and operations
functions.

We started by inspecting the production infrastructure and the application code together, since the cost
spikes turned out to be driven by code-level inefficiencies rather than purely an infrastructure problem. We
fixed the immediate issues, then used the breathing room to learn the system in depth and design a more
appropriate, autoscaling infrastructure to replace what was in place.

From there, the engagement ran on three parallel tracks, sequenced so each one made the next one safer
and cheaper.

Key actions:

• Building the safety net first – automated CI/CD via GitHub Actions, with most releases shipping without
  downtime; production error and performance monitoring with Sentry; introduction of unit, functional
  and static analysis testing on a codebase that had started at zero coverage.
• Upgrading the language version, framework and libraries to current, supported releases, restoring
  security and supportability without a rewrite.
• Performance and stability work driven by real production data: query and application optimizations
  that allowed the same infrastructure to handle materially more traffic at lower load; substantial
  reduction in 5xx error rates; rebuilt background job processing with parallel workers, eliminating
  blocking and overlapping runs; data import and export operations brought down from tens of minutes
  to tens of seconds.
• Rebuilding the payment operator integration to the recommended pattern, moving the operator’s
  health rating from “poor” to “good” and eliminating a known category of lost revenue.
• Continuous delivery of revenue-impacting features and fixes alongside the modernization work, so the
  business never had to choose between growth and stability.

The guiding principle throughout was to fix what we found rather than start from scratch.
Rewriting a live, profitable, custom-built re-commerce platform with thousands of requests per
minute is the easy thing to suggest, and the wrong thing to do.

The harder, less glamorous work – making the existing system healthier in place – is what actually
saved the client time and money, and what kept revenue compounding while we worked.

How we worked

Day-to-day, we operated as the platform’s engineering team rather than as an external supplier. Engineers
and QA were embedded in the client’s product workflow, took part in planning and prioritization, and owned
production incidents end to end – from alerts and on-call response through root cause analysis and
prevention. Roadmap decisions about the platform’s technical direction sat with us, in dialogue with the
business. The client could rely on engineering and focus on running the business.

Outcome

Across the engagement, the platform’s commercial and operational metrics moved decisively in the right
direction.

• 2x revenue, from the first release on our watch
• 99.99%+ uptime in the most recent year (from <95%)
• 0 → 100% releases automated
• 0 → growing test coverage (unit, functional, static)
• Poor → Good payments operator integration rating
• Minutes → seconds longest-running data operations

New customer signups grew significantly (reported by the client) and site traffic increased. Page response
times and 5xx error rates dropped substantially. Background processing was parallelised. Infrastructure cost
was held flat or reduced even as the platform served more traffic, with the new autoscaling architecture sized
to actual demand rather than worst-case guesses.

The application remains the same product the business depends on – now running on a stack that is current,
observable, automatically deployed, and considerably less expensive to operate.