Can a product build only its UI and use third-party services for everything else?
A product can and often should buy standardized capabilities, but a production system generally cannot be only a UI. A controlled business backend still owns identity, permissions, orders and state, secrets, billing, audit, and failure handling. Payments, messaging, maps, storage, and models then connect through adapters.
UI-only is appropriate for a demonstration with no real accounts or transactions, or a white-label platform that already supplies a complete backend. Once the product contains user data, orders, payments, entitlements, enterprise knowledge, or device control, direct browser/app calls expose keys, fragment authorization, and cannot protect state during provider timeout, duplicate callbacks, price changes, or retirement.
When decomposing features, data, and acceptance scenarios, also compare When does custom software provide more value than an existing SaaS product?; the linked guidance adds context that should be considered in the same decision.
| Model | Internal ownership | Advantage | Main risk | Fit |
|---|---|---|---|---|
| UI plus a complete third-party backend | Pages, brand, limited configuration | Fastest release | Data model, roadmap, and exit depend on platform | Prototype or white-label product |
| UI plus business backend plus third-party capabilities | Users, permissions, workflow, facts, adapters | Balanced speed and control | Integration and bills still need operations | Default for most production products |
| Build differentiating core and buy commodity services | Core algorithm or business engine also internal | Strongest roadmap and data control | Highest engineering, compliance, operations | Only when the core is a real advantage |
Payments, SMS/email, maps, object storage, CDN, push, audio/video, OCR, and model inference have standardization, regulation, or scale effects that rarely reward rebuilding. The product should retain accounts and organization, permissions, core facts, pricing and entitlement, review policy, customer data, supplier-routing logic, and cross-service exception handling.
The backend hides permanent credentials and establishes trust. A client receives a short-lived user token and requests the business backend, which checks tenant, role, object, and allowance before calling a provider. Payment callbacks verify signature and idempotency; model requests remove unrelated personal information; messaging enforces frequency and approved templates; map keys are restricted by domain or app signature. Obfuscation cannot secure a permanent key embedded in Web, app, or mini-program code.
Create a capability and exit card for each supplier: service, region, retention or training use, subprocessors, SLA, limits, price/minimum, account owner, licence, incidents, export, retirement, and replacement. Open-source components record versions and licences, with SPDX identifiers where useful. Update both contract and engineering inventory.
Not every service needs two providers. Abstraction and backup are valuable for high-impact payments, messaging, storage, or critical models. If providers have materially different semantics, a theoretical one-click switch creates a lowest-common-denominator design and twice the tests. Set recovery needs first: a low-risk map lookup may wait, peak transaction messages may need a backup, and core data storage needs independent backups and a migration exercise.
Adapters convert supplier input/output into a stable internal model and retain request ID, version, latency, cost, and error category. OpenAPI can document the internal contract. A timeout must distinguish unknown, failed, and confirmed outcome so retry does not double-charge. Queues, circuit breaking, caching, and human fallback vary by risk.
Compare three-year volume bands. APIs are usually cheapest at low use; per-call charges may later exceed dedicated or packaged capacity. Include network, storage, review, support, and channel fees. Wavesteam separates provider fees from engineering and opens critical accounts under the client entity, following the Transparent Delivery Standard.
Acceptance includes normal calls, denial, limits, timeout, duplicate callback, malformed responses, insufficient balance, and outage. The UI must explain state, records must not duplicate, logs must diagnose, and work must fall back safely. Wavesteam recommends an owned business core with sensible purchased capabilities rather than maximizing custom development.