No-code B2B product finder
Category-specific search that the product team builds themselves — plus a quote and sample flow that captures the lead.
The problem we were handed.
Buyers needed to search, filter and request quotes or samples for networking components — and the team needed to build category-specific search without developers.
Networking components don't share a spec sheet. A managed switch is chosen on port count, PoE budget and uplink type. A patch cable is chosen on gauge, shielding and jacket rating. A transceiver is chosen on reach, wavelength and form factor. One filter set can serve exactly one of those well, and every new category meant a ticket, a sprint and a deploy before buyers could search it.
Search also stopped short of the thing that mattered. A buyer would narrow the catalog to the four parts that fit, then land on a generic contact form and retype half of what they had just filtered. The intent was there and the system threw it away.
And nobody could share a result. Reps were describing filter combinations in email, or sending screenshots, because there was no link that carried the state of a search from a call into an inbox.
How we built it.
A Slim + Angular finder with a drag-and-drop filter designer, a quote/sample/support cart, third-party API sync and shareable pre-filtered URLs.
Drag-and-drop filter designer
A no-code surface where the product team composes the filter set for each category. Filter controls — range slider, multi-select, toggle, lookup — get dragged into an order, bound to a catalog attribute, and published. No deploy, no ticket, no developer.
- Filter definitions stored as data, not as code
- Draft and publish states, so a half-built layout never reaches buyers
- Attribute bindings validated against the live catalog before publish
A catalog model that survives new categories
Rather than a column per specification, the schema treats attributes as rows with declared types. Adding a category becomes data entry instead of a migration — which is the only reason the no-code designer works at all. Typed attributes are what let a range slider know it can do arithmetic and a facet know it can count.
- Attribute-per-row storage in MySQL, indexed for filter queries
- Numeric, enum and boolean types so ranges and facets behave correctly
- New categories added without a schema change or a release
Sync from the third-party source of truth
The catalog was never ours to own. A scheduled sync pulls products and their attributes from the client's third-party API into a read model the finder queries, so a correction made upstream reaches buyers without anyone re-importing a spreadsheet.
- Idempotent sync — safe to re-run, safe to resume mid-batch
- Changes reconciled against the read model rather than wiped and reloaded
- Sync failures surfaced loudly instead of quietly serving stale data
Quote, sample and support cart
Filtering is half the job. Buyers collect parts into a cart and send it as a quote request, a sample request or a support question — one flow, three intents. The submission carries the parts and the filters that found them, so the reply doesn't open with twenty questions the buyer already answered.
- One cart, three request types, one submission path
- Requests land as structured leads, not free text in a mailbox
- Filter context attached to every submission
Shareable pre-filtered URLs
Every filter state is encoded in the URL. A rep narrows the catalog live on a call and pastes the link into the follow-up; the buyer opens exactly that result set. The same links do duty as campaign landing pages and as sales collateral.
- Filter state serialized into a readable query string
- Retired or renamed filters degrade gracefully instead of erroring
- Links stay bookmarkable after a category's filter set is edited
Architecture & integrations.
What it delivered.
The interesting part of this build isn't the search. It's that the search stopped being an engineering dependency. Once the product team can shape a category's filters in an afternoon and hand the result to a buyer as a link, the catalog stops being something that gets revisited once a quarter — and starts behaving like the sales tool it was always supposed to be.
Questions this project raises.
That was the point of this build. Controls — range slider, multi-select, toggle, lookup — get dragged into an order, bound to a catalog attribute, and published behind draft and live states. No ticket, no deploy, no developer in the loop.
Attributes are stored as typed rows rather than a column per specification, so adding a category is data entry. Declared numeric, enum and boolean types are what let a range slider do arithmetic and a facet count correctly — the designer works only because of that.
The sync is idempotent and resumable, reconciling changes against the read model rather than wiping and reloading it, and failures surface loudly instead of quietly serving stale data. The client's system stayed the record; the finder only queries a copy.
Usually. It's an Angular front end over a REST API, so it mounts on a route of your main domain or inside an existing WordPress, Shopify or HubSpot build, with your header, footer and analytics left intact.
Designer first, then catalog and sync, then the cart — so the first category is usable before the rest are configured. Scope tracks category count and source-data quality. We can also build it white-label under NDA, so your client only ever sees you.
Related work.
Have a problem shaped like this one?
Tell us what's in the way. You'll hear back from a senior engineer within one business day.