Every engineering team eventually runs into the same discussion.
“Should we build it, or should we buy it?”
Recently we had to redesign the search experience for a WooCommerce store with roughly 800 products spread across excavator buckets, hydraulic thumbs, couplers, and heavy equipment attachments.
The existing search did its job… technically.
In reality, it behaved exactly like the default WooCommerce search:
- No typo tolerance
- No SKU lookup
- Slow AJAX requests
- Alphabetical ordering instead of relevance
- No insight into what customers were actually searching for
The business goal was simple:
- Make search feel more like Amazon.
- Suggestions should appear instantly while typing.
- Misspelled words should still find products.
- Known SKU numbers should work.
- Customers should reach the correct product with as few clicks as possible.
Naturally, the first proposal was:
“Let’s use Algolia.”
Honestly, I wasn’t against the idea.
Algolia is an excellent product, and sometimes paying for a mature SaaS solution is the smartest engineering decision you can make.
The proposal was straightforward: connect Algolia using a premium WooCommerce integration plugin (around $100) and move on.
Fast.
Reliable.
Low risk.
The only thing I asked for was one day.
One day to investigate whether our problem actually required that much infrastructure.
If the experiment failed, we’d proceed with Algolia—although, in our case, I would probably integrate directly with its API instead of introducing another plugin layer.
That felt like a reasonable compromise.
After digging through documentation, older engineering discussions, benchmark articles, and experimenting with several architectures, something became obvious.
Our catalog contains around 800 products.
That’s… not a huge dataset.
Compressed, the searchable product index is only a few dozen kilobytes.
Small enough to download once.
Small enough to keep entirely in the browser.
Small enough to search locally in just a few milliseconds.
At that point, the architecture almost designed itself.
Instead of sending an AJAX request on every keystroke—or outsourcing every search to a third-party service—we could load the index once and perform autocomplete entirely on the client.
The server would only handle the more advanced search panel.
After the prototype was finished, the results were surprisingly good.
Autocomplete became almost instant.
Typos started working.
SKU searches worked.
The server stopped processing every single key press.
Most importantly, the experience simply felt better.
The prototype was convincing enough that we decided to continue improving the custom solution instead of introducing Algolia—for now.
That decision wasn’t about saving the cost of a plugin.
It was about choosing the simplest architecture that solved today’s problem while keeping the door open for tomorrow.
If the catalog eventually grows to five, ten, or twenty thousand products, Algolia—or another dedicated search platform—may absolutely become the right choice.
Good architecture isn’t about avoiding external services.
It’s about knowing when you actually need them.
What we delivered
- Instant autocomplete after typing just two characters.
- Fuzzy search that tolerates common spelling mistakes.
- Partial SKU search.
- Product suggestions including image, SKU, and price.
- Direct navigation from suggestions to product pages.
- Better relevance ranking for the main search.
- Client-side autocomplete with virtually no server load while typing.
- Automatic search index regeneration whenever products are updated.
- Search analytics that already log zero-result searches for future improvements.
- Mobile-specific behavior that keeps the interface clean.
What’s next?
The interesting part is that search is no longer just a search box.
It has become a source of customer behavior.
Every search term is already being recorded.
The next iteration will include:
- a dashboard showing the most searched keywords,
- zero-result reports,
- click-through statistics,
- and an intelligent synonym system that learns from real customer searches.
If dozens of customers search for “thumb” but the catalog uses “hydraulic thumb attachment,” the system will eventually learn that relationship automatically.
That’s where search starts becoming genuinely useful—not because it’s technically impressive, but because it continuously improves from real user behavior.
Sometimes buying software is the right answer.
Sometimes spending a single day validating an assumption leads to a simpler, faster, and more maintainable solution.
This time, the experiment was worth it.
Cred că cel mai important lucru pe care l-am luat din această experiență este că întrebarea nu era „Algolia sau custom?”, ci „care este cea mai potrivită soluție pentru problema și dimensiunea proiectului de astăzi?”. Asta este ideea care rămâne cu cititorul și deschide natural calea către articolul tehnic despre implementare.