Skip to content
A teal system-health line on a dark grid: one sharp spike, then a flat, unbroken line; below it four outlined boxes in a row, the last one filled.

“We tell ugly apart from expensive.”

Technical leadership for four years: from a crashing server to four re-platformings with zero downtime

A US marketing platform for truck-service businesses. We took over a product that kept crashing on non-scaling hosting and led it through four re-platformings — and no user ever saw a page that didn't work.

Get in touch
A US marketplace for truck services · technical leadership · team of 12 · 2022–2026
Zero
outages across 4 phases
60 → 90+
Lighthouse; SEO 30 → 90+
90%
faster: the 20 slowest queries
Summary

A US marketplace for truck services. We took over a product that kept crashing on hosting that could not scale, with holes that let SQL injection through, and ran it for four years through four re-platformings — PHP to Node.js and NestJS, jQuery to React and Next.js, native Android to Expo, a single server to ECS. In that time no user ever saw a page that didn’t work.

For the first two years we rewrote nothing. We stabilized what was there: AWS, a WAF, email onto SQS, images onto S3, indexes on the twenty slowest queries. Revenue could not wait for a rebuild to finish. MySQL stayed the only fixed point through all four phases, and the old Android apps kept running until traffic from them fell to zero.

The outcome: Lighthouse performance from 60 to 90+, SEO from 30 to 90+, the twenty slowest queries 90% faster — on a platform that lives off organic search.

The problem

The inherited PHP product kept crashing on hosting with no scaling, with security holes that let SQL injection through. The platform lives off organic search and advertisers — every hour of downtime is an hour an advertiser pays for nothing.

The constraint

No rewrite up front — revenue couldn't wait two years for a rebuild to finish. MySQL was declared the only fixed point. And the old Android apps couldn't be shut down, because users don't update when you tell them to.

What we did

  1. Stabilize what makes the money first

    Two months: move to AWS, email to SQS, images to S3, a WAF in front, legacy holes closed. The twenty slowest queries sped up through indexing — not a line rewritten up front.

    Queries 90% faster

  2. Rebuild with zero downtime — both systems live side by side

    PHP replaced by Node.js, then NestJS with TypeScript; React web app, Next.js site, Expo apps, ECS autoscaling. Triggers on the old database forwarded changes to the new one; the old apps ran until traffic hit zero.

    Rollback: seconds, via CloudFront

  3. One design system for web and mobile

    Our own UI library: 200+ components in a monorepo, shared between the React web app and the Expo apps — primitives and forms common, only side effects separated.

    Web and mobile can’t drift apart

  4. AI built into the process, standards in CI

    Engineering rules checked by the pre-commit hook and CI: no any, components under 200 lines, typed API calls. Claude Code in daily use — tests are no longer written by hand.

    Team about 50% faster
THE SYSTEM — ONE HUB, ONE WAY OUT
Three clients enter one API. The API writes to four databases chosen by purpose and puts messages on one queue. Three workers read from the queue, and only one of them ever sends anything.Public siteNext.jsDashboardsReactMobile appExpoMain API506 routes · 100 modelsRelationalthe only fixed pointSearch indexOpenSearchTime-seriesanalyticsCacheRedisQueueSQSOutbound servicemail and SMSSearch syncreindex on changeSix daily jobsrenewal, dunning, re-engagementthe only thing that sends anythingoutside production it redirects all mail to a test address
One API, four databases chosen by purpose, one queue — and a single way out to the clients.
PRODUCTION TRAFFIC — UNINTERRUPTED
Phase 1 · 2022 — stabilize legacy PHP

Two months of rescue: move to AWS (email to SQS, images to S3, a WAF in front), security holes closed, the twenty slowest queries made 90% faster through indexing — not a line rewritten up front.

MySQL — the only fixed point, synchronized through every transition

The result

Four re-platformings, zero downtime. Lighthouse performance from 60 to 90+, SEO from 30 to 90+ — on an ad platform that lives off search, that's direct revenue.
For context
1%
of sales lost per every 100 ms of extra load time
Amazon — Greg Linden, 2006
+2%
conversion per second of faster loading
Walmart

This was an ad platform whose customers arrive from search.

What we’d do differently

We would measure from day one. We have Lighthouse scores and query times, but no number for posting a listing before and after — and that is the flow an advertiser actually feels. Two stopwatch runs in the first week would have given us the best number in this portfolio.

We would also retire the old Android apps sooner. Waiting for traffic to fall to zero was the right call for users, but it kept two client apps on the same API for two years.

Related
A 15-minute report to 0.2 sThe same judgement in another discipline: schema and queries untouched, the speed-up underneath.A construction ERP next to SAPBuilt alongside the existing system, not instead of it — a third piece of evidence for the same rule.The part of a migration everyone skips: the way backThe database migration from phase three, in full — two-way triggers and a way back.
All 18 case studies
  • Node.js
  • NestJS
  • TypeScript
  • React
  • Next.js
  • Expo
  • styled-components
  • MySQL
  • AWS: ECS, S3, SQS, RDS, CloudFront, WAF
  • Claude Code

Have a system that keeps failing but can’t stop?

Get in touch

Systems that can’t stop — from architecture to production.

© 2026 Micro Tech, Sarajevo