Try the systems.

Eight single-purpose command-line tools that take a season's swatch and colourway images from Drive to a live WordPress wholesale catalogue — every one dry-run by default, every one safe to re-run after an interruption.

Status: Internal tooling, used for the S27 drop

What it does: A season drop means ~166 products, several colourways each, a swatch tile and a photo per colourway, all named by whoever exported them from Drive — and a shared host that rejects large uploads and cannot replace a media file in place. Rather than one fragile pipeline, this is a chain of small tools with sharply separated blast radii: rename, upload-what's-missing, link products to their images, three read-only audits, a careful refresher, and a probe that finds out what the server will actually accept.

A local macOS dashboard for every Claude Code session on the machine — what each one is doing right now, how far along it is, roughly how long it needs, and what it would have cost on API pricing. Zero runtime dependencies, nothing instrumented, nothing leaves the machine.

Status: Working tool, installed and in daily use locally

What it does: Reads only what is already on disk under ~/.claude plus the macOS process table, and derives a live view of every session: state, current activity, running background agents with what each was asked to do and what it is doing now, progress, an ETA range with a confidence chip, and per-model cost attribution. The core runs under plain `node src/server.js` with no dependencies at all — Electron is only the window. The server binds 127.0.0.1 and has no auth surface because it is never reachable off-host.

An LLM screening service that reads and scores every CV against the pinned job description it was submitted under, redacts identifiers twice before anything crosses a border, and never makes an accept or reject decision — the ranked shortlist and the reasoning go to a person.

Status: Foundation shipped as a separate service: sync, intake and extraction, scoring and push-back, merged and tested. On 2 Sep 2026 the screening moved into the HR platform's own recruitment module, one application on one database, with CVs in private cloud storage. HR's first production screening there, on 24 Sep 2026, failed before its result was saved, so no piloted end-to-end run is recorded yet.

What it does: Removes the repetitive half of hiring — reading and sorting every CV by hand — while keeping every accept/reject with a person. As first built, it polled the HR platform for candidates at the right stage, extracted CV text, scored it against a hash-pinned snapshot of the job description, and pushed a ranked shortlist with per-criterion reasoning back onto the /hiring pages recruiters already use. It was deliberately one-directional: the HR app never called out to it, so /hiring kept working when it was down. Since 2 Sep 2026 the same screening runs inside the HR platform's recruitment module. Every LLM step reads one editable markdown file with frontmatter (id, version, model, temperature, inputs, output schema), so changing how candidates are read is a prompt edit with a recorded version and hash, not a deploy.

A weekly Meta ads keep/pause pipeline. A deterministic rules engine flags every pause; an LLM explains each one, and may argue to keep a flagged ad as a labelled override, but can never pause one. Product coverage is printed beside each pause and withholds nothing.

Status: Production pipeline (report path live; Streamlit UI intentionally dormant)

What it does: Replaces a manual weekly Ads Manager review of dozens of ads across three funnel stages. Pulls insights per stage with its own date window, rolls up to one row per ad, evaluates each ad against a pluggable rules engine loaded from a single JSON config, then calls an LLM once per ad-set bucket to write the human-readable recommendation — and emits the same report as Markdown, self-contained HTML (Google Docs–friendly), JSON and PDF. A Streamlit dashboard with ad cards, filters and notes exists in the repo but is deliberately not active; the report is the shipped output.

An internal web app that lets a production-planning team export Shopify orders themselves — one row per line item, each tagged to the warehouse it will actually ship from, with a conservative can-we-fulfil-from-stock verdict.

Status: Internal production

What it does: Removes the developer from a routine data request. A planner picks a date range in local (Bali) time behind company Google sign-in, previews the orders, and downloads Excel or CSV — or pushes to Google Sheets. Stateless, no database. The genuinely hard parts are the warehouse decision (Shopify has three plausible 'location' values that do not mean the same thing) and matching order lines against three stock spreadsheets kept in a different naming system.

A wholesale ordering platform that replaced an Excel order form and the email thread around it. Buyers and sales reps order against live Salesforce product and account data; the order is validated, persisted, rendered to a PDF, signed, and routed to the planning team for accept or decline — with a nearby-stockist conflict check running in the background on every new account.

