5.2s → 0.9s
LCP · MOBILE P75 · LIGHTHOUSE 58 → 95 · A11Y 69 → 100 · 34-DAY ENGAGEMENT
Easy Grocer runs a cycle-based grocery model — curated packages delivered on a schedule — but its WooCommerce site shipped a 5.2-second mobile LCP and a delivery-window picker that dropped carts. Over 34 days I rebuilt the ordering funnel, cut the plugin count by two thirds, and separated driver onboarding from the customer path.
- Client
- Easy Grocer
- Vertical
- Grocery · E-commerce
- Year
- Q3 2025
- Role
- Lead
- Duration
- 34 days
- Status
- ● Live
- Verified
- Live site
Loom walkthrough
Screen plates · Gallery
Placeholders shown — production screenshots replace these on the live build. Arrow keys navigate; Esc closes.
Problem
Easy Grocer’s cycle-ordering model is genuinely different — customers pick a recurring package and a delivery window rather than shopping ad hoc — but the site had been bolted onto a generic WooCommerce theme with 41 active plugins. The delivery-window picker reloaded the whole page, the cart lost items on mobile, and the homepage took 5.2 seconds to become usable. Driver sign-ups and customer checkout shared one tangled funnel.
The business needed the ordering rhythm to feel effortless on a phone, the cart to stop leaking, and drivers onboarded without wading through a grocery checkout.
- ▲ LCP 5.2 s mobile p75
- ▲ 41 active plugins
- ▲ Full-page reload on window pick
- ▲ Cart loss on mobile
- ▲ Lighthouse perf 58 · a11y 69
Constraints
Decisions
Kept WooCommerce. Removed the builder.
Alternative considered: a headless commerce rebuild. Rejected because: the 34-day window and the existing product/order data made a Woo refactor the safe bet. Tradeoff: headless has a higher ceiling; Woo + custom blocks hit the deadline without a data migration.
Delivery-window picker as a no-reload block.
Alternative: a third-party booking plugin. Rejected because: none modelled cutoff windows and neighbourhood grouping. Tradeoff: a custom picker is mine to maintain — but it updates in place, keeps the cart, and is keyboard-operable.
Split driver onboarding from the customer funnel.
Alternative: one funnel with role detection. Rejected because: it confused both audiences. Tradeoff: two entry points to maintain, but each path is short and clear.
Build
Stack
- ▸ WordPress 6.7 + WooCommerce
- ▸ Gutenberg blocks · ACF Pro field definitions
- ▸ Existing payment gateway kept
- ▸ Cloudflare · cache + image resize
- ▸ Custom delivery-window block · no reload
- ▸ WCAG 2.2 AA tested via axe + NVDA + keyboard
Plugins · 41 → 14
- ✓ kept WooCommerce · ACF Pro · Stripe · Yoast SEO · Wordfence · Cloudflare · WPForms
- × removed (27) Page builder · 4 slider/UX plugins · third-party booking plugin · duplicate analytics · 19 orphaned add-ons
Results · Measured
Every metric carries its tool, date, and page measured. The cart-completion figure is the client’s own analytics, 30 days pre vs post launch.
Tradeoffs
I did not rebuild the neighbourhood-grouping logistics back end — only the customer-facing ordering funnel and the driver onboarding. The routing engine still runs on the original service; it was out of scope and working. A logistics-dashboard phase is scoped for 2026.
AI usage · This project
Claude and Cursor scaffolded the WooCommerce block templates and the delivery-window state machine’s test cases. Every block and the payment path were hand-written and reviewed. Accessibility, the cutoff-window logic, and QA were entirely human. No site copy was AI-written.
Read the full AI policy ↗.
- Scaffold
- Claude · Cursor
- Refactor
- Human
- A11y
- Human · NVDA
- Copy
- Client + human
- Architecture
- Human
- QA
- Human
Testimony · Verified
"Our ordering rhythm is the whole product, and Pixy made it feel effortless on a phone. The cart stopped losing items, the site is three times faster, and our drivers sign up without ever touching a grocery checkout."
- Name
- Daniel Mensah
- Role
- Founder
- Company
- Easy Grocer
- Project
- 2025 WooCommerce rebuild
- Verified via
- geteasygrocer.com