Introduction
When you decide to properly build out a set of frequently asked questions (FAQ), the first thing most people reach for is a dedicated FAQ SaaS.
It is quick to set up, but once you try to embed it into an EC site, problems surface: "the design feels out of place," "search behaves differently," "we can't reuse it across sites."
In this article, I explain why I built the FAQ in-house rather than relying on an external SaaS for an apparel and gear EC site, and what the overall design looks like. It organizes 100-plus questions into about ten categories and handles search, an admin UI, and cross-site deployment entirely on our own.
Why In-House Instead of SaaS
A Unified Feel for Design and Search
A SaaS FAQ always ends up looking like "that one part runs on a different service." The fonts and buttons differ slightly, and the search box works as something separate from the main site. Individually these are minor, but pile them up and users start to feel the site is "hard to search." Building in-house means assembling the FAQ from the same components as the product pages, and making search results continuous with on-site search. That unified feel is my single biggest reason for going in-house.
Cost and Multi-Site Deployment
FAQ SaaS often charges by inquiry volume or page views, so costs balloon as you add sites. In my environment there were several sister EC sites, and I wanted to roll out the same FAQ foundation across all of them. In-house, a system built once can simply be dropped onto another site, with almost no added cost beyond hosting. Over the long run that came in cheaper than stacking up monthly SaaS fees.
Keeping It as a Content Asset in Your Own Hands
An FAQ is a tool for reducing inquiries, but it is also a content asset that draws traffic from search engines. Hand it to a SaaS and you lose control over URL structure and structured data, dropping your SEO flexibility. Keep it on your own site and you design the category URLs and heading structure yourself, so the FAQ itself becomes an entry point for acquisition. The peace of mind of having the data in your own hands is significant, too.
Fast to set up, but the design feels off, search is separate, and cost grows as you add sites
Built from the same components as product pages, search is unified, and multi-site rollout is low-cost
The Full Picture of an In-House FAQ
Data in JSON, Delivery via KV
The FAQ content is managed as per-category JSON files. On the development side these are handled in Git, while production delivery comes from a fast key-value store (Vercel KV) — a two-tier setup. Holding JSON as the source of truth while serving from KV keeps display fast and management easy at the same time. The straightforward UI of per-category pages with accordions was only feasible because of this lightweight data structure.
Inline Search Powered by a Search Index
Hunting through 100-plus questions by opening one category at a time isn't realistic. So I built a search index (search-index) spanning all FAQs and added inline search that narrows candidates on the fly as you type. Users reach the right FAQ across categories just by typing part of their question. I cover how this search is built in the next article.
~10 categories, 100+ questions (managed in Git)
Production delivery data
For cross-category search
Per-category pages, accordions, contact flow
Balancing "Staff Edit, Developers Review"
Two Editing Paths
A common conflict in FAQ operations is "staff want to fix things immediately" versus "developers want to manage the data." In my design, floor staff can edit FAQs directly from an OTP-authenticated admin UI, while developers manage the JSON in Git. The two are synced bidirectionally with KV via push/pull scripts (faq-push / faq-pull). Whichever path you edit from, the data ultimately converges into one.
The Same Mechanism Across Sites
The sister EC sites run this same in-house FAQ as-is. Because the data structure, admin UI, and search are shared, there is no need to rebuild per site. When launching a new site, you just prepare the category JSON and sync it to deliver the same quality of FAQ experience. Building the mechanism properly once really pays off in these rollout moments, doesn't it?
What In-House Gave Us
A unified design, easy-to-use search, painless multi-site rollout, and SEO value as a content asset. In-house lets you hold all of these — hard to get from a SaaS — in your own hands at once.
Conclusion
The reasons for building the FAQ in-house come down to four points: a unified feel for design and search, cost, multi-site deployment, and value as a content asset. It's not a flashy feature, but this humble foundation keeps paying off for both inquiry reduction and acquisition over the long run.
This theme is explored further in the three articles below.
FAQ Data Management and Search Index with JSON + KV
Covers how to hold per-category JSON and how to build the search index behind cross-category search.
Admin-UI Editing with Git-Based Sync
Staff edit in the admin UI, developers manage in Git — explaining how push/pull keeps both in sync.
Connecting FAQ to the Contact Flow to Reduce CS Load
Explains the flow design that places FAQ search before the contact form to encourage self-service.