SaaS Development with App Integration
One product. Many companies. Nobody sees anybody else’s data.
Multi-tenant platform, subscription billing, teams and seats, an admin side, and the mobile app, built as one system, so nothing has to be stitched together after you have paying customers.
Your code, your accounts, your customers’ data. Yours on final payment, and handed to your in-house team whenever you want it.
Overview
A SaaS product is more than an app. It needs many customers living safely on one system, subscription billing that survives a failed card, teams and roles and seats, an admin side for your own staff, and usually a mobile app that stays in sync with the web. Get the shape of that wrong and you find out eighteen months later, with paying customers on board, when the fix is a rebuild. We build the whole thing as one system so that does not happen.
What usually goes wrong
What clients tell us before they call us
| The client's words | What it really means | Links to |
|---|---|---|
| “Be very very careful with agencies. Their incentive is to get as much work as possible, not to be effective and get things done fast.” | The agency's interest and the founder's diverged. | § 10 How we make our incentives match yours |
| “$17k for a shitty looking MVP… nobody became a customer and I made $0 in revenue.” | Money went into building, none into finding out whether anyone wanted it. | § 11 When you should not build this yet |
| “Transitioning that product to your team will be most difficult.” | Nobody planned for the day the founder hires developers. | § 10 |
| “I'm not technical enough to understand what to ask for… I don't know how to assess the quality of what's built.” | The buyer could not check the work, so they could not trust it. | § 07, § 09 |
Who you will work with
Anand Yadav
The hardest thing about a SaaS build is not the code. It is that you are making decisions in month one that you cannot cheaply change in month eighteen, how tenants are separated, how plans work, what happens when a card fails.
Most of those decisions get made by whoever is at the keyboard, quietly, because nobody asked. I would rather put them in front of you, in plain words, with what each one costs you later. You will not understand the code and you do not need to. You will understand the trade.
And I will tell you honestly when the answer is: do not build this yet.
The decision that costs the most to change
Multi-tenancy, explained properly
Every SaaS platform has to answer one question: when Company A and Company B both use your product, how separate is their data really? There are three honest answers, and every agency page we studied names the word “multi-tenant” without ever explaining the choice.
| Model | What it means | Costs less | Costs more | Right when |
|---|---|---|---|---|
| Shared database, shared tables | Everyone's rows in one place, separated by a tenant column and enforced in code | Cheapest to run, easiest to update everyone at once, simplest reporting across customers | One bug in one query can expose the wrong customer's data. Noisy neighbours: one heavy customer slows everyone | Most products. Small to mid-size customers, no per-customer compliance demands |
| Shared database, one schema per tenant | One database, but each customer has their own set of tables | Stronger separation, per-customer backup and restore is possible | Migrations get slower as customers grow. More moving parts to operate | Mid-market customers, or when a customer may ask for their data back cleanly |
| One database per tenant | Every customer physically separate | Strongest isolation, per-customer backup, residency and compliance are straightforward | Most expensive to run and to operate. Deploying a change means deploying it many times | Enterprise or regulated customers who require it in writing |
What we do: we ask you two questions before choosing: who is your biggest realistic customer in three years, and will anyone ever require their data to be physically separate or in a specific country. Then we write the decision down, with what changing it later would involve.
The honest part: moving between these models after you have paying customers is a migration project, not a setting. That is precisely why it deserves a conversation in month one rather than a default chosen at the keyboard.
Building for many tenants
SaaS is a billing problem wearing a product
Tenancy, plans, upgrades, refunds, tax and the app store cut all land in the same place. Getting them wrong is expensive to unpick later, so they come first here.
The part that quietly loses revenue
Billing is engineering, not a Stripe logo
Every agency page says “we integrate Stripe.” Across five competitor pages, not one mentions proration, dunning, failed payments, mid-cycle upgrades, or tax. Those are the parts that break, and they break after you have customers.
| The situation | What has to happen | What goes wrong when nobody built it |
|---|---|---|
| Customer upgrades on day 12 of 30 | Charge the difference for the remaining days, not a full month | You overcharge and refund by hand, or undercharge and lose the difference every time |
| Card fails on renewal | Retry on a schedule, email them, hold the account in a grace state, then downgrade, not delete | You lose a customer who wanted to stay. This is called involuntary churn |
| They downgrade mid-cycle | Credit or schedule the change at period end. Decide which, and be consistent | Angry support tickets and inconsistent invoices |
| Seats change | Seat count, proration and the invoice must agree, every time | Your billing and your product disagree, and customers notice |
| Trial ends | A defined path into paid, and a defined path out | Trials silently expire and nobody follows up |
| Tax | VAT, GST and US sales tax vary by where the customer is | You find out at your first audit |
| Refunds, disputes, chargebacks | A process, with a record | It becomes someone's manual job forever |
On the failed-card problem: one subscription platform’s own network data (July 2026) puts involuntary churn (customers lost purely to failed payments) at around 1.06% against 2.16% voluntary churn for software and SaaS, which would make failed cards roughly a third of all churn (Recurly Research). That is a vendor’s own benchmarking data, not independent research, so treat it as directional. But directionally it says the same thing every operator says: a retry schedule and a dunning sequence is one of the cheapest revenue improvements in a SaaS product, and it is almost never in the original build.
The uncomfortable section
How we make our incentives match yours
The most common warning founders give each other about agencies:
Be very very careful with agencies. Their incentive is to get as much work as possible, not to be effective and get things done fast.
It is a fair warning. Here is what we do about it, in writing rather than in promises:
What we commit to
| What we commit to | What that means |
|---|---|
| Fixed scope per block | Two-week blocks with an agreed outcome, so “more hours” is never automatically “more money” |
| A handover plan written in month one | Before there is anything to hand over, because it is honest then and awkward later |
| Your accounts, your name, from week one | Repository, cloud, Stripe, stores. We work inside your infrastructure |
| We will tell you not to build things | § 08 and § 11 are both on this page because we say these things on calls anyway |
| A named person, not an account manager | Anand is on every project. § 05 |
| You can stop at the end of any block | No notice period dressed up as a partnership |
On hiring your own developers: you probably will, and you should. A SaaS product that makes money eventually needs people who think about it every day. We would rather be the team that hands it over cleanly and stays for the specialist work than the team that made leaving expensive.
Your commission, on a dated table
What the app stores take, and when
If your SaaS sells subscriptions through a mobile app, the store’s cut is a real line in your pricing model. It changed a lot in the last eighteen months.
| Situation | Where it stands | Source |
|---|---|---|
| US App Store, linking out to your own web checkout | Following the Epic injunction (2025), US apps may link out to external payment, and Apple continues to charge zero commission on external purchases while the case continues. A court has said Apple may eventually charge “a reasonable commission,” but the amount has not been set | Apple Developer news |
| Apple Small Business Program | 15% instead of 30% for developers with up to $1M annual proceeds | Apple |
| Google Play, EEA / UK / US, from 30 June 2026 | Subscriptions 10% plus a 5% billing fee | Google Play Console Help |
| Google Play, elsewhere | 15% on the first $1M a year, then 30%. Subscriptions stay at 15% globally regardless of revenue | Google Play Console Help |
| “Reader app” external link entitlement | Only for apps whose primary function is magazines, newspapers, books, audio, music or video. B2B SaaS and productivity apps do not qualify | Apple |
| EU, under the DMA | Apps on the EU storefront can promote and link to external payment. Choose standard terms or Alternative Terms (10% core commission for most developers and renewals, +3% if Apple processes payment, plus a €0.50 Core Technology Fee per install above 1M a year; Apple says under 1% of developers would pay it) | Apple |
What this means for your pricing: where you take the money is now a design decision, not just a technical one. We build the billing so the same subscription can be sold through the web, through the store, or both, because the rules above are still moving.
Checked 12 August 2026.Track record
Industries we serve
| Industry | What we have built | Proof |
|---|---|---|
| CRM, HR & internal business tools | Multi-party systems that grew 100× | PM Fund Manager · FMSoft CRM |
| Retail, POS & e-commerce | Merchant platforms across many devices | Vencru POS |
| Fintech & banking | Wallets, lending, settlement | Fidex Wallet · Hindustan Loan |
| Legal-tech | Case and document platforms | DigitsLaw · ActivePass |
| Consumer subscription | Paid subscriptions at scale | Pray the Bible |
| Events & community | Multi-organisation platforms | Virtue Insight |
| Healthcare & wellness | Open. No case study yet. | No claim made |
Stack
Tech we use
Row-level security, schema-per-tenant or database-per-tenant, chosen in § 07
Organisations, invitations, roles, SSO where enterprise customers need it
We recommend the stack that fits your product, not the one we prefer to write.
What clients say
The SightInfusion team delivered our app with impressive speed, clear communication, and reliable quality. A professional team we're excited to work with again soon.
Working with SightInfusion was a smooth and professional experience. Proactive, technically strong, and always transparent with updates.
SightInfusion handled our complex project with patience, expertise, and consistent communication. Learns fast, solves challenges quickly.
FAQ
Questions clients ask
What actually makes something “SaaS” rather than just a web app?
Many separate customers on one system, paying on a subscription, with their data properly separated. The separation part is § 07 and it is the decision that costs most to change.
What is multi-tenancy and which model do I need?
Three models, with what each costs you later, in § 07. The short answer: most products want shared-schema; enterprise or regulated customers may require database-per-tenant.
Can we change the tenancy model later?
Yes, but it is a migration project once you have paying customers, not a setting. That is why it is decided in week one. § 07
Do I need a mobile app for my SaaS?
Often not, or not for everything. Four cases where you should and four where you should not, in § 08 (written by a mobile agency).
You integrate Stripe, is that all billing means?
No. Proration, dunning, failed payments, mid-cycle upgrades, seats and tax are the parts that break after you have customers. § 09
What happens when a customer’s card fails?
Retry schedule, notification, grace state, then downgrade, not deletion. Failed cards are a meaningful share of total churn and are among the cheapest revenue to recover. § 09
What do the app stores take from my subscriptions?
It depends on store, region and your revenue, and it changed twice in the last eighteen months. Current figures with first-party sources in § 12.
Should I build this yet?
If nobody has paid you and you could onboard your first five customers by hand, probably not yet. § 11
How do I judge the work if I am not technical?
By the decisions, not the code. We put each significant decision in front of you with what it costs later. § 05, § 07
What if we hire our own developers later?
You should, and the handover plan is written in month one for exactly that day. § 10
Do I own everything?
Yes: code, designs, cloud, Stripe account and customer data, on final payment.
How long does a SaaS platform take?
Three to five months for the platform, three to five weeks to add the mobile app afterwards. The market publishes “about six months” for a basic platform. § 15
What does it cost?
Agencies publishing figures in this market quote $40,000 to $300,000, which tells you how wide the category is. You get your fixed number after the architecture week. § 16
Can you take over a SaaS product somebody else built?
Yes, start at App Rescue and Code Audit, because the first question is whether the tenancy and billing decisions underneath are sound.
Tell us the problem. We bring the engineering.
A short call, an honest answer on whether we are the right team, and a scope you can hold us to.
Start a project