SmartLink
Software engineering

SaaS product development in Pakistan: cost, timelines and tenancy

SaaS product development in Pakistan is priced as software rather than as a website, and the difference shows up in the second year rather than the first. SmartLink Services builds multi tenant products from Karachi on React, Node and PostgreSQL, with tenancy, subscription billing and support tooling designed in from the opening sprint. What follows is the detail that usually arrives after a proposal has been written: what the engineering costs at published market rates, how long a first billable release takes, and whether to run one shared product or a separate copy for every customer. Cloud accounts and payment providers are contracted in your name, so nothing recommended here earns us a margin.

Discuss this service
Model
Multi-tenant
Cadence
Two-week sprints
Handover
Code \u00b7 pipeline \u00b7 docs
Overview

Tenancy and billing are architecture

The expensive decisions in a SaaS product are made in the first fortnight and paid for in year three. Where the tenant identifier sits, whether isolation is enforced by the application or by the database, how a plan limit is represented, and what happens when a customer asks for their data to be deleted. None of these feel urgent while there is one customer on a demonstration account. All of them become migrations once real customers are on the system, and migrating tenant data is the least enjoyable work in the field.

We design tenancy, billing and operational tooling in from the first sprint. That does not mean building every feature early. It means the isolation model is chosen deliberately and enforced in one place, the subscription and plan structure exists before the first invoice has to be raised, and there is an administrative view that support can use without a database client in front of them. Those three cost very little at the start. Each of them is disproportionately expensive to retrofit afterwards.

What we build towards is a released first version that could take money from a stranger, not a prototype that demonstrates well in a meeting room. That means environments, a deployment pipeline, error reporting and a way to onboard a tenant without a developer being involved at any point in it. A product that works in a demonstration but needs an engineer for every signup is not finished. It is a demonstration with a login page attached, and the gap between those two states is routinely underestimated by everyone involved.

Scope

What SaaS product development covers

Everything below is agreed in writing before any development & saas work starts, so both sides know what is in and what is not.

What the work covers

  • Discovery, user journeys and scope for a releasable first version
  • Multi-tenant data model and tenant isolation strategy
  • Subscription, plan and billing integration
  • Authentication, roles and audit logging
  • CI/CD pipelines and staged environments
  • Usage analytics and operational dashboards

What you get at handover

  • Released first version in production
  • Architecture and data model documentation
  • CI/CD pipelines and environment definitions
  • Admin and tenant onboarding tooling
  • Source repository with contribution guide

Typically involves

Discuss this service
01

Choosing an isolation model you can still defend once the fleet grows

There are three common shapes. A shared schema with a tenant column, a schema per tenant, or a database per tenant. Shared is cheapest to operate and carries the highest consequence for a single missing filter. Database per tenant gives clean isolation and easy per customer restore, at the price of painful migrations across a growing fleet. Schema per tenant sits between them and inherits some of both problems. There is no universally correct answer, only one that fits the customers you expect and the guarantees you will have to make.

Whatever is chosen, the enforcement should exist in exactly one place. A tenant filter applied by hand in every query will eventually be forgotten in one of them, and that one will turn out to be a report or an export where the consequence is widest. Row level security in the database, or a mandatory scope in the data access layer that a query cannot bypass, moves the guarantee from discipline to structure. Tests should include a deliberate attempt to read another tenant's data through every entry point.

Background work is where isolation quietly breaks. A request carries a tenant context naturally, because it arrived with one. A queued job, a scheduled task or an administrative script does not, unless somebody designed it to. Most cross tenant incidents originate in a report generator, a nightly export or an internal support tool rather than in the main application path. Those deserve the same enforcement and the same tests, and they are usually written later by someone treating them as throwaway tooling.

  • Isolation model chosen against expected customer size, restore needs and compliance promises
  • Enforcement placed in one layer, so no individual query can omit the tenant scope
  • Background jobs, scheduled tasks and exports carrying explicit tenant context
  • Cross tenant access attempted deliberately in tests, through every entry point
  • Per tenant restore rehearsed where the isolation model is supposed to make it easy
02

Billing that matches what the product actually does

Billing drifts away from the product faster than anything else in a SaaS codebase. A plan limit is added on the pricing page, enforced in one place in the code, and then a second code path grows that does not check it at all. A customer is moved onto a custom arrangement by a sales conversation and represented as a manual override in a database row. Six months later nobody can say with confidence what a given tenant is entitled to, and support answers by guessing.

