Skip to content
Birdhouse

Guiding Principles

Birdhouse exists to let non-technical teams build visual aspects of the Feather app without engineering involvement. But not everything belongs in a CMS. These three principles guide decisions about what to make configurable, when, and how.

Reusability is a priority

Section titled “Reusability is a priority”

Visual building blocks should serve multiple use cases. A new question type should work for more than one vertical. A new policy page section should be generic enough that other verticals can use it too.

The risk of introducing one-off functionality is bloating Strapi with exceptions and confusing users who expect consistency. If something cannot be built in a flexible, generic, reusable way, consider alternatives:

  • Build entirely in code — like Private Health pre-signup (Oct 2025), where the flow was too unique to fit existing building blocks
  • Hybrid solutions — like the Household quote screen (Aug 2025), where part of the page was driven by Strapi and part was custom code

One-off Strapi components create long-term maintenance burden. A reusable component that works across verticals is worth more than a bespoke one that ships faster for a single case.

First build the “classic way”, then generalise and automate

Section titled “First build the “classic way”, then generalise and automate”

When starting on a new area, build it in code first to understand the patterns before making it configurable in Strapi.

The questionnaire builder is a good example of this principle in action. Many verticals had already been built entirely in code before Birdhouse existed. This gave the team clear patterns to generalize: what a question looks like, how rules work, what screens are needed. When it came time to make questionnaires configurable, the building blocks were already well understood.

Jumping to Strapi configuration too early risks building something that is not truly reusable. You end up with a CMS model shaped around one specific use case rather than the general pattern. The cost of reworking a CMS schema (and migrating existing content) is higher than refactoring code.

The sequence matters: code first, then patterns, then CMS configuration.

Not everything that could be configured in Strapi should be

Section titled “Not everything that could be configured in Strapi should be”

Birdhouse works well for simple inputs: picking visual assets, updating text and URLs, using true/false toggles. Even moderately complex logic like questionnaire rules is supported because the patterns are well understood and the building blocks are mature.

But not every part of the frontend can or should be configurable by non-technical teams. Some things belong in code:

  • Logic that depends on runtime data (API responses, user state, feature flags)
  • Interactions that require custom UI behaviour beyond what existing components offer
  • Flows where the number of edge cases makes a visual editor more confusing than helpful

The goal is not to eliminate code from the product — it is to move the right things into the CMS so that the people closest to the business problem can iterate without waiting for engineering.

See also

Section titled “See also”