Business Matching is Kemenperin’s (Ministry of Industry, Republic of Indonesia) program for connecting Indonesian manufacturers and IKM actors with buyers, distributors, and export channels. The digital platform behind it has been rebuilt four times across eight years — each era matching the technology of its moment while preserving the program’s core mission. This case study documents the full arc: from a PHP 5 monolith through PHP 8 modernization, a decoupled React + Hono architecture, and the current Svelte + Go system running at bm-online.id.

The first incarnation of Business Matching for Kemenperin ran on PHP 5 — a classic server-rendered monolith where every page was generated on request. IKM (small & medium industry) actors could register a company, list products in a catalog, and submit matching requests ahead of ministry-run business matching events. It did the job. Manufacturers adopted a digital matching channel for the first time, and ministry staff gained an admin view over participants. But the stack was aging fast: no dependency isolation, legacy mysql_* patterns in places, and an increasingly brittle deployment on shared hosting. Recap — Proved the model — industry would match online — but the runtime had no headroom left.

The second era rebuilt the platform on PHP 8 — same monolith shape, professional internals. Typed function signatures, Composer-managed dependencies, and PDO prepared statements replaced the legacy patterns. The registration and matching flows gained server-side validation that actually held up under real ministry events. For the first time the codebase had tests covering the critical paths, and ministry staff got a dedicated admin panel to curate participants, approve companies, and schedule one-on-one matching sessions between buyers and producers. Recap — Same shape, professional internals — bought the platform years of stable service.

Era three split Business Matching in two: a React SPA for participants and a Hono-powered TypeScript API serving the data. Decoupling unlocked a genuinely mobile-friendly experience for factory-floor users and let the API serve more than one consumer. JWT-based auth replaced server sessions, PostgreSQL replaced MySQL, and the matching workflow became an explicit API contract instead of implicit page logic. The trade-off was real though — two codebases, two deploy pipelines, and validation rules duplicated on both sides. Recap — A real API and a real SPA — but double the maintenance for a small team.

The current production system at bm-online.id consolidates every lesson from the earlier eras. A Svelte/SvelteKit frontend delivers SSR speed with SPA ergonomics in a single codebase, while a Go backend serves the matching API with a tiny footprint and single-binary deploys. Validation lives in shared schemas instead of duplicated client/server rules, the admin and public experiences share one deployment story, and infrastructure cost dropped to the lowest point in the platform’s history. Recap — One frontend, one backend, one deploy — the architecture the earlier eras were reaching for.

bm-online.id is the living result of all four eras — the same Business Matching program Kemenperin started on PHP 5, now running on a stack designed to last the next era. The history above documents what changed, why it changed, and what each version looked like in production.