From Single App to Multi-App Platform
Every platform that serves multiple businesses started as something more specific. An invoicing tool for one industry. A project management app for one type of team. A CRM for one sales methodology. At some point, the decision gets made: stay specific and go deep, or go generic and go wide.
We made the generic choice. Here's why.
What We Saw in Specific Apps
Specialized applications are excellent at their core use case. An invoicing tool is great at invoicing. A project management tool is great at project management. The problem is that most businesses aren't doing just one thing.
A services business manages projects and invoices and contracts and client relationships and team capacity. Each of these domains has specialized tools built for it — but the relationships between them matter enormously, and specialized tools don't model those relationships well.
The data lives in four systems. Updates happen in one and don't propagate to others. Reporting requires manual aggregation. The workflow that spans invoicing and project completion requires humans to hand off between systems.
The Platform Hypothesis
A configurable platform can model your entire operation — not just one domain — and maintain the relationships between domains. A project links to its invoices. An invoice links to the contract it's based on. The contract links to the client. The client links to all their projects.
That web of relationships is your business data, and it needs to live in one place to be useful.
What Generic Actually Means
Going generic doesn't mean going shallow. A generic platform needs to be deep enough that it can model specialized domains well — not just store arbitrary data, but model invoices with proper line items and VAT handling, model projects with tasks and milestones, model support queues with SLA tracking.
The platform provides the infrastructure; the configuration defines the domain model. Generic infrastructure, specific implementations.
The Cost of the Decision
Going generic is harder to build. It's harder to market — "we do everything" is a harder story to tell than "we do invoicing perfectly." It requires building flexible primitives that can be assembled into specific behaviors, rather than hardcoding the specific behaviors.
We made the decision anyway, because the alternative — building another specialized tool for one domain — didn't solve the problem we actually cared about. Business operations span domains. The platform should too.