Work
Things I've built, migrated or repaired — what the problem actually was, what decided the design, and what the result does and doesn't prove.
These are systems I've built, migrated or repaired. Each page says what the problem was, what I did about it, and what it doesn't prove. No invented outcomes. Where something is still a pilot, or I don't have a measurement, the page says so.
Where the code can be public it is, and those projects have their own pages in the catalogue. Where it belongs to somebody else, the case says what changed for them and stops there.
The work tends to come in a few shapes:
- a platform that had to keep serving while I replaced it piece by piece, with the running system as the reference for what "working" means;
- a directory or marketplace where nothing goes live until it has been reviewed, and duplicates, media processing and rollback are one operation;
- a data product built from official sources, where every published fact keeps the source behind it and there is a way to correct it;
- pipelines that stay private: model endpoints, prompts, credentials and generated media never leave infrastructure the client controls;
- a migration I'd trust because the rows reconcile and the checksums match, not because the cutover happened.
Every case page has the same four things: the problem in the words of whoever had it, the constraint that decided the design, what I built, and what it doesn't prove. If I can't write that last one, the case isn't finished.
I'm publishing these one at a time as I finish reviewing them, so a project can show up in the catalogue before its case page does. Until then, the catalogue page is the one to read.
Work pages
A 51,098-page directory release with a private publishing control plane
Moving a large adult-services directory off a legacy Laravel and MariaDB request path onto an immutable Rust output with an authoritative route manifest - 409,495 classified route outcomes and 321,904 redirects tied to the observed public release.
A back office for review sites where the evidence and the rollback both matter
An operator application that takes a candidate domain, gathers bounded evidence, extracts and scores what it found, passes it to review, and then renders a static release that can be activated or rolled back.
A bilingual directory where publication state is visible, not assumed
An English and Thai directory with location, listing, detail and operator surfaces, built so that publication state — source, consent, moderation, translation and removal — is something the operator can see.
A licensed in-home day care directory built around a person's address
A directory experiment for licensed in-home day care providers, where the map is the friendly surface and the crawlable state, city and provider routes are the actual product — with coordinates deliberately approximate because the address is somebody's home.
Building a publishing pipeline that keeps releases and acquisition apart
Evidence, inputs, outputs, costs and media sit in bounded production packs, a Go manifest drives a streaming Rust renderer, and activation is atomic — with 22 of the 24 acquisition techniques deliberately left manual.
Fixing a dental website's business details, redirects and tracking
A multi-milestone engagement on a dental practice site: consolidating redirects, removing conflicting practice markup, aligning the homepage details with the structured data, and cleaning up the agreed Google Ads conversion setup.
Next.js and WordPress launch checks
Reviewing a headless Next.js and WordPress website before launch: page and deployment problems identified at the route level, corrections scoped against the affected page types, and the changed behaviour retested on the live site.
One demo submission, one GA4 event, and a matching CRM lead
I gave a SaaS site a permanent demo page, replaced the homepage popup links with ordinary links, and tied the GA4 lead event to form success — with a controlled test on 11–12 August 2026 producing one outbound event and a matching HubSpot record the client confirmed.
Rebuilding a 1.2 million row catalogue, and keeping the evidence
A frozen legacy dump turned into 379,232 canonical rows with 823,089 raw rows kept beside them — checksums on the result, no orphaned relationships, and 28 sequences repaired before anyone trusts it.
Recovering old WordPress URLs after a migration
An old WordPress URL inventory worked through page by page: recoverable addresses mapped to specific current pages, retired and ambiguous ones deliberately excluded from catch-all rules, and the live redirects checked for chains, loops and soft 404s.
Replacing an established marketplace's engine while it kept taking money
I moved a live adult-services classifieds platform onto a new stack — Go API and workers, an Astro public site, React account and admin surfaces — while billing, moderation, media and search kept working. The recorded release had not passed its final production gate.
Setting up lead tracking and reporting for a services business
A completed multi-month engagement: GA4 and Google Tag Manager implemented and tested for a lead-magnet funnel, and GSC and GA4 reporting built so that starting data, internal visits and test activity are separated rather than averaged together.
WordPress SEO fixes delivered behind an agency
The agreed WordPress changes made and checked while the agency kept the end-client relationship: a Search Console property established, the sitemap confirmed, the homepage canonical and metadata corrected, and priority service pages updated inside the existing theme.
nikom.work: rebuilding my own site as an in-memory Go renderer
The Laravel version answered every page view with database queries and two cookies. I rebuilt it as a Go site that does no database work on a page view, and kept SQLite for one job — holding a contact message until it is delivered.
Have a system like this?
Describe the workflow, the data or the system you need built. Scope and any quote are handled privately after the enquiry.
Published