Three systems we designed and run in production
Not a gallery of homepages. These are the engineering problems behind the work, a multilingual commerce data platform, a fleet-operations automation tool, and a defense-in-depth security stack. The constraint, the architecture, and what shipped.
A multilingual B2B commerce platform
A multi-vendor marketplace with a custom machine-translation pipeline and an authenticated B2B sourcing layer.
The challenge
The brief was an export marketplace where independent suppliers run their own storefronts, international buyers source and request quotes, and the entire catalog renders in three languages, on infrastructure the client owns, with no per-transaction platform tax. The hard parts were never the storefront. They were keeping a growing catalog translated and in sync across three locales, isolating dozens of vendors with their own products and payouts, and exposing a buyer-supplier sourcing layer without handing the data to scrapers.
What we engineered
- A custom Python translation pipeline that batches catalog and page content through machine translation and writes it into a localization datastore, keeping three locales in sync as the catalog changes, with no human re-keying
- A multi-vendor marketplace layer on WooCommerce: per-vendor storefronts, product ownership, and a commission-and-payout engine
- An authenticated B2B sourcing (RFQ) API, buyers post requirements and suppliers respond, gated behind login and hardened against user-enumeration and scraping
- Live payments (card and bank transfer) with bulk-order handling
- Structured data and content modeled for B2B discovery
A fleet-operations CLI for a production estate
Python command-line tooling that manages a fleet of production systems over SSH: drift detection, automated remediation, and one-command rollback.
The challenge
Operating a fleet of production systems by hand does not scale, and it is exactly how configuration drift, missed patches, and silent failures creep in. We needed one tool that could see and act on every system in the estate, safely, with a guaranteed way to undo.
What we engineered
- A Python CLI that orchestrates every system in the fleet over SSH, driven by a single declarative config, one source of truth for hosts, paths, and identifiers
- Configuration-drift detection, automated patching, and performance auditing across the whole fleet from one command
- Cache baselining with one-command rollback, and nightly encrypted backups with retention
- Idempotent operations, running it twice changes nothing, which is what makes it safe to automate
Defense in depth, from the app layer to a CUI enclave
A fleet-wide hardening runtime plus a FIPS-validated Linux enclave for Controlled Unclassified Information.
The challenge
Two security problems, two layers. Every public system in the fleet needed a consistent hardening baseline that couldn’t be forgotten or misconfigured site by site. And handling Controlled Unclassified Information for federal work demanded a far stricter environment than any commercial web host provides.
What we engineered
- A fleet-wide PHP hardening runtime that ships one baseline to every system: XML-RPC blocked at the PHP entry point, REST user-enumeration restricted, security and permissions-policy headers enforced, platform fingerprint scrubbed
- A FIPS-validated, hardened Linux enclave for CUI: deny-by-default firewall, application allow-listing, full-disk encryption, and SIEM monitoring
- Estate-wide email authentication (DMARC quarantine, SPF, DKIM), key-only SSH, and a zero-trust gate on internal tools