Safely manage your Zendesk from the AI assistant you already use, via the Deltastring MCP. Beacon configuration platform
← Back to news

Building in public

The "building in public" philosophy represents a deliberate rejection of stealth development in favour of transparent product iteration exposed to market scrutiny. This approach forces founders and product teams to confront their assumptions early, iterate based on real feedback rather than internal consensus, and maintain accountability to their audience throughout the development cycle. For CX professionals, this matters because it signals a shift in how vendors—particularly smaller, emerging players in the support and customer experience space—are approaching product development. Rather than launching fully-formed solutions, these builders are inviting their users into the messy, iterative process itself, which fundamentally changes the relationship between vendor and customer.

The implications for CX teams are twofold. First, this transparency creates an opportunity to influence product direction before solutions become entrenched in your workflows. Teams adopting tools from builders operating publicly gain visibility into roadmaps and can advocate for features that solve their specific problems before they're baked into architecture. However, this also introduces risk: what happens when a publicly-built product pivots significantly, as evidenced by the shift from AI-driven configuration automation to alternative solutions? Teams must weigh the agility and responsiveness of emerging vendors against the stability guarantees of established platforms. For organisations already invested in Zendesk or Salesforce, the question becomes whether the innovation velocity of public builders justifies the switching costs and integration overhead, or whether the predictability of mature platforms remains the safer bet despite their slower iteration cycles.

The broader tension here concerns market maturity and customer readiness. Building in public works when your audience has the sophistication to evaluate unfinished products and the tolerance for change. Yet many CX teams operate under constraints—compliance requirements, change management protocols, stakeholder sign-offs—that make participating in early-stage development impractical. This creates a bifurcated market where innovative, hands-on teams can shape emerging tools whilst risk-averse organisations remain locked into established vendors, potentially widening the gap between cutting-edge practice and operational reality in customer support.