Status: Production — public order form plus password-gated admin and sales-rep dashboards, released through a dev stack before production

What it does: Takes wholesale ordering off a spreadsheet emailed back and forth and puts it on one form with a review queue behind it. A buyer or a rep picks a season, looks the account up in Salesforce, adds products at the season's prices, and signs; the planning team sees every order in one table with its PDF, its value, its ship window and its decision. Three surfaces, deliberately separated: the public order form, the internal admin page, and a read-only rep dashboard that shows a rep only their own book and a card-masked PDF. Two of the more interesting decisions are defensive rather than featureful — the 'is this a new account' verdict is taken from Salesforce rather than from what the buyer ticked, and accepting an order is refused unless an account actually exists to file it under.

A daily API sync plus the analysis it enabled: independently reproducing a loyalty vendor's own numbers from raw data, then showing that the licence fee on the invoice was the smaller part of what the program actually cost — and that the vendor's headline ROI figure was circular. The figures themselves are one retailer's unit economics and one vendor's commercial terms, so they are described, never published.

Status: Complete: analysis delivered, holdout test recommended, decision pending

Why an explainer: explained rather than replayed, because the deliverable was a decision, not a service, so the page reproduces the method on a cohort it generates in your browser with a known answer — the real program's members, redemptions and revenue are one retailer's unit economics and one vendor's terms, and comparing them observationally is the exact error the project exists to correct.

What it does: Two halves. The engineering half is a small, dependency-free daily sync that pulls every customer, order and points-activity record into a dated snapshot, writes a member balance export, renders a dashboard page and prunes itself. The analysis half is the actual deliverable: a renewal decision on a loyalty platform, built by reproducing the vendor's figures from raw data, taking apart the causal claim underneath them, and writing both the internal recommendation and the letter to the vendor specifying the study design in advance. The in-house alternative that decision would need is a separate entry, the First-Party Loyalty Platform: in shadow mode and not launched.

A re-runnable Shopify migration that reads birthday months out of free-text customer notes into structured metafields — with a keyword guard so 'customer ordered in March' never becomes a birthday, and a dry run that is the default.

Status: Complete — run against the live store, report retained

What it does: Years of customer birthdays and mobile numbers had been typed into the free-text `note` field by staff. This walks every customer, extracts what can be extracted safely, and writes it into `custom.birthday_month` and `custom.mobile_number` metafields so the store can actually use it — producing a per-customer CSV report of exactly what it did or would do.

Two Liquid snippets that stop Shopify's semantic search returning products that share only a theme with the query — because a search for 'lobster' returning a product with the word nowhere on it reads as a broken site.

Status: Live on the production storefront

What it does: Shopify's storefront search expands a query semantically, so /search returned products that only share a theme with it — 'lobster' brought back OH CRAB!, MARLED CRAB V and KEY WEST, and 'pumpkin' brought back WONDERFUL CHRISTMAS, none of which carry the word in their title, tags, description or variants. (MAUI V and CROP BOYFRIEND also come back for 'pumpkin', and stay: a pumpkin colourway is in their variant names, so they are genuine matches.) This adds a post-filter over the search results so an item is only shown if it genuinely carries every word the customer typed, while leaving deliberate tag matches intact. Shipped alongside a jersey-placement product add-on and a banner extension.

A personal project with Stephanie Monique: a Shopify theme built from scratch for ANATOMY, the minimal knitwear label the two of us founded — 24 sections, a named brand palette in the settings schema, no framework and no build step.

Status: Complete, packaged for handover

What it does: A complete editorial storefront theme: hero, marquee, brand intro, philosophy, material values, founders, category grid, collection feature, featured products, CTA banner, newsletter and a cart drawer, on top of the full set of main-* page templates. Colours, type and spacing are exposed as named brand tokens in settings_schema.json (color_ink and friends) so the merchant edits the brand rather than the CSS.

One button that reads a merchandising spreadsheet, pulls the store's own last 14 and 30 complete days of Shopify sales, matches style-and-colour across two naming systems, runs a decision tree with four possible actions or a deliberate blank, and writes three columns back into a sheet people are actively using.

