The Bridge Problem
Here's how traditional internal tool platforms work:
Every request your team makes flows through the platform's middleware. That middleware has to authenticate, route, log, and proxy each call. The more users you have, the more traffic hits their bridge. The more traffic hits their bridge, the more infrastructure they need.
The result? They charge per user because every user costs them money.
It's not greed — it's architecture. When your platform is in the middle of every request, user count directly drives infrastructure cost. Per-seat pricing is the natural business model for bridge-based platforms.
What "No Bridge" Actually Means
Build0 takes a different approach to how your apps connect to services.
Direct credential injection: When you connect a service - Stripe, HubSpot, Slack, Supabase - Build0 doesn't become a permanent middleman. Your credentials are encrypted (AES-256-GCM), stored securely, and injected directly into your app's runtime at execution time.
Your app talks to Stripe. Not Build0-talks-to-Stripe-on-behalf-of-your-app.
What Build0 handles:
Securely storing and encrypting your credentials
Injecting them at runtime so your app can authenticate
Hosting and serving your application
Managing who can build and who can view
*What Build0 doesn't do:**
Sit between every API call your app makes
Proxy database queries through a middleware layer
Meter traffic per user through a bridge
How This Works Under the Hood
Build0 supports three types of connections:
1. OAuth Integrations (via Nango)
For services like Slack, HubSpot, GitHub, Salesforce, and Shopify — Build0 uses Nango to handle the OAuth flow. Once authenticated, your app receives the access token directly.
You connect once. Your app calls the API directly with that token.
2. First-Party Databases (via Neon)
Every Build0 app can provision a PostgreSQL database through Neon. You get a real connection string - postgresql://user:pass@host:port/db - and your app queries the database directly.
No query proxy. No middleware translating your SQL. Direct PostgreSQL access.
3. Manual Credentials
For any service not covered by OAuth - custom APIs, internal services, legacy systems - you add credentials manually. They're encrypted with AES-256-GCM and injected at runtime.
Whether it's an API key, a bearer token, or a connection string, your app uses it directly.
Why This Changes Pricing
When your platform isn't proxying every request, user count stops being an infrastructure cost driver.
Bridge-based platform:
10 users × 50 requests/day = 500 requests through the bridge
100 users × 50 requests/day = 5,000 requests through the bridge
10x users = 10x infrastructure cost = 10x seat fees
Build0 (no bridge):
10 users hitting Stripe directly = Build0 serves 10 page loads
100 users hitting Stripe directly = Build0 serves 100 page loads
API traffic goes directly to Stripe, not through Build0
Build0 still has infrastructure costs - we host your apps, serve your frontend, manage your credentials. But those costs scale with the number of apps and deployments, not with how many people open them.
That's why we can offer capacity-based pricing.
Your 90 viewers on the Scale plan aren't generating 90x the infrastructure load on Build0. They're generating load on your connected services - which you're already paying for.
What This Means in Practice
Support Dashboard Connected to Stripe
Your support team needs to look up customers and issue refunds. With a bridge-based platform, every lookup routes through their middleware to Stripe. 20 support agents making 50 lookups/day = 1,000 proxied API calls through the platform.
With Build0, those 1,000 calls go directly to Stripe. Build0 serves the dashboard UI and injects the Stripe API key. The platform's cost is serving 20 page loads, not proxying 1,000 API calls.
Operations Dashboard Connected to PostgreSQL
Your ops team needs real-time inventory data. With a bridge-based platform, every query routes through their SQL proxy. Sorting, filtering, refreshing — all through the middleware.
With Build0, your dashboard queries Neon PostgreSQL directly with the injected connection string. Build0 serves the app. The database handles the queries.
Approval Workflow Connected to HubSpot
Sales reps request discount approvals. Managers review and approve. On approval, HubSpot updates automatically.
The HubSpot API calls happen directly from your app. Build0 stores the workflow data in your app's database. The approval logic runs in your app's backend. Build0 provides the runtime - not a request bridge.
The Trade-offs (Let's Be Honest)
Direct connections mean your connected services see direct traffic. If your Stripe API has rate limits, your app hits those limits directly. A bridge-based platform might batch or cache requests for you. With Build0, you manage your own API consumption.
Build0 still hosts your applications. We're not a "deploy to your own infrastructure" solution. Your apps run on our servers, authentication goes through our system, and we serve every page load. We're eliminating the API bridge, not all infrastructure.
Credential security is critical. Because credentials are injected into your app's runtime, our encryption and access control must be airtight. We use AES-256-GCM encryption at rest, separate transit encryption for delivery, and role-based access to ensure only authorized apps receive credentials.
Why Bridge-Based Platforms Can't Easily Change
It's worth understanding why this isn't just a pricing decision for bridge-based platforms.
Their middleware does real work:
Query translation - abstracting database differences
Caching - reducing load on downstream services
Audit logging - tracking every data access
Permissions - enforcing row-level and field-level security at the proxy layer
These are valuable features. But they come with a cost structure that scales with users and requests. Moving away from bridge architecture would mean rethinking their entire platform - not just changing a pricing page.
Build0 chose a different starting point. We handle permissions at the app level, logging through our analytics layer, and let your services handle their own query optimization.
The Bigger Picture
The bridge model made sense when internal tools were complex enterprise deployments that needed heavy middleware. But the landscape has changed:
Managed databases (Neon, Supabase, PlanetScale) handle their own scaling and security
API platforms (Stripe, HubSpot, Shopify) handle their own auth, rate limiting, and reliability
OAuth providers (Nango, WorkOS) handle secure token management
The services you connect to have gotten good enough that a middleware bridge adds cost without proportional value. Your Stripe API doesn't need a middleman. Your PostgreSQL database doesn't need a query proxy.
Build0 is built for this reality. Connect your services directly. Let them do what they're good at. Pay for the platform that builds and hosts your tools — not for a bridge you don't need.
The Bottom Line
Per-seat pricing in internal tools isn't a business choice - it's an architectural consequence. When your platform bridges every request, every user is a cost center.
Build0 eliminates the bridge. Your apps connect directly to your services with securely injected credentials. Our costs scale with what you build, not with who uses it.
The result: you build tools and share them freely. No viewer tax. No per-seat penalties. No bridge.
