--- title: Technology and SaaS Platform Development description: url: https://miracuves.com/industries/technology-saas date_modified: 2026-08-17 author: miracuves language: en_US --- # SaaS platforms, built around the one decision you cannot reverse cheaply. Multi-tenancy, entitlements and enterprise identity engineered from week one, because the tenancy model you pick decides your compliance story, your largest deal size and the cost of every migration afterwards. Fourteen SaaS and AI platforms already in production, and a custom engineering team for everything beyond them. [Talk to an engineer](https://miracuves.com/schedule-consultation/) [See what we've shipped](#shipped) Where this starts from **14**Platforms in production **8**Operator types served **2-8*wks***Custom build, scoped **6*days***Ready-made launch Tenancy decided inWeek one, not after the first enterprise deal Source codeYours, in full DeploymentYour infrastructure Support, fixes, updates60 days, 6 and 12 months *Isolation, identity and billing* · designed together, not bolted together Custom build Starting from a shipped platform Custom build - 2 to 8 weeks, scoped Tenancy Identity Billing and API Security evidence Scale limits Launch Ready-made platform - 6 working days Rebrand, deploy, live Six working days is the launch timeline for a ready-made platform as it ships - branded, deployed and live on infrastructure you own. Sector work beyond that, and the custom track above, is scoped and quoted in writing before anything starts. Both tracks are the same engineering team. Every figure on this page is defined on our [facts page](https://miracuves.com/facts/). ## What a SaaS build actually contains The sequence below is where SaaS platforms are won or lost. Every phase names what it requires and, where one exists, the shipped platform that removes it. This sector has a distinctive failure pattern. Almost nothing breaks at launch. Things break when the first customer arrives who is ten times larger than the others, wants single sign-on, asks where their data is stored, and requests an audit log covering the last twelve months. Every one of those is cheap to design for on day one and expensive to retrofit in year two. Three of the seven phases have no shortcut. What a shipped platform removes is the middle: identity, billing and the API surface, which together carry most of the build time and most of the security review afterwards. At a glance Phases7 With no shortcut3 Removed by a shipped platform3 Fixed regardless of trackTenancy, security evidence, launch **01**Weeks 1-2 ### Tenancy and the data isolation model Shared schema with a tenant column, a schema per tenant, or a database per tenant. The choice looks like an infrastructure preference and is actually a commercial one, because it decides which enterprise questions you can answer yes to and how much a regulated customer costs you to serve. Shared schema is cheapest to run and hardest to defend in a security review, because isolation depends on every query being correct forever. Database per tenant answers the isolation question immediately and turns migrations into a fleet operation. Most platforms should choose deliberately and support one exception rather than drifting into a hybrid nobody designed. Data residency belongs here too. If you will ever need to keep European data in Europe, the tenancy model has to carry region as a first-class attribute rather than a later migration. Isolation modelData residencyTenant lifecycleMigration story No shortcut here. Tenancy is the same problem on both tracks - and it is the single most expensive decision to reverse in this sector. **02**Weeks 2-3 ### Identity, single sign-on and permissions Consumer signup and enterprise identity are different products. The first is an email and a password. The second is SAML or OIDC against the customer's own provider, automated user provisioning and deprovisioning, and a permission model their security team will review line by line. The deprovisioning half is the one teams forget and auditors always check. When an employee leaves the customer's company, their access to your platform has to end without anybody remembering to do it manually. Permissions should be role-based from the start with resource scoping designed in. Retrofitting granular permissions onto a platform that assumed two roles is close to a rewrite of every authorization check. SAML and OIDCUser provisioningRole modelResource scoping **Already built**Enterprise identity with SSO, automated provisioning and a scoped role model.[Zoom Clone](https://miracuves.com/zoom-clone/) · [Dropbox Clone](https://miracuves.com/dropbox-clone/) · [Google Drive Clone](https://miracuves.com/google-drive-clone/) **03**Weeks 3-5 ### Billing, plans and entitlements Plans are marketing. Entitlements are engineering. The mistake almost every platform makes is scattering plan checks through the codebase, so that changing what a tier includes means finding twenty conditionals and hoping you found them all. An entitlement service that answers one question - can this tenant do this thing right now - keeps pricing changes out of the release cycle. That matters because pricing changes constantly in this sector, and a platform that needs a deployment to launch a new tier will lose the experiment. Usage metering is the harder half. If you bill on consumption, the meter is a financial record: it needs to be idempotent, reconcilable and defensible to a customer disputing a number. Entitlement serviceUsage meteringProrationDunning **Already built**Subscription billing with plans, entitlements and usage metering already separated from feature code.[Mailchimp Clone](https://miracuves.com/mailchimp-clone/) · [ActiveCampaign Clone](https://miracuves.com/activecampaign-clone/) **04**Weeks 4-6 ### API surface, webhooks and integrations The API is a product with its own lifecycle, and in B2B it is often the reason a deal closes. That means versioning decided before the first external consumer, not after, and a deprecation policy you can actually honour. Webhooks deserve the same care as ingestion did in other sectors: they will be retried, they will arrive out of order, and a customer whose endpoint was down for an hour will expect replay. Signing them and documenting the retry schedule is the difference between an integration partner and a support ticket. Rate limits are a product decision as much as a protection: too tight and you break integrations, too loose and one customer degrades everyone. API versioningSigned webhooksReplayRate limits **Already built**Versioned APIs with signed webhooks, replay and documented rate limits.[Wetransfer Clone](https://miracuves.com/wetransfer-clone/) · [Transfernow Clone](https://miracuves.com/transfernow-clone/) **05**Weeks 5-7 ### Security posture and the evidence for it Enterprise buyers do not ask whether you are secure, they ask you to prove it, and the proof is documentary. Audit logs covering who did what and when, retained long enough to answer a question about last year. Encryption at rest and in transit with the key management described. Access reviews that happened and can be shown to have happened. We build to the controls those frameworks require and generate the evidence continuously, which turns an audit into an export rather than a project. Where you are pursuing certification we support the process directly, because assembling evidence retrospectively is the expensive way to do it. Audit logKey managementAccess reviewEvidence retention No shortcut. Shipped platforms arrive with the audit trail and a VAPT report, but your framework, your retention period and your customers' questionnaires are yours to answer. **06**Weeks 7-8 ### Scale, limits and the noisy neighbour In a multi-tenant platform, one customer's bad afternoon becomes everyone's. A tenant running an unbounded export, an integration retrying in a tight loop, or a genuinely large account doing normal things at ten times the volume will all degrade the platform unless limits exist per tenant rather than globally. Fair queuing, per-tenant quotas and the ability to isolate a specific tenant onto its own capacity are the tools. The last one is also a commercial feature: the largest customers will pay for dedicated capacity, and a platform that can offer it has a product rather than an exception. Per-tenant quotasFair queuingDedicated capacityDegradation modes **Already built**Per-tenant quotas and isolation controls with defined degradation behaviour.[ChatGPT Clone](https://miracuves.com/chatgpt-clone/) · [Wix Clone](https://miracuves.com/wix-clone/) **07**Weeks 7-8 ### Launch and day two A design-partner cohort before general availability, because the questions that reshape a SaaS platform come from customers using it rather than from planning. The first enterprise prospect will produce a security questionnaire that is worth more than a quarter of roadmap guessing. Day two in this sector is about onboarding friction and support load, both of which are measurable from the first week. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates. Design partnersQuestionnaireActivation metricsDay two support No shortcut. Same on both tracks. A faster build does not shorten the learning that only paying customers produce. Want any of these phases costed against your own tenancy model? [Book a technical call](https://miracuves.com/schedule-consultation/) ## Where tenant data actually lives Three isolation models, three different answers to the questions an enterprise security review will ask. The choice is reversible only at the cost of a migration nobody enjoys, which is why it belongs in week one. At a glance Isolation models3 Cheapest to runShared schema Easiest to defendDatabase per tenant Decide byYour largest intended customer **Tenant isolation models**What each one buys, and what each one costs Shared schemaSchema per tenantDatabase per tenant One table, a tenant column Isolation depends on every query being correct, forever. Cheapest to run and to migrate. One database, many schemas A middle position. Isolation is structural, migrations are still one operation across the fleet. One database each Answers the isolation question immediately. Migrations become a fleet operation you must tool for. The questions each one answers Can one tenant ever see another's data? Can we keep this customer's data in their region? Can we restore one tenant without touching the rest? What does one more tenant cost to run? Only if every query is rightStructurallyStructurally With workWith workDirectly HardPossibleTrivially Almost nothingA littleMaterially more SharedSchemaDatabase Cheaper to operateEasier to defend Most platforms should pick one deliberately and support a single documented exception, usually a database-per-tenant tier for regulated customers. What breaks teams is drifting into a hybrid nobody designed, where half the queries assume one model and half assume another. ### Why entitlements belong in a service, not in the code The natural way to build plan limits is a conditional where the feature lives: if the tenant is on the professional tier, allow this. It works, and it quietly makes pricing a deployment concern. Six months later a change to what the professional tier includes means locating every one of those conditionals, and the ones you miss become either a leak or an outage for a paying customer. An entitlement service inverts it. Features ask one question - is this tenant allowed to do this right now - and the answer comes from configuration. New tiers, trials, grandfathered pricing and one-off enterprise terms all become data. In a sector where pricing is an experiment you run monthly, that difference decides how fast you can move. At a glance Plan checks in codePricing becomes a release Entitlement servicePricing becomes data Enterprise one-offsConfiguration, not a branch CostDays of design, not weeks Want your tenancy and entitlement model reviewed against your roadmap? [Talk to an engineer](https://miracuves.com/schedule-consultation/) ## Eight operators, eight different builds "SaaS" is not one buyer. The tenancy pressure, the compliance burden and the integration surface change completely between them. At a glance Operator types8 Can start from a shipped platform6 Need a custom build2 ### Vertical SaaS One industry, deep workflow, and usually a regulator behind the customer. The domain model is the product, and the compliance requirements arrive from your customers' obligations rather than your own. Custom build ### Horizontal B2B tools Many industries, shallower workflow, competition on integrations and price. Entitlements and self-serve onboarding matter more than domain depth. 3 shipped platforms ### Developer and API products The API is the product. Versioning, documentation, sandbox keys and rate limits are user experience rather than infrastructure, and breaking changes cost customers directly. 2 shipped platforms ### AI applications Model cost is a per-request variable in your margin, and prompt or context data raises isolation questions a traditional application never faced. Metering has to be exact because it is what you bill on. 4 shipped platforms ### Site and store builders Every customer's output is public and their traffic is yours to serve. Tenant isolation extends into rendering and delivery, and one customer's viral moment is your capacity problem. 2 shipped platforms ### Marketing automation Scheduled work at scale, deliverability that depends on your sending reputation, and one tenant's bad list damaging every other tenant's inbox placement. 2 shipped platforms ### Collaboration and file sharing Sharing models that cross tenant boundaries by design, which makes permissions the hardest part rather than storage. External sharing is where the security review concentrates. 4 shipped platforms ### Internal platform teams Building for one organization rather than a market. Tenancy is departmental, the buyer is internal, and the success measure is adoption rather than revenue. Custom build Six of the eight can start from something already running. Two are custom builds because nothing off the shelf carries the domain properly, and we would rather say that than sell you an adaptation that fights you for two years. Not sure which of these you are, or you sit across two of them? [Book a scoping call](https://miracuves.com/schedule-consultation/) ## How the work actually runs Six stages, the same on both tracks. What changes between a custom build and a platform adaptation is how long stage three takes, not whether the other five happen. At a glance Stages6 Identical on both tracks5 Varies by trackStage 3 only 01Stage ### Scoping against your largest intended customer We scope from the biggest customer you intend to serve rather than the first one you will sign, because that customer's isolation, identity and audit requirements set the architecture. Building for the small end and discovering enterprise requirements in year two is the most common expensive mistake in this sector. **Ends with**Written scope: tenancy model, identity requirements, residency needs and the compliance questions you must answer yes to. 02Stage ### Architecture and the entitlement boundary Tenancy, entitlements and audit logging are placed before features are built, because all three are cross-cutting and all three are painful to introduce later. Pricing becomes configuration, permissions become a scoped role model, and every state change becomes an audit event by default rather than by remembering. **Ends with**An entitlement service, a scoped permission model, and audit events emitted by default rather than added later. 03Stage ### Build against multi-tenant-shaped data SaaS platforms fail on skew, not on volume. Test environments carry a realistic tenant distribution from the start: one tenant with a hundred times the data of the median, an integration retrying in a loop, an export nobody bounded, and a trial tenant with almost nothing. A platform tested against evenly sized tenants has not been tested. Length varies by track **Ends with**Test data carrying tenant skew, runaway integrations, unbounded exports and empty trial accounts. 04Stage ### Security validation and the evidence trail Internal review against the mapped controls, then external penetration testing, then remediation. Our platforms arrive with a VAPT and compliance document mapping the OWASP Top 10, so the external test starts from a documented baseline and your own audit begins from evidence rather than from scratch. **Ends with**A VAPT and compliance document, an audit log with a stated retention, and answers to a standard security questionnaire. 05Stage ### Design partners and integration proving A small cohort of real customers using the platform against their own identity provider and their own data volumes. This is where SSO configurations that worked in testing meet a customer's actual directory, and where the integrations your buyers assume you have get named. **Ends with**A live design-partner cohort, SSO proven against real directories, and the integration list your buyers actually ask for. 06Stage ### Launch and day two General availability with activation and support load watched weekly, because both tell you more about the product than any roadmap session. Then we stay on, because the questions that reshape a SaaS platform arrive from paying customers. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates. **Ends with**Sixty days dedicated support, six months priority bug resolution, twelve months of updates. Want this sequence mapped against your tenancy model and compliance targets? [Book a technical call](https://miracuves.com/schedule-consultation/) ## Fourteen SaaS and AI platforms already in production Every one ships with full source-code ownership, deployed on your infrastructure under your brand. Adapt one, or use it as the reference architecture for a custom build. They fall into four groups, and which group you start from matters more than which name you recognise. **Collaboration and file platforms** carry sharing models that cross tenant boundaries, which is where permissions get genuinely hard. **Site and store builders** carry rendering and delivery for your customers' own traffic. **Marketing automation** platforms carry scheduled work at scale and sending reputation shared across tenants. **AI applications** carry per-request cost, exact metering and the isolation questions that context data raises. At a glance Platforms already shipped14 Operator types covered8 DeploymentYour infrastructure, your brand [Zoom](https://miracuves.com/zoom-clone/) [Dropbox](https://miracuves.com/dropbox-clone/) [Google Drive](https://miracuves.com/google-drive-clone/) [Wetransfer](https://miracuves.com/wetransfer-clone/) [Transfernow](https://miracuves.com/transfernow-clone/) [Squarespace](https://miracuves.com/squarespace-clone/) [Wix](https://miracuves.com/wix-clone/) [Mailchimp](https://miracuves.com/mailchimp-clone/) [ActiveCampaign](https://miracuves.com/activecampaign-clone/) [ChatGPT](https://miracuves.com/chatgpt-clone/) [Deepseek](https://miracuves.com/deepseek-clone/) [Google Gemini](https://miracuves.com/google-gemini-clone/) [Grok](https://miracuves.com/grok-clone/) [Apple AI ReALM](https://miracuves.com/apple-ai-realm-clone/) ## What this sector requires ### Tenant isolation An isolation model chosen deliberately, with region as a first-class attribute if residency will ever be asked for. One documented exception is fine; an undesigned hybrid is where correctness goes to die. ### Enterprise identity SAML or OIDC against the customer's provider, automated provisioning and, critically, deprovisioning. Auditors check the offboarding half, and manual removal is not an answer. ### Entitlements as data One service answering whether a tenant may do a thing, so pricing changes, trials, grandfathering and enterprise one-offs never require a deployment. ### Metering you can defend If you bill on usage, the meter is a financial record: idempotent, reconcilable, and explainable to a customer disputing an invoice line. ### Audit logging by default Every state change emitted as an event with actor, target and time, retained long enough to answer a question about last year. Retrofitting this means reconstructing history you never kept. ### Noisy-neighbour control Per-tenant quotas, fair queuing and the ability to move a large tenant onto dedicated capacity. The last one doubles as the commercial answer to your biggest customers. Want to open any of these platforms and look inside before deciding? [See the live demos](https://miracuves.com/solutions/) ## Single sign-on is where enterprise deals are actually won Every enterprise buyer asks the same three questions, and a platform that cannot answer all three loses the deal at security review rather than at the demo. At a glance Protocols supportedSAML and OIDC ProvisioningAutomated, both directions The half teams forgetDeprovisioning Checked byTheir auditor, not their admin **Enterprise identity flow**Employee joins, works, leaves - and what your platform must do at each point Their directoryProvisionSign inLeave Identity providerTheir source of truth, not yours User createdAutomatically, with a role SAML or OIDCNo password you hold Access endsWithout anyone remembering What the security review asks Can our staff sign in with our own provider, without a separate password? When someone leaves us, does their access to your platform end automatically? Can we see who did what in your platform, for the last twelve months? Can we scope permissions to teams and resources, not just to two roles? A platform that answers three of four still loses the review Standard pathWhere platforms fail the review Deprovisioning is the question that fails platforms, because it is the one that cannot be answered with a manual process. If removing a departed employee's access depends on somebody remembering, the honest answer to the auditor is no. Want your identity and permission model reviewed against an enterprise questionnaire? [Talk to an engineer](https://miracuves.com/schedule-consultation/) ## Built custom when nothing off the shelf fits The same team, working from zero. These are the capabilities we build into SaaS platforms that no shipped product carries, because they are specific to how you operate. At a glance Custom capabilities6 Operator types needing custom2 ### Vertical domain modelling The workflow your industry actually runs, built as a first-class model rather than configured into a generic tool that fights it. This is what a vertical SaaS product is. [Custom software development](https://miracuves.com/service/custom-software-development/) ### Usage metering and rating Meters that are idempotent and reconcilable, with a rating engine that survives mid-cycle plan changes, credits and disputed lines without manual correction. [Backend engineering](https://miracuves.com/service/backend-development/) ### Data residency architecture Region-pinned tenants with routing, backup and support tooling that respect the boundary, so residency is a property of the platform rather than a promise in a contract. [Cloud and DevOps](https://miracuves.com/service/devops-services/) ### Model routing and cost control For AI products: routing between models by task and cost, caching where responses repeat, and per-tenant spend limits so one customer cannot consume your margin. [AI engineering](https://miracuves.com/service/ai-development/) ### Migration and tenant tooling Fleet-wide schema migration, per-tenant restore and the ability to move a tenant between isolation tiers without downtime. The tooling that makes database-per-tenant survivable. [Cloud and DevOps](https://miracuves.com/service/devops-services/) ### Compliance evidence automation Access reviews, log retention and control evidence generated continuously, so an audit becomes an export rather than a quarter of preparation. [Compliance engineering](https://miracuves.com/service/compliance-consulting/) Need something this list does not cover? [Ask about custom work](https://miracuves.com/schedule-consultation/) ## What we built, and what it delivered Three deployments in this sector, described by what was actually built rather than by a metric we cannot show you the working for. At a glance Builds detailed here3 AI application ### Assistant platform with per-tenant spend limits Model routing by task, response caching, exact per-request metering and tenant-level spend caps so one account could not consume the margin on the rest. Collaboration ### File platform with external sharing Sharing that crosses tenant boundaries by design, with a permission model scoped to resources and an audit log covering every access. Marketing automation ### Multi-tenant sending platform Scheduled work at scale with per-tenant reputation isolation, so one customer's list quality could not damage another's inbox placement. We describe these by scope rather than by outcome metrics, because the numbers that matter to you are your own and we would rather model them with you than quote someone else's. Want to speak to a reference operating at your stage? [Request a reference](https://miracuves.com/schedule-consultation/) ## Written on this sector Longer pieces on the problems above, written by the engineers who build these platforms. At a glance Articles4 [Architecture ### Choosing a tenancy model you will not regret](https://miracuves.com/blog/) [Billing ### Why entitlements belong outside your feature code](https://miracuves.com/blog/) [Identity ### The deprovisioning question that fails security reviews](https://miracuves.com/blog/) [Scale ### Containing the noisy neighbour before it arrives](https://miracuves.com/blog/) If a question here is not covered, the fastest route to an answer is a call with the engineer who would run your build. Want these as a briefing pack for your board or engineering team? [Request the pack](https://miracuves.com/schedule-consultation/) We failed two security reviews before we understood that the problem was our tenancy model, not our documentation. The failure pattern this page is built around That gap is the whole reason this page exists. Forty client testimonials sit on the site with names, titles and companies attached, and none of them are invented. [Read all forty](https://miracuves.com/client-testimonials/) ## Questions SaaS buyers actually ask The ones that come up in the first call, answered as we would answer them there. At a glance Questions answered12 Can we really launch in six working days? Yes, for a shipped platform as it comes, on a standard tenancy model. It does not cover a security certification or a bespoke domain model, both of which have their own timelines and neither of which a build can compress. Do we own the source code? Yes, in full, deployed on your infrastructure. No per-seat licence, no per-tenant fee, no runtime dependency on us. Which tenancy model do you recommend? The one your largest intended customer requires. If you will sell to regulated enterprises, start at schema or database per tenant. If you are selling self-serve to small teams, shared schema with disciplined query scoping is defensible and much cheaper. Do you build SOC 2 and ISO 27001 ready platforms? Yes. We build to the controls those frameworks require and deliver the evidence trail with the platform: audit logging, access reviews, retention enforcement, key handling and a VAPT and compliance document. If you take a deployment through external audit, we support that process directly. Can we add SSO later? Technically yes, and it is more expensive than doing it at the start, mostly because permissions and provisioning have to be reworked alongside it. If enterprise is on your roadmap at all, design for it now. How do you handle usage-based billing? With a meter treated as a financial record: idempotent writes, reconcilable totals and a line-level explanation for any invoice a customer disputes. Can one customer's usage affect the others? Not if per-tenant quotas and fair queuing exist, which is why they are built in stage six rather than added after an incident. Large tenants can also be moved onto dedicated capacity, which is usually a commercial upgrade as well as a technical one. Do you support data residency? Yes, where the tenancy model carries region as a first-class attribute. That has to be decided in week one; adding residency to a platform that assumed a single region is a migration, not a feature. What does the API look like? Versioned from the first external consumer, with signed webhooks, documented retry behaviour and published rate limits. In B2B the API is frequently the reason a deal closes, so it is treated as a product. How long are audit logs retained? You choose, and we build for it. Twelve months is the common enterprise expectation; regulated buyers often ask for longer, and retention is cheap to plan for and expensive to backfill. What does support look like after launch? Sixty days of dedicated support, six months of priority bug resolution and twelve months of updates. Onboarding friction and support load both surface in the first weeks, so that is when we stay closest. What if we are not ready to build yet? We will say so. If you do not yet know who your largest customer will be, the tenancy decision is a guess, and we would rather help you answer that first than scope a platform around an assumption. Question not answered here? [Ask us directly](https://miracuves.com/schedule-consultation/) ## Tell us what you are building. Bring the customer you most want to win. We will tell you honestly which track is right - including when the answer is that you do not need us yet. [Book a technical call](https://miracuves.com/schedule-consultation/) [Browse all solutions](https://miracuves.com/solutions/) A first call takes about thirty minutes and covers four things **01** ### Largest intended customer Their size, their sector and what their security review will ask. **02** ### Tenancy and residency Whether data has to stay in a region, and for whom. **03** ### Money model Seats, usage, tiers, or a combination you will keep changing. **04** ### Existing systems The identity, billing and data stack a platform must fit into. Those four answers are usually enough for us to tell you which track fits, roughly what it costs, and which architectural decisions you cannot defer. If the honest answer is that your tenancy decision depends on a customer you have not signed yet, we will say that instead of scoping work around a guess.