Status: Internal production — the 2.0 running on Cloud Run since its 29 Aug 2026 release

What it does: Replaces a manual Google Apps Script workflow for the seasonal merchandising sheet. Reads the product sheet, fetches real Shopify sales in the store's own timezone, resolves each sheet row to a Shopify style+colour, applies a faithful port of the team's flowchart, and writes back the two sales columns and a Web Suggestion sentence — plus the window dates into row 11, where the sheet already kept them by hand. Standard runs write in one step; a custom-threshold run stops at a preview and needs an explicit, confirmed apply. The README carries a warning block at the top: the app has no sign-in, so whatever sits in front of it is the only thing protecting the sheet.

A nightly-synced PostgreSQL warehouse behind an internal dashboard, built so that 'what did we sell yesterday, through which channel, at what ad cost, and are customers happy about it' is one page instead of five admin UIs and an argument about whose spreadsheet is right.

Status: Production — six nightly source syncs, a role-scoped internal dashboard and an on-demand report runner, all in one deployable service

What it does: Consolidates a storefront, an analytics property, three ad platforms and a review platform into one warehouse, and puts a dashboard on top of it. The genuinely hard part was never the charts — it was that the same figure had previously been computed three different ways and disagreed with the storefront's own report three different ways. So the platform commits to one written definition of a product sale, holds it in a database view, and makes every endpoint read that view. The dashboard's own conventions are written down as requirements for any new page: a date range with previous-period deltas, a daily/monthly toggle wherever there is a time series, CSV export on every card, live data only, and a colourblind-safe categorical palette assigned by slot rather than picked by hand.

Builds and updates storefront product pages from the internal source-of-truth workbooks. One or more style-colours go in; a complete page comes out — title, SEO, variants, size chart, per-size weights, SKUs, barcodes, tags, prices, per-location inventory, images and a per-style description.

Status: Production — five production types on both the create and the update path, driven manually, from a daily returns grid, or from a small internal interface

What it does: Removes the click-by-click assembly of a product page. The season's data already exists — weights in the style master workbook, size charts and prices in a master data sheet, stock and image references in a working sheet, SKUs and barcodes in a UPC list — and a page is a deterministic function of all of it. The tool builds the page from the sheets, so a correction is made at the source rather than in the storefront admin. That is also its sharpest edge, and the README says so plainly: an update re-sends the handle, SEO, description, tags and images, so a hand edit made in the admin will be overwritten. Five production types share one skeleton and differ only in flags, stock location and size filtering — placeholder inventory for a style not yet made, real per-warehouse quantities for one that is, sample sizing for a sample.

The consolidation job underneath the reporting stack: Shopify orders, Salesforce orders and Redo returns merged into the four spreadsheet tabs that operational workflows read directly — first as notebooks, then behind a small multipage interface so someone other than a developer could run it.

Status: Superseded as a standalone repository — folded into the data platform, where it is documented as the legacy sheets path that gets no new investment and must not break

What it does: Keeps four shared spreadsheet tabs — orders, returns, master data and a summary — as the operational source of truth they had already become, but fills them from APIs instead of by hand. The honest part of this project is its documentation: an architecture note in the team's own working language, a runbook, three numbered decision records, and a guide for adding a report. One of those decisions exists to record that a merge function does a date-overlap replace rather than the per-order upsert its docstring claims — the kind of thing that is a trap until it is written down. Its second act was an interface: the pipeline had no CLI and ran only from notebooks, so a multipage app was put in front of it and containerised, which is the moment it stopped being a developer's tool.

An original HR, attendance, statutory-payroll and workforce platform for a ~300-person Indonesian garment manufacturer, replacing a 291-column master workbook, a legacy Apps Script attendance app, paper leave forms and a macro-driven payroll spreadsheet with one auditable system of record. The ~300 is the company's headcount and the system's design target, not a count of people using it: the August 2026 cutover began a phased rollout that is still in progress.

Status: Cloud production since the August 2026 cutover, phased rollout in progress. Release v10.1.0 reached production on 3 Oct 2026, after its four database migrations were rehearsed on a restored copy of production; the current release, v10.4.0, followed on 9 Oct 2026. I promoted both.