Entitlements should be data, evaluated in one service. What plan a tenant is on, what limits that plan carries, what overrides apply and when they expire, all queried through the same path whether the caller is the application, the administrative view or a background job. Trials, upgrades, downgrades, proration and involuntary cancellation after a failed payment are ordinary cases that need designing rather than discovering. Metered usage in particular needs one defined recording point, because usage counted twice becomes a refund conversation.

The reconciliation is the part teams skip. What the payment provider believes a customer owes and what your database believes should be comparable on demand, with every difference explainable. Webhooks arrive out of order, are delivered more than once, and occasionally do not arrive at all. Designing for idempotent handling and a periodic reconciliation job is unglamorous work that prevents a specific and awkward situation: a customer who has paid and lost access, or one who has not paid and kept it.

  • Plans, limits and overrides held as data and evaluated through a single entitlement service
  • Trials, upgrades, downgrades and failed payment treated as designed states, not edge cases
  • Metered usage recorded at one defined point, with idempotent handling of retries
  • Payment provider webhooks handled idempotently and tolerant of out of order delivery
  • A periodic reconciliation between provider records and application state, with exceptions reported
01

What SaaS product development costs in Pakistan

Published market ranges for custom web application work in Pakistan run PKR 200,000 to 1,000,000 and upwards, and a SaaS product sits at the top of that band or above it. Feature count is not the reason. A product strangers are expected to buy carries work an internal tool never needs: sign up without a developer present, a billing relationship with a payment provider, isolation between customers that holds inside a report as well as inside a screen, and environments somebody can deploy to on a Friday afternoon. Set that against a business website at PKR 80,000 to 200,000 and the shape of the difference is plain enough.

Hourly figures tell the same story from the other side. Full stack development in this market is quoted at PKR 3,500 to 8,000 an hour, junior work at PKR 500 to 1,000, and senior specialists at the top of the full stack band. Where a mobile client forms part of the product, published market pricing for a mobile application runs PKR 400,000 to 800,000.

Four items move a SaaS estimate more than the feature list does. Isolation comes first, since a database for each customer and a shared schema with enforced scoping generate different migration and restore work for years afterwards. Billing is second: a trial, an upgrade, proration and a declined card are states to be designed rather than discovered. Roles are third, and each additional one multiplies what has to be tested before a release rather than adding to it. Administrative tooling is fourth, and it is the item most often missing from an estimate entirely, which is how a young product ends up with three developers holding production database access. Running cost belongs in the same conversation, because it does not stop when development does: hosting, the provider's percentage on every transaction, error reporting, and somebody answering support. Everything above is market pricing rather than our quotation. A real figure follows discovery, once the tenancy model, the billing rules and the scope of the first release are written down.

  • Custom web application pricing at PKR 200,000 to 1,000,000 and upwards as the nearest published comparator
  • Isolation model priced for its migration and restore consequences as well as its build
  • Billing states specified up front: trial, upgrade, downgrade, proration, failed payment
  • Administrative and support tooling costed rather than assumed into the sprint
  • Hosting, provider fees and support time budgeted as running cost from the first month
02

How long a first billable release takes

Reported delivery timelines in this market fall into three bands. Six to twelve weeks covers a focused single scope go live. Three to six months describes a mid sized product. Nine to twelve months is enterprise scale work carrying several integrations and a security review in the path. A SaaS first release usually lands in the middle of that spread, because the parts that make a product sellable rather than demonstrable cannot be quietly skipped.

Twelve weeks is achievable for a genuinely narrow first version: one workflow end to end, real authentication, a live payment provider and a deployment pipeline behind it. What pushes past that is seldom the interface. Single sign on requested by an early enterprise customer changes the identity model. A second payment method adds a reconciliation path nobody costed. Data carried in from a customer's existing system is the classic one, and it turns out worse than described far more often than better.

Gateway approval is its own queue and belongs on the plan in week one. Merchant onboarding wants documents, a bank relationship and a review whose timetable belongs to the provider, and a product that cannot take money has not launched however finished the code looks. Content is the quieter delay: pricing pages, terms of service, onboarding emails and the help articles support will need on the first morning all have owners outside engineering, and none of them appears on a sprint board.

