> product // shopflare-search // the making of
ShopFlare Search
how it was made.
ShopFlare Search started as two repo clones on the same December day and sat quiet for four months. Then the real build happened — 52 commits across two production stores, a Doofinder-style widget rebuilt from scratch, and AI vision enrichment that reads product images to fill gaps that the catalogue never covered.
The short version
The initial repos were created in December 2025 — one for a motorcycle parts store, one that would become the second store — and then left. The real build only started in April 2026: a single commit landed FTS5 full-text search, fitments, an MCP server, a widget, manuals and parts-books all at once. What followed was a fortnight of hard polish: a Doofinder-style layout overhaul, search-as-you-type suggestion chips, facet filtering, sort controls, ARIA accessibility, mobile fixes, and injection via WordPress mu-plugin. The the second store fork activated a week later in a single focused day, adding business-owner analytics, Google OAuth with an email allowlist, and Llama 4 vision enrichment — AI that reads product images to surface colour, material and other attributes the text never described. Both stores have been in production since, with weekly analytics digests and a steady stream of real-feedback fixes.
// the build log · mined from the commit history, nothing dramatised
Two repos, one day
Both instances were initialised on 7 December 2025 — the parts store and the repo that would eventually become the second store, both from the same starting point. Neither shipped anything for four months. The groundwork was laid; the build would wait.
The whole engine, landed at once
On 17 April a single commit dropped the complete search engine: FTS5 full-text index, fitments data, an MCP server, the embeddable widget, manuals and parts-books support. The next day the session learnings went into CLAUDE.md. That one commit was the product — everything after was refinement.
Doofinder parity, earned not borrowed
The parts store was paying for Doofinder. The next week was a head-on sprint to match it: a full layout overhaul, search-as-you-type suggestion chips, facet checkboxes with brand and category filtering, a sort dropdown (relevance, price, newest), GST pricing display, safety filters, and injection via WordPress mu-plugin rather than a theme hack. The widget was then wired to the store's existing search button instead of floating a pill over it — more honest, less intrusive. ARIA roles, focus trapping and live regions followed. The commit message "Doofinder-style polish + GST pricing + safety filters" gives the benchmark.
The second store: fork, vision, analytics
On 23 April the second store instance came to life in a single day. The fork added business-owner analytics — a dashboard home with an owner overview — Google OAuth with an email and domain allowlist blocking sign-ups outside configured accounts, and Llama 4 vision enrichment that extracts searchable attributes from product images. A vision prompt benchmark compared minimal against detailed prompts across Llama 4 and Gemma 4 before the pipeline was hardened. Also that day: fixing the analytics pipeline so it stopped logging every keystroke as a separate search event.
Client feedback and weekly rhythm
Both stores settled into production. The parts store began publishing weekly analytics digests from 26 April. A fitments API endpoint was added for a WordPress plugin. In May, the second store addressed direct client feedback — a 4-column grid, switching from an input to a button, a facet count bug fix, and price gating for non-logged-in consumers. The the parts store sync batching step was fixed after a step timeout surfaced in production. Steady, unglamorous work.
git log: “feat: full search engine build — FTS5, fitments, MCP, widget, manuals, parts-books”
One commit, 17 April 2026 — the entire engine, landed at once after four quiet months.
// the roads not taken
Tried, measured, set aside: the judgement lives here as much as in what shipped.
Analytics dedup — one event per query, not one per keystroke
The original analytics pipeline logged a search event on every autocomplete call. A commit on 23 April explicitly fixed this: "Stop logging every keystroke as a separate search event." Real user behaviour, measured honestly, matters more than impressive raw numbers.
Stock indicators hidden from public consumers
Stock visibility was gated behind authentication — a May commit hid stock indicators for non-logged-in consumers on the second store instance. The business decides what the public sees.
Want something built like this?
This is how we work: in the open, measured, honest about the dead ends.