What it does: At the August 2026 cutover (v9.30): 17 domain modules (identity, org, people, time, leave, payroll, approvals, performance, recruitment, reports, audit, theme, company, team, tasks, notifications, platform) over a 102-model Postgres schema. Three interface types (Admin / Manager / Employee) with Director-only role administration, effective-dated RoleAssignment history and field-level masking of identity, bank, BPJS and compensation data. Attendance is an append-only event ledger with audited void+replace edits; overtime is computed automatically from actual attendance with no request/approval workflow (confirmed as the company's real rule). Payroll runs through separately versioned rule engines in exact decimal arithmetic, snapshots every rate and threshold onto every result, and produces publish-gated HTML+PDF payslips plus a checksummed bulk-transfer file in the bank's own macro-enabled XLSM template. Also: 13 leave types, THR with automatic payroll inclusion, master-data import/export with preview → transactional apply → rollback, versioned contract PDFs, per-user liquid-glass themes, 30 reports, EN/ID localisation. The only model calls are in recruitment, where screening ranks, scores and recommends and a person decides; nothing probabilistic sits between an attendance event and a payslip. Since September 2026 every merged change ships as one immutable image through staging and smoke tests. Changes to payroll, leave, shared calculations, the database layer, access control or the recruitment AI wait at staging until I promote that exact image, and an integrity compare after every production release rolls it back if anything protected moved. A push that carries a migration releases nothing, so schema changes go in separately, ahead of the code.

A Playwright automation that downloads every applicant CV from a SEEK hirer employer account into per-job folders with a CSV index — built to survive a GraphQL API with introspection disabled that the vendor reshapes without notice.

Status: Working tool, used against a live employer account

What it does: The unified SEEK hirer portal that JobStreet employer accounts now live on has no bulk 'download all resumes' button, and SEEK deletes applicant attachments 180 days after an ad closes — a constraint the README states before anything else. This drives the portal to recover them. Four commands: sign in yourself, teach it your portal, harvest, report. The script never sees or stores credentials.

A three-day technical hiring trial built as an engineering artefact: a deterministic generator that renders synthetic phone-photographed wholesale order forms with seeded defects across 14 classes, and an answer key that grades the correct RESPONSE to each defect, not just the correct value.

Status: Complete — run against a live candidate in August 2026

What it does: The role being hired for is 'someone else's messy process, data nobody labelled, and a definition of working that belongs to a non-technical person in another department'. Rather than test that with a whiteboard question, this builds the messy process: a fictional wholesale knitwear brand whose sales reps photograph paper order forms, and a pipeline the candidate has to design over three days. The generator is deterministic, so the answer key is exact and reproducible.

A Google Apps Script system that turns one shared spreadsheet into a per-employee-permissioned, audit-logged timekeeping app — with real per-row range protections, cross-midnight shifts, and a monthly payroll recap generated rather than re-typed. The legacy system PeopleOS later replaced.

Status: Superseded by PeopleOS; kept as the reference implementation of the confirmed company rules

What it does: Staff clock in and out through a web app form; admins and HR manage sheets and generate payroll recaps from a custom Sheets menu. Every source comment and UI string is in Indonesian. Deployed against a bound spreadsheet with clasp; there is no build, no tests, and no local way to run it — every execution happens in Apps Script. This is also the archaeological source for PeopleOS's CONFIRMED company rules: MAX_OT = 78, REGULAR_DAYS = 7, the Saturday 5-hour shift credited as 7, and the 30-minute late grace all came from reading this code and the payroll workbook formulas.

A private, single-user app, with Today, Life, Money, Creator and Work behind one quick-capture box, rebuilt in September 2026 to replace its first version and Bridge. It keeps money, journal and health records online, so the database enforces ownership on every table, sign-in needs an authenticator code, and AI runs only on my own Mac.

Status: Live since 30 Sep 2026 as a private, single-user app. The September rebuild runs on Vercel with a Supabase Postgres database; it has one account, sign-ups are switched off and sign-in needs an authenticator code. A worker on my Mac runs the AI jobs, the Instagram sync and nightly backups. It replaced its first version, on Vercel since 1 Aug 2026, which was retired at the cutover with its tables moved aside rather than deleted, and my local tracker Bridge, retired the same day. Checked on 9 Oct 2026: the sign-in page answers and the worker is running.

Why an explainer: explained rather than replayed, because the security boundary is a Row Level Security policy in Postgres, and faking a database policy to demonstrate a database policy would argue the opposite of the point — so that one widget is refused, and the recurrence engine and validation schema beside it are real code ported from the app's first version.

What it does: Daily planning was split across two tools that each did half the job: a first version of DENAVUM with three spaces, and Bridge, a laptop-only tracker that had grown an Instagram dashboard and a content studio. The rebuild is one installable app with five spaces behind a single capture box. Today is a daily deck drawn from the other spaces. Life holds tasks, habits, check-ins, a journal, goals, people, documents and reading. Money is a rupiah-first ledger with accounts, budgets, bills, clients, currency rates and CSV import. Creator carries over Bridge's Instagram dashboard, studio, trend research and profile. Work keeps Bridge's three rules: every project has a next action; blocked needs a reason and waiting needs a person; nothing is marked shipped until five handover items are filled in. These rules are enforced in validation, in the domain logic and as database constraints. The capture box reads a typed line, in English or Indonesian, as a spend, income, task, idea, follow-up, date or note, and shows how it will be filed before anything saves; on a phone it also captures offline and sends reminders. The hard part is that one person's money, journal, health and people records live online, so no single check is trusted. There is no way to sign up, and every sign-in needs an authenticator code. Requests pass a host guard and a per-request content security policy. Row-level security is forced on every table: the site's own database role can read nothing until a request's verified identity is set inside its transaction, and a test fails if any table is left unprotected. AI never runs on the server. The site queues jobs in Postgres, and a worker on my Mac claims them and runs them through the Claude Code command line, with schema-checked output, under a database role that cannot reach the money, journal, people or health tables at all. Going live was handled as the migration of a running system: production was backed up, the migration was rehearsed on a copy built from that backup, and the first version's tables were moved into their own schema with a written rollback rather than dropped.

A single-user, local-first work tracker built around one question: what is the next action, and if there isn't one, why not. Stalled work is made to look wrong rather than blank, and a project cannot be marked shipped until five handover items are ticked.

Status: Retired on 30 Sep 2026, when DENAVUM replaced it, and kept as a read-only archive

What it does: Ran on the laptop, bound to 127.0.0.1 only, and kept everything in one folder you could copy. In its July version it was explicitly not a team tool: no accounts, no cloud sync, no notifications, no LLM. By its retirement it also used Claude in five specific places and synced Instagram, work DENAVUM has taken over. Today, List and Board views over projects with markdown notes, subtasks, links, file attachments, an append-only activity timeline, tags, people, a handover checklist and a status-report generator.

The first version of this portfolio — a scroll-driven cinematic sequence over a single WebGL corridor with every word in real DOM underneath it, and a documented editorial rule set forbidding any metric the source repositories do not actually measure.

Status: Superseded — archived at tag v1.0-production; the portfolio has since been rebuilt

What it does: Nine scenes in sequence over one persistent WebGL canvas, six case studies statically generated at /work/[slug] each with a rendered architecture diagram, an Instagram read model, and a three-script QA harness. The genuinely reusable artefact is its editorial rule set: a written document that traces every claim on the site back to a specific repository and bans invented numbers outright.

A small web app that replaced a season's style-master spreadsheet with a normalised database and one edit screen — colourways and their yarn bill of materials, knit details, prices, packaging, shipping and per-size measurements on a single page instead of across a few hundred columns.

Status: Delivered as a self-contained office install — two commands to set up, one to run, one file to back up

What it does: Takes the season's style master out of a spreadsheet where every attribute is a column and puts it into tables that match what the data actually is. Office staff add a style, search by season, style, colour or size, and edit everything about it on one screen. Two details make it survivable on an office machine rather than a developer's: dropdown lists teach themselves, so a yarn or a packing method typed once is offered next time and spelling stays consistent, and the whole database is a single file — the backup instruction is 'copy this file', and the restore instruction is 'put it back'.