This is a live production site for a custom-apparel shop — roughly 30 pages spanning services (screen printing, embroidery, DTF, contract printing), industry and location pages tuned for local SEO, method-comparison pages, a guides library, pricing, gallery, about, and contact. But the pages aren’t the interesting part. The engineering that matters happens after a customer hits “submit.”
The problem: every quote was manual
Before this build, a quote request meant re-keying the customer’s details into Printavo by hand, creating a folder for their files, chasing down the artwork, and replying manually — for every inquiry. It was slow, error-prone, and it didn’t scale with the shop’s growth.
An async, fault-tolerant intake pipeline
When a form is submitted, it fires a WordPress action (pforms_submission_complete) that queues a ten-step background workflow on Action Scheduler. Per order, that workflow: finds or creates the Printavo customer over their GraphQL API, creates a quote, provisions a Google Drive folder under the correct shared drive, writes a submission backup, uploads the customer’s artwork, and sends a templated acknowledgment email.
The detail that makes it production-grade: each step declares its own error policy — fail, continue, or retry — and records a step-level run history. A hiccup in one third-party integration never silently drops an order; it surfaces as a recorded, recoverable failure instead of a customer who never hears back.
Forms that defend themselves
Three config-driven forms — contact, a bulk-order quote for 50+ pieces, and a small-order request — run on a form runtime I built. Every form gets a defense-in-depth layer by default: JSON-schema validation, honeypot and submission-timing checks, rate limiting, and MIME / magic-byte file validation that rejects disguised (polyglot) uploads. Security here is the baseline behavior, not an opt-in setting.
A data layer built to survive retries
Custom database tables (workflows, runs, run-steps) with versioned, reversible dbDelta migrations; credentials encrypted at rest via wp_salt(); a daily cron that purges form entries older than 30 days; and a self-healing reconciliation pass that keeps the database and Action Scheduler’s registered events in sync. Background jobs retry by nature — the schema is designed assuming exactly that.
Shipped like production, not a demo
I executed the Cloudflare / GoDaddy DNS migration, configured GA4, and shipped through versioned releases (release-candidate → stable) with rollback-safe, additive-only migrations, a production runbook, and per-deploy handoff notes. The connector surface is secured with WordPress Application Passwords.
Outcome
A live site with a self-running intake pipeline: a customer’s quote request automatically becomes a Printavo quote, an organized Drive folder containing their artwork, and a branded acknowledgment email — with zero manual data entry. The site has been production-stable through a controlled testing period and into live operation.
The marketing site itself is assembled from reusable, design-token-driven block sections on a theme.json block theme, and the form runtime and workflow engine are part of a custom plugin suite I designed and built from the ground up — so the engineering underneath, front end to background jobs, is mine end to end.