En
Fr
De
It
Es
Uk
What does a custom SaaS development company actually build?
A custom SaaS development company builds the product your customers use and the machinery around it that lets you sell it as a subscription: accounts, teams, plans, billing, permissions, onboarding, an admin back office, integrations, and hosting that serves every customer from one codebase. The visible features are often less than half of the work. The rest is what makes the product safe to sell to the tenth and the hundredth customer.
Lytvynov Production builds SaaS products on PHP/Symfony, React or Vue and PostgreSQL or MySQL, with mobile apps in React Native or Flutter when needed. We work with startups building a first product and with B2B companies turning an internal tool into something they can sell.
Which parts does every SaaS product need?
Every SaaS product needs the same set of building blocks, and deciding early how much of each to build saves months later. This is how we usually phase them:
| Building block | SaaS MVP | Version for B2B sales | Scale stage |
|---|---|---|---|
| Accounts and auth | Email and social login | Teams, invitations, SSO (Google, Microsoft, SAML) | SCIM provisioning, enterprise SSO |
| Multi-tenancy | Shared database, tenant id on every row | Tenant-aware caching, per-tenant settings | Dedicated database option for large customers |
| Roles and permissions | Owner and member | Custom roles, per-object permissions | Audit log, approval flows |
| Billing | One plan via Stripe Checkout | Plans, trials, seats, usage limits, dunning | Usage-based pricing, invoicing, tax handling |
| Admin back office | Generated admin for your team | Customer lookup, impersonation, refunds | Reporting, feature flags per tenant |
| Integrations | One key integration | Public API, webhooks | Marketplace apps, embeddable widgets |
| Operations | CI/CD, backups, error tracking | Monitoring, staging per branch | Autoscaling, data retention policies |
How should multi-tenancy be designed?
Multi-tenancy should be designed on day one, even if you only have one customer, because retrofitting tenant isolation into a live product is expensive and risky. The core rule is simple: every query that touches customer data must be scoped to a tenant, and that scoping must be enforced by the framework, not remembered by each developer.
In Symfony we implement this with a tenant resolver (from subdomain, header or user session) and a Doctrine filter that adds the tenant condition to every query automatically, plus tests that try to read another tenant's data and must fail. For most products a shared database with a tenant column is the right start. A schema per tenant or database per tenant comes in when enterprise customers require physical separation or regional data residency. We keep the tenant model behind one interface so moving a large customer to a dedicated database later is a migration, not a rewrite.
How do subscription billing and pricing work in a SaaS?
SaaS billing works best when a billing provider handles money and your code handles product rules. Stripe Billing, Paddle or Chargebee store cards, charge them, generate invoices and deal with taxes. Your application listens to their webhooks and decides what each customer is allowed to do: which plan, how many seats, which limits, what happens during a trial or after a failed payment.
We have built payment-heavy products before. Ritoria, a serialized-fiction platform, ran an in-app currency bought through Stripe, PayPal or Braintree, spent on chapters, gifts and donations, with a transaction ledger, referral rewards and payouts to authors and cover designers. Lessons from that kind of work: keep a ledger of every money movement, make webhook handling idempotent, and never let a user's access depend on a single webhook arriving on time.
What should the SaaS admin panel include?
The SaaS admin panel should let your team answer a customer question without calling a developer. That means finding any customer, seeing their plan and usage, changing settings, refunding, and viewing what they see.
For early products we generate the admin from the data model (EasyAdmin in Symfony works well), which gives you a working back office in days. Ritoria's back office grew to 38 sections covering content rows, banners, genres, FAQ, SEO texts and every entity in the system, without a separate custom admin project. As the product grows we add the pieces that pay back fastest: impersonation with an audit trail, per-tenant feature flags, and dashboards for activation and churn.
How do you plan a SaaS roadmap from MVP to scale?
A SaaS roadmap should be ordered by what blocks revenue, not by what is most interesting to build. We usually plan three stages:
- SaaS MVP (10 to 14 weeks): one core workflow, sign-up, one plan, Stripe Checkout, generated admin. Goal: first paying customers. See MVP development.
- Sellable to businesses (next 3 to 5 months): teams and roles, several plans, trials, SSO, public API and webhooks, audit log, onboarding emails. Goal: pass a B2B buyer's security questionnaire.
- Scale: performance work, usage-based pricing, integrations marketplace, dedicated tenants, AI features built on your customers' data.
The roadmap is revisited every month against real usage. Features that no paying customer asks for move down, no matter how early they were planned.
Which SaaS products have we built?
We have built SaaS and subscription products for our own portfolio and for clients:
- AI Resume Master: our own AI resume builder with a SaaS and ad-based model, built in about three months, now at 50,000 monthly active users.
- Ritoria: a Symfony platform with 54 domain entities, three payment providers, a marketplace and a social layer in English and Arabic, which ran in production on AWS for two and a half years through 292 commits and 120 database migrations.
- Sports event calendar: a freemium platform with B2B licensing for a UK sports tech company, including APIs and embeddable widgets for partner platforms and a parsing engine that unifies hundreds of external calendars.
How much does custom SaaS development cost?
Custom SaaS development cost depends on the depth of multi-tenancy, billing complexity, number of integrations and compliance requirements. A SaaS MVP typically takes 10 to 16 weeks, a B2B-ready product 4 to 8 months, and ongoing development after that runs on a monthly budget based on team size.
We give a fixed quote per milestone after a short scoping call. A SaaS product starts from about $10,000 with us; our guide to MVP development cost breaks down the first release. For stack decisions, our comparison of Symfony vs Laravel for SaaS explains why we default to Symfony for long-lived products.
When should you not build a custom SaaS?
You should not build a custom SaaS when an existing product covers most of your needs and your advantage is not in the software itself. If you need internal CRM, helpdesk or project tracking for your own team, buying an existing tool is usually cheaper. Custom SaaS development pays off when the software is what you sell, when your workflow is specific enough that off-the-shelf tools force costly workarounds, or when you need to own the data model and integrations for the long term. A useful test: if a competitor could copy your offer by buying the same subscription, the software is not your moat, and building it will not make it one.
How we work on SaaS projects
We start with a short scoping phase: tenants, roles, plans, integrations and the first release, written down and estimated. Then we deliver in milestones with a demo every week, code in your repositories and infrastructure in your cloud accounts. Senior engineers own the architecture and review every change; we use AI coding agents internally to speed up delivery. Many clients stay with us as a dedicated Symfony development team after launch.
Tell us what your product does and who pays for it, and we will propose a first release. Book a SaaS scoping call.
