The feature engine

Every feature in the platform gets its own page, and the list re-shelves itself around how the visitor is thinking — by area of the business, by what's going wrong, by what they'd gain, by system, or A–Z.

What it is

A server-rendered explorer over the full feature registry with six lenses and a generous free-text search, plus one statically generated page per feature. Each feature carries the problem it solves, the pain points in a builder's own words, the benefits, how it works, why it was built, and the code it traces to. Every view is linkable, because the state lives in the URL.

Also called: feature list · what does it do · capabilities page · search by problem

See it
The feature engine
CustomerBuildingAmountStatus
Marlin HooverEquipment Storage$11,080Sent
Delia YoderHobby Shop$6,710Approved
Ivy Brubaker40×64 Shop$3,100Sent
Sutter KlineBarndominium$1,580Approved
Marlin HooverRiding Arena$2,910Open
The explorer with the lens selector open and the same feature set re-grouping under 'By what's going wrong'. Rendered by src/components/features/FeatureExplorer.tsx. Sample data — no customer information appears here.
How it works
  1. 1The whole registry is server-rendered into the HTML so crawlers and slow connections see everything.
  2. 2Six lenses re-group the same set: category, pain point, benefit, problem, system, A–Z.
  3. 3On the three problem-shaped lenses a feature appears under EVERY pain it addresses, not just a primary one.
  4. 4Search weights name, aka, pain points and problems, and requires every term to appear somewhere, so a two-word query narrows rather than widens.
  5. 5Lens, query and focus are written to the URL with replaceState, so a view can be sent as a link without filling the back button.
  6. 6Feature pages are statically generated across the whole registry with canonical URLs and OpenGraph metadata.
Why we built it

Keith's brief is quoted in the component: "The feature list page again should be expansive, but categorizing how they want and in all the different ways that they may want… almost like a table that transforms based on the type of way they want to interact with it." The central insight is his example: "not many people may think to search for permitting issues, but they may search losing jobs because of permits." And the URL-state decision has a field reason: "the cold-calling rep's whole job is to answer 'can it do X?' with a link that lands on exactly the answer. A view that cannot be sent is a view that cannot be used in the field."

The problem
  • Visitors arrive holding a problem, not a feature name.
  • A single fixed categorisation hides features from half the people they are for.
  • A filtered view that cannot be linked is useless to a salesperson.
Sound familiar?
What you get
Search by the words you'd actually type, not the feature's name
The same list re-shelves five different ways
Any view can be sent as a link that lands exactly there
What's inside

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →