Hidden Complexity: How a Simple Survey Product Became 167 Endpoints

A deep dive into Formbricks reveals how a six-endpoint survey widget expands to 167. This growth highlights the unseen infrastructure required for real-world SaaS products.

The dev.to post by devto author David Moores claims a survey widget, which appears to be a six-endpoint feature, expands to a 167-endpoint product when built for real-world use. This discrepancy, highlighted through an analysis of the open-source Formbricks project, underscores the often-underestimated backend complexity inherent in seemingly simple SaaS offerings. Founders frequently miscalculate the infrastructure required to move from a core function to a robust, scalable product.

The Weekend Project: Six Endpoints

The core functionality of a "How was your experience?" survey widget, as initially conceived, involves a minimal set of API interactions. The author identifies six endpoints within Formbricks that handle fetching surveys, displaying them, and collecting responses. These include GET /api/v1/client/:workspaceId/environment for survey retrieval, POST /api/v1/client/:workspaceId/displays to register a display, and POST /api/v1/client/:workspaceId/responses for submitting answers. This initial scope aligns with a basic proof-of-concept.

Browser Physics and API Versioning Quadruple the Count

The transition from a local proof-of-concept to a production-grade product operating across various client websites introduces immediate complexity. Browser security protocols, specifically Cross-Origin Resource Sharing (CORS), necessitate OPTIONS preflight requests for nearly every client-facing endpoint. This requirement alone duplicates much of the client API surface. Furthermore, the need to support installed SDKs on external websites means API versions cannot be deprecated quickly. Formbricks, the author reports, maintains both v1 and v2 of its client API concurrently, effectively doubling the client-side surface. These factors, without adding a single new feature, expand the initial six endpoints to 27, according to the post.

Management APIs for Real Teams

Once a product moves beyond basic user interaction, real-world teams require programmatic access to manage their data and configurations. The Formbricks project includes a comprehensive management API that mirrors the UI's capabilities. This involves standard Create, Read, Update, and Delete (CRUD) operations for core entities such as surveys, responses, contacts, contact attributes, webhooks, and file storage. These management endpoints, also spread across v1 and v2, contribute 46 endpoints to the total, representing over a quarter of the entire API surface. This layer, though invisible to the end-user, is critical for operational use.

Future-Proofing with a V3 API

The Formbricks codebase also reveals a newer v3 API, which the author identifies as containing an additional 20 endpoints. This version introduces features like POST /api/v3/surveys/generate, survey templates, validation, and a feedback-classification pipeline. This v3 API indicates a strategic investment in future capabilities, particularly those related to AI and advanced analytics, suggesting an ongoing expansion of the product's scope beyond its initial survey collection function.

What We'd Change

The Formbricks case study, as presented, illustrates a common pitfall: underestimating the “product around the thing.” Founders often scope based on core functionality, neglecting the operational, compatibility, and future-proofing layers. This leads to significant technical debt or scope creep if not anticipated.

For new projects, a deliberate architectural decision should be made regarding API versioning from day one. While supporting multiple versions indefinitely is necessary for client-side SDKs, a clear deprecation strategy for internal or server-to-server APIs can mitigate endpoint sprawl. Furthermore, the management API layer, which accounts for a substantial portion of Formbricks' endpoints, is often a prime candidate for build-vs-buy analysis. For non-core functionalities like user authentication, file storage, or even complex webhook management, leveraging existing third-party services can reduce initial build complexity and ongoing maintenance.

The expansion to 167 endpoints, while seemingly large, reflects the reality of building a robust, extensible SaaS. The “weekend project” mentality fails to account for browser physics, the need for backward compatibility, and the extensive management interfaces required by professional users. Founders should allocate significant engineering resources to these “invisible” layers, or risk a product that is brittle, hard to maintain, or impossible to integrate programmatically.

Landing

The Formbricks example demonstrates that the difference between a functional prototype and a production-grade SaaS is not merely feature expansion, but a fundamental increase in infrastructural surface area. The journey from six endpoints to 167 for a “simple” survey product reveals that the true cost of software lies not just in its visible features, but in the unseen layers of compatibility, management, and future extensibility that enable it to operate reliably in the real world.

The investor read

The Formbricks case signals that even “simple” SaaS products carry significant hidden technical debt and operational overhead. Investors should scrutinize architectural choices, particularly around API versioning and management interfaces, during due diligence. Products that effectively abstract away this complexity, or provide robust, well-documented APIs for integration, are more defensible. The growth from 6 to 167 endpoints highlights the cost of building a comprehensive platform versus a feature, suggesting a higher capital requirement for seemingly straightforward solutions. This also points to opportunities for infrastructure plays that simplify common SaaS challenges like API management and versioning.