Phase one is fixed on outcome, budget and date. Whatever follows is planned against the pace phase one actually demonstrated, since an estimate made before any code existed is a guess in a spreadsheet.

  • Six to twelve weeks reported for a focused single scope go live in this market
  • Three to six months the honest band once billing, roles and an integration are in scope
  • Payment gateway and merchant onboarding started in week one rather than at the end
  • Pricing, terms, onboarding emails and help content assigned to named owners with dates
  • Phase one fixed on outcome, budget and date, later phases planned on measured pace
03

A shared product or a copy for each customer

Plenty of software firms here sell what looks like a product and deliver a separate installation to every customer. The route is understandable. Your first customer pays for the build, each later sale is a copy with a few changes, and nothing has to be isolated because nothing is shared. The bill arrives later and it is easy to describe: eleven installations, each on a slightly different version, and a security patch that has to be applied eleven times by somebody who can still remember what was altered in each one.

A shared multi tenant product inverts every one of those properties. One version runs, one patch fixes everybody, and the twelfth customer costs about what the eleventh did. The price is paid up front and it is real. Isolation has to be enforced in a single layer rather than trusted to discipline in every query. Tenant context has to travel into background jobs, scheduled tasks and exports, which is where most cross tenant incidents actually begin. Plans, limits and overrides have to live as data. Schema changes have to be applied to a whole fleet at once. None of that is exotic engineering, and all of it costs more in month twenty than in month two.

Separate copies still win in specific situations. A customer whose regulator or parent company requires data to remain on infrastructure they own. A deployment inside a plant network with no dependable external link. A small number of very large contracts where each one funds its own operations properly. Where that describes the market you are genuinely selling into, design for it deliberately, because a product built for shared tenancy and then deployed customer by customer inherits the costs of both models and the benefits of neither.

There is a middle route worth naming. Build the application multi tenant, keep the tenant boundary honest, then permit a single tenant deployment for the customers who truly require one, from the same repository and the same pipeline. That keeps one version under maintenance while leaving room for the contract that pays for a year of engineering. What we argue against is the version with no plan at all, where the second customer is served by copying a folder. The recommendation goes in writing before the first sprint is booked, with the option we set aside and the reason it was set aside.

  • Shared tenancy where the plan is many customers of similar size on one version
  • A deployment for each customer where residency, plant networks or contract scale demand it
  • Tenant context carried into background jobs, scheduled tasks and exports from the start
  • One repository and one pipeline even where a single tenant deployment is permitted
  • The chosen model written down with the rejected option and its reason recorded
How we deliver

Delivering SaaS product development

A build is planned one phase at a time. These six steps run inside each phase rather than once across the whole product, which is how the second phase gets planned on measured pace instead of a guess.

  1. 01

    Discover

    What does a user in this role need to do, and what does success look like as a recorded outcome. We also ask which existing systems hold the data, because that usually decides the architecture.

  2. 02

    Blueprint

    Tenancy model, identity provider, data residency and the shape of externally visible identifiers get decided now, in week one, because all four are cheap here and disruptive after the first paying customer.

  3. 03

    Build

    The deployment pipeline goes in before there is anything worth deploying. Then sprints, with each one ending in a working release on a real environment rather than a demonstration on a laptop.

  4. 04

    Test

    Coverage concentrates where money, permissions and data integrity live, plus a regression suite that runs on every change. Each production defect earns a permanent test, so the suite ends up shaped by real failures.

  5. 05

    Go live

    Release to production through the same pipeline every other build used, behind a feature flag where the change is risky. Request tracing and alerting on user visible symptoms are on before the first user arrives.

  6. 06

    Run

    Dependency updates, certificate renewals and platform deprecations are handled on a cadence, not when something breaks. Hosting cost is reviewed quarterly and attributed to the features generating it.

Working together

A first version that can take money

The measure we work to is straightforward. Can a customer sign up, be isolated from every other customer, be billed correctly, be supported by somebody who is not a developer, and be recovered if something goes wrong. A product meeting those conditions is finished enough to sell and to improve. One missing any of them will consume engineering time on operations rather than on features, which is the state most early products find themselves in by month six.

Everything else follows from that. Environments and pipelines exist so a fix can ship the same day it is found. Tenancy is enforced structurally so growth does not increase the chance of a serious incident. Billing is reconciled so revenue is a fact rather than an estimate. None of it is exotic engineering. It is the ordinary work that gets postponed because there is always a feature that feels more urgent this week.

Credentials

Accreditations behind Development & SaaS

Custom software runs on somebody else's platform, so what we are accredited to build and run on matters as much as the code itself.

Oracle

Partner

Applications built over Oracle schemas get read through views and stored procedures rather than direct table access, and we integrate with E-Business Suite and Fusion through their published REST services.

Microsoft

Partner

Azure for hosting, Entra ID when a corporate customer makes single sign on a condition of purchase, and Azure SQL or SQL Server where the data belongs in a managed relational engine.

Google

Partner

Container workloads on Google Cloud with a chosen processing region, Workspace sign in for internal tools, and Firebase where a mobile application needs push notification and offline handling.

FBR digital invoicing

Compliant integrations

Billing and point of sale modules we write submit to the FBR system directly. Sandbox tokens first, then production credentials, with failed submissions queued and visible rather than swallowed by a retry loop.

HIPAA

Compliant practices

When an application we build holds protected health information, we are the business associate and sign accordingly. Role based access, encryption in transit and at rest, and audit logs are part of the build.

Client words

What Development & SaaS clients say

Comments from people who run development & saas systems day to day.

  • They wrote our requirement documentation knowing it had to survive a tender committee, and they were direct when one of our requirements could only be met by a single supplier. We would not have caught that ourselves. The audit trail design has since been through a full review without a finding.
    IT Director Public sector authority
  • Our first concern with FBR integration was simple: what happens to the tills when the line drops. They built the queueing and retry before anything else and demonstrated it by pulling the connection in front of us. Trading carried on, and the invoices went up when the link came back.
    Operations Manager Retail chain, Pakistan
  • Every vendor we spoke to said they could handle style, colour and size. This team asked to see our order book first, then told us which of the shortlisted platforms would need thousands of item codes to do it. That one piece of advice probably saved us a year.
    General Manager Textile exporter
Questions

Questions about SaaS product development

Published market pricing for custom web application work runs PKR 200,000 to 1,000,000 and upwards, and a SaaS product usually sits at the top of that band or above it. Hourly, full stack development here is quoted at PKR 3,500 to 8,000. Tenancy, billing and administrative tooling move the figure more than the feature list does. Those are market ranges. Our own figure follows discovery.

Reported timelines put a focused single scope go live at six to twelve weeks and a mid sized product at three to six months. A first billable release generally lands in the middle. Payment gateway approval, single sign on for an early enterprise customer and data brought in from an existing system cause most of the slippage, and none of the three sits inside the code.

Settle the question in week one, because it shapes the architecture and the launch date. Not every international provider onboards a business registered here, and the answer usually involves a local gateway, a local acquiring relationship or an overseas entity, each with its own documents and review. Whichever route is taken, the reconciliation between what the provider says you were paid and what your database believes is a designed feature.

You do, from the first day rather than at final invoice. The repository, the pipeline definitions, the cloud subscription and the payment provider account are registered in your name, and we work inside them with named access that can be revoked without touching anything else. Intellectual property assignment is written into the contract before development starts.

Usually, and the first piece of work is an assessment rather than a rewrite proposal. We look at how tenant isolation is enforced, what tests exist, how a release reaches production, and where the data model has been worked around. Sometimes one subsystem should be replaced and the rest kept. A full rewrite is occasionally correct and much more often a way to spend a year.

Four lines continue: hosting and managed services, the payment provider percentage on every transaction, monitoring and error reporting, and the people who answer support and ship fixes. Consumption based services rise with adoption, which is a good problem presented as an invoice. We put those figures in the proposal so the business case covers year two rather than launch week alone.

More in Development & SaaS

More Development & SaaS services

Software engineering

Custom application development

Internal web and mobile applications built against the systems you already run.

Open service page → Software engineering

API & integration development

Documented, versioned APIs and an integration layer that removes manual re-entry.

Open service page → Software engineering

Secure environment engineering

Application environments built to a security baseline: identity, secrets, least privilege, audit.

Open service page → Software engineering

QA, testing & release management

Test coverage, regression suites and release control so upgrades stop being an event to fear.

Open service page →

Building a product that has to take money?

Tell us what you run today and where saas product development is causing you trouble. The first conversation is a consultation rather than a pitch.

Book a consultation All development & saas