Building the front door to a Business OS

By the time we started this work, a merchant trying to find a customer, check a transaction, or locate a product they had listed had to already know which section of Mainstack that information lived in. There was no single place to just ask. Global Search was built to be that place, the first foundational, cross-platform capability of V4, not tied to any one product.

Merchants could not find business information without knowing, in advance, which module it lived in.

That sounds like a small inconvenience until you watch someone actually do it. A merchant trying to confirm whether “Adaeze” paid her invoice has to guess: is that under Payments, Transactions, or Invoices? A merchant looking for the course they titled “Intro to Baking” has to remember it lives under Products, then navigate there, then scroll or filter. None of this is hard, individually. It is just friction, repeated dozens of times a week, for the people actively running their business through the platform.

This was invisible in demos, where you show one flow at a time. It only shows up when you watch someone try to actually run their business day to day, and realise how much of that time is spent navigating, not doing.

I owned this end to end as the senior product designer driving search for Mainstack V4: framing the problem, defining what Phase 1 would and would not cover, designing the interaction model, and writing the PRD that Engineering, Product and QA built from. I worked closely with engineering throughout, particularly on scoping decisions that had real technical weight behind them, like how result pagination should behave and what “Products” actually means inside Mainstack's data model.

The instinct with a first version of search is to build the whole thing: every entity, a command palette, filters, saved searches. I pushed back on that early, deliberately. The story we told was not “we are adding search.” It was: as Mainstack becomes a Business OS, merchants need one consistent way to find information across the platform, without learning where everything lives.

That reframing mattered because it turned a feature request into platform infrastructure, and it gave me permission to say no to almost everything in the first version. Phase 1 needed to prove the pattern with the three things merchants look up constantly: Contacts, Transactions and Products. Everything else, communities, payment links, invoices, commands, natural language, got an explicit “not yet” instead of a vague “eventually.”

The hardest part of this project was not any single screen, it was staying disciplined about what search would not do yet.

Every conversation about search pulls toward the command palette version: type anything, do anything, from anywhere. That is genuinely the long-term vision, and I believe in it. But building toward it in one shot would have meant shipping something half-finished across ten surfaces instead of something complete across three. I drew a hard non-goals list into the PRD itself, no communities, no payment links, no invoices, no commands, no filters, no AI-assisted query interpretation, in Phase 1, and defended it through several rounds of “can we just also add...” conversations. The keyboard shortcut is a good example: Cmd+K felt like an obvious Phase 1 addition until we were honest that it is a command-palette-shaped feature, and belongs with the rest of that work in Phase 3, not bolted onto a foundation release.

The other genuinely hard part was pagination, which sounds like a small technical detail until you realise it shapes the entire tab-switching interaction. I pushed against infinite scroll here, even though it is the obvious default for a browse-more pattern. Inside a modal, an open-ended scroll makes it easy to lose your place, and it fights with the keyboard navigation we had already committed to, arrow keys and scroll position drift apart the moment results load continuously underneath you. We landed on a simple Load more button instead: each batch of results is predictable, a merchant always knows roughly how much more there is, and it is a discrete, trackable action instead of a scroll-position trigger that is noisy to instrument. Less flashy than infinite scroll, more honest about what a search modal actually needs to do.

Global Search shipped as the first foundational capability of Mainstack V4, in full Phase 1 scope, Contacts, Transactions and Products, searchable from anywhere in the platform, no longer contingent on a merchant remembering which module a piece of information lives in.

It is early days in production, so I am not going to dress this section up with numbers that do not exist yet. What I can say is that the metrics were not an afterthought: search adoption, search-to-result click rate, time to first result and zero-result rate were all defined in the PRD before launch, not chosen after the fact to fit a good-looking story. Zero-result rate in particular is the one I am watching closest, since a high rate this early would tell us merchants are searching for things outside Phase 1's scope, a direct, useful signal for what Phase 2 should prioritise first.

Phase 1 was deliberately narrow so Phase 2 and 3 have somewhere solid to build from. Phase 2 extends search to Invoices, Payment Links and likely Communities, and adds search history (the last five searches, scoped per account) to the pre-query state alongside Quick Actions. Phase 3 is the command palette: actions and commands executable directly from search, filters, saved searches, and the Cmd+K shortcut that got cut from this version for good reason. Getting the foundation right, tab structure, scope discipline, an empty state that never dead-ends, is what makes that roadmap buildable instead of aspirational.