How 12 Products Share One Platform

The SnapIT ecosystem includes a form builder, QR code generator, link shortener, analytics platform, AI agent, SaaS portal, and more. They each have their own domain, their own frontend, and their own personality. But underneath, they all run on SnapIt Software -- a shared platform that handles authentication, billing, and cross-product data flow. This is both the biggest advantage and the biggest engineering challenge in the ecosystem.

One Login, Twelve Products

Users sign in once and have access to every SnapIT product their plan includes. This sounds simple, but shared authentication across independent products creates real complexity. Each product has its own domain, its own frontend application, and its own set of permissions. The authentication system needs to issue tokens that work across all of these while respecting product-specific access controls.

The approach is a centralized identity provider that every product trusts. When a user signs in through any SnapIT product, they authenticate against the shared identity layer. The resulting session token contains their identity, their tenant, and their role. Each product validates this token independently and maps the role to its own permission model. A user who is an admin in SnapIT Forms might be a viewer in SnapIT Analytics -- the shared identity tells each product who the user is, and the product decides what they can do.

Unified Billing Across Products

Billing for a multi-product platform is harder than billing for a single product. Customers want one invoice, not twelve. They want to add a product to their plan without re-entering payment information. They want to see their total spend across the ecosystem in one place.

SnapIt Software handles this with a single subscription record per tenant that includes all active products. Adding a product means updating the subscription, which triggers a prorated charge for the remainder of the billing cycle. Removing a product issues a prorated credit. The customer sees one line item per product on their invoice, but the billing system treats it as a single subscription with multiple components. This is managed through a payment processor that supports multi-line subscriptions natively, which avoids the nightmare of reconciling multiple independent subscriptions per customer.

When One Product Changes, Everything Ripples

The tightest coupling in the ecosystem is data flow. A form submitted through SnapIT Forms can trigger an analytics event in SnapIT Analytics, generate a short link through URL Unicorn, and send a notification through the core platform's email service. These integrations are configured as workflows -- event triggers connected to actions across products.

This means a change to any product's API can break integrations in products that depend on it. The mitigation is versioned APIs and a contract testing approach. Each product publishes the shape of its events and API responses. Before deploying a change, the platform verifies that existing integration contracts are not broken. If a breaking change is necessary, the old version continues to work alongside the new one until all dependent integrations are migrated.

The Trade-Off

A shared platform means faster development for new products -- authentication, billing, and hosting are already solved. But it also means every architectural decision affects twelve products instead of one. Adding a feature to the shared layer requires considering how it interacts with each product. The discipline required to maintain this shared foundation is the real cost, and it is worth it because the alternative -- twelve independent stacks with twelve login systems and twelve billing integrations -- would be far more expensive to maintain.