SmartLink
Software engineering

Custom software built to run in production.

Choosing a custom software development company in Pakistan is mostly a question about what happens after the launch. The build is the predictable part. Whether the thing can be deployed on a Tuesday afternoon two years later, by an engineer who never met the person who wrote it, is what decides whether the money was well spent. We build SaaS products, internal web and mobile applications and integration layers from Karachi, on React, Node and PostgreSQL, with the repository, the pipeline and the environments held by you throughout. What follows covers cost, duration, when custom is the wrong answer, and what we do and do not carry out ourselves.

Discuss this practice
Stack
React · Node · PostgreSQL
Delivery
Sprints with demos
Handover
Source and deployment guide
Ownership
Yours, entirely
Overview

Building it is the cheap part. Running it is the commitment.

Custom software is easy to start and expensive to abandon. The build itself is usually the most predictable phase. What decides whether it was a good decision is everything after: whether it can be deployed safely, whether a new engineer can understand it, whether a failure is visible before a user reports it.

So we build with that horizon in mind. Environments are set up to a security baseline with identity, secrets management, logging and backup handled from the start rather than retrofitted. Releases go through test coverage and regression suites so upgrades stop being a gamble. Documentation and source are handed over as a matter of course.

We also say no to custom builds fairly often. If a configured platform covers eighty percent of the requirement, building from scratch to capture the rest is rarely the right economics, and we will say so before the quote rather than after.

Scope

What Development & SaaS covers

From a first release of a SaaS product through to an integration layer over systems you already run.

What the work covers

  • Discovery, scope definition and a realistic release plan
  • Multi-tenant SaaS product development through to a billable release
  • Internal web and mobile applications over your existing systems
  • Documented, versioned REST APIs and an integration layer
  • Environments built to a security baseline: identity, secrets, logging, backup
  • Test coverage, regression suites and controlled releases

What you get at handover

  • Working software released to a real environment
  • Source code and a deployment guide
  • API documentation, versioned
  • Test suite and release checklist
  • Monitoring and alerting configured

Typically involves

REST APIs CI/CD
Discuss this practice
Services in this practice

Every Development & SaaS service

Software engineering

SaaS product development

Multi-tenant products built from discovery through to a released, billable product.

Open service page → 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-keying.

Open service page → Software engineering

Secure environment engineering

Application environments built to a security baseline: identity, secrets, logging and backup.

Open service page → Software engineering

QA, testing & release management

Test coverage, regression suites and release control so upgrades stop being a gamble.

Open service page →
01

Scoping a build when the requirements are not yet knowable

Every software engagement carries a tension between the certainty a buyer needs and the discovery a build requires. Pretending otherwise produces either a fixed price with a defensive scope that satisfies nobody, or an open ended arrangement with no incentive to finish. Our answer is to fix the scope of a phase rather than of the whole product. The first phase has a defined outcome, a defined budget and a defined date, and what follows it is planned with what the first phase taught everyone.

Phase one should contain something a real user can do from beginning to end, however narrow. A single workflow with authentication, real data, real permissions and a real deployment is worth more than five half built screens covering the entire feature list. It proves the architecture, exposes the integration problems and gives both sides a shared reference for what quality looks like. It also produces the first honest measure of pace, which is the only reliable basis for planning what comes next.

Scope documents should describe behaviour and its evidence rather than screens. A screen list invites argument about whether something was included. A statement that a user in a given role can perform a given action, and that success looks like a specific recorded outcome, can be tested and signed. We write acceptance criteria at that level during planning rather than during handover, which also removes most of the later disagreement about whether a particular item is a defect or a change.

  • Scope fixed per phase, with a defined outcome, budget and date for phase one
  • One complete narrow workflow delivered first, including authentication and deployment
  • Acceptance criteria written as testable behaviour before development starts
  • A defect and change definition agreed in writing at the same time
  • Planning based on measured pace from a real phase rather than a pre-build estimate
02

Architecture decisions you will live with for years

Tenancy is the first of them and the hardest to revisit. A product that separates each customer into its own database is straightforward to reason about, easy to restore for one customer alone and expensive to operate at scale. A shared schema is cheaper to run and unforgiving of a single missing filter in a query. Choose according to how many customers you expect, what they will demand about data separation, and whether you will ever need to move one customer to a different region.

Identity and residency follow closely. Deciding early that authentication belongs to an identity provider rather than to the application saves a great deal of retrofitting later, particularly when a corporate customer makes single sign on a condition of purchase. Residency behaves the same way. Moving an established product into a specific region afterwards means moving data, logs, backups and the third party services that quietly hold copies. Both decisions are cheap in week one and disruptive in year three.

Three smaller choices cause a disproportionate share of the later pain. Identifiers exposed in web addresses cannot be changed once customers have bookmarked them and built integrations against them. Times stored without an explicit zone produce defects that appear twice a year and confuse everyone. Money held as a floating point number produces rounding disputes that finance will eventually find. None of these is hard, and all of them are cheap in the first fortnight and expensive after the first real customer.

  • Tenancy model chosen against expected customer count and data separation requirements
  • Authentication delegated to an identity provider before customers ask for single sign on
  • Data residency decided with logs, backups and third party services included
  • Externally visible identifiers treated as permanent from the first release
  • Time zones and monetary precision handled explicitly rather than left to defaults
01

What a custom software development company in Pakistan charges

Typical market rates in Pakistan are quoted by the hour and by the project, and the two do not always agree. Published hourly figures put junior work at PKR 500 to 1,000, full stack work at PKR 3,500 to 8,000, and senior specialists at the top of that band. The same people billed internationally are quoted at USD 15 to 50 an hour, and premium agencies at USD 40 to 80. That gap is the whole reason this market exists, with Pakistani rates sitting roughly 60 to 80 percent below Western equivalents for work of the same standard.

Project pricing is easier to compare across suppliers. Published market ranges put a business website at PKR 80,000 to 200,000, an e-commerce build at PKR 120,000 to 500,000 and upwards, and a custom web application at PKR 200,000 to 1,000,000 and upwards. The upper bound of that last band is doing an enormous amount of work, because a custom application can mean an internal tool used by nine people in one office or a product you intend to sell to a bank.

What moves the figure is rarely the feature count. Integrations move it most, since every external system brings its own authentication, its own failure modes and its own owner who replies when they reply. User roles move it next, because each role multiplies what has to be tested before a release. Data migration from an existing system is routinely underestimated and routinely the largest single item in the end. Single sign on, offline capability, mobile and compliance evidence each add real work. Then there is the item missing from most business cases, which is the running cost after launch, and it does not stop simply because development did. Our own figure comes after discovery and is written against a scope, and the phase one number is the one we hold to.

  • Hourly and project pricing quoted against the same scope so the two can be compared
  • Integrations priced individually, since each carries its own owner and failure modes
  • Data migration scoped as its own workstream rather than folded into a build estimate
  • Running cost after launch stated in the proposal rather than discovered in year two
  • Phase one fixed on outcome, budget and date, later phases planned on measured pace
02

How long a custom build takes

Reported delivery timelines in the Pakistani market give three bands worth knowing. A focused scope reaches a first live release in six to twelve weeks. A mid sized product runs three to six months. Work at enterprise scale, with several integrations and a security review sitting in the path, runs nine to twelve months. Those figures describe the first release rather than the end of the work, because a product people actually use keeps generating work of its own.

Phase one should be short and complete rather than long and broad. One workflow, end to end, with real authentication, real data and a real deployment behind it, tells both sides more than a dozen screens covering the entire feature list. It also produces the first honest measure of pace, and pace measured once is worth more than any estimate produced before a line of code existed.

Delay usually arrives from outside the code. Access to systems provisioned in week three rather than week one. A third party API whose documentation describes a version that is no longer live. A decision needing four people in a room that gets one of them. Data that turns out to be far worse than anybody admitted, which is the classic and the expensive one. A security review scheduled after the build instead of beside it, then finding something structural. None of these is unusual, and every one of them is cheaper to plan for than to absorb.

  • First live release scoped as one complete workflow rather than a set of partial screens
  • A single named decision maker on your side, available inside the sprint
  • System access provisioned before the first sprint starts
  • Third party APIs tested against the live version early, not against their documentation
  • Security review run alongside the build rather than as a gate at the end
03

Build, buy or configure

Buying a finished product is the right answer far more often than anybody selling development will tell you. Accounting, payroll, help desk, customer relationship management and most of what a business does day to day are solved problems with mature products behind them, and each of those products has a roadmap, a support line and thousands of other customers finding the defects before you do. Where a licensed product covers the substance of a requirement, the remaining difference is rarely worth a code base you must maintain for a decade.

Configuration sits between the two, and it is where most of our honest recommendations land. A platform configured properly, using its own extension points rather than fighting them, covers a surprising amount of what people describe as unique to their business. The test is whether you are configuring or rebuilding. Adding fields, workflows, approval routes and reports is configuration. Replacing the product's core behaviour with your own because it does not match a habit is rebuilding inside somebody else's software, which is the worst of the three options and the hardest to escape.

Custom is right in three situations. The process is genuinely how you compete, so encoding somebody else's version of it gives the advantage away. No product fits, usually because the domain is narrow or the regulation is local. Or the software is the product, built to be sold. Outside those cases, building is a decision to take on maintenance, security patching, platform changes and hiring for the next decade, in exchange for a fit that a configured system would have reached most of the way to.

The clearest sign that custom is wrong is a requirement described as a cheaper version of a product you could licence today. Those economics do not survive once support, security work and platform changes are counted, and we decline that work rather than take it. We have talked clients out of builds and put the recommendation in writing before anything had been spent with us. Advice that costs us a project is still advice worth giving.

  • A licensed product first where the requirement is a solved problem with mature options
  • Configuration preferred where a platform's own extension points cover the difference
  • Custom reserved for competitive process, absent product fit, or software you intend to sell
  • Rebuilding a product's core behaviour inside it treated as a warning rather than a plan
  • A written recommendation against building wherever a configured system fits
04

Secure environments, code ownership and independent testing

Security in what we build starts with the environment rather than the code. Identity and access delegated to a managed provider, secrets held in a managed store instead of configuration files, logging that follows a single request across services, patching on a schedule, and backups that have been restored at least once. Application work follows OWASP guidance, which in practice means input validation, authorisation checked on every path rather than only the visible ones, dependency versions recorded so a vulnerability announcement can be answered in minutes, and the OWASP Top Ten used as a review checklist rather than a badge on a website.

Ownership should never be in question at any point. The repository, the pipeline, the infrastructure definitions and the environment credentials are yours from the first day, not handed across at the end as a reward for settling the final invoice. Intellectual property is assigned in the contract, in writing, before work starts. Where a customer of yours requires it, source code escrow with a neutral third party is arranged and we sign whatever that arrangement needs. We do not withhold code or environments to force a support renewal.

Independent testing is deliberately not ours to do. A penetration test commissioned from the team that wrote the code is worth very little, whatever the report eventually looks like. Where a contract or your own policy requires one, engage a firm with no stake in the build. We prepare the environment, remediate the findings and support the retest, and we will not issue a security opinion on our own work. Framework certification behaves the same way: we implement controls and produce evidence, and the certificate comes from your certification body after their own audit.

Cloud subscriptions and software licences are contracted by you directly. We are not a reseller, so the architecture we recommend cannot quietly reflect what earns us a margin.

  • Secrets in a managed store, identity delegated, logs traceable across services
  • OWASP guidance applied during review, with dependency versions recorded for response
  • Intellectual property assigned in writing before development starts
  • Source code escrow arranged with a neutral third party where a customer requires it
  • Penetration testing commissioned independently, with remediation and retest supported
05

Cloud or on premise

For most custom applications cloud is the default, and the reasons are practical rather than ideological. Environments can be created and destroyed at will, the same definitions build test and production, scaling becomes a configuration change, and managed identity, secrets and database services remove work nobody enjoys doing by hand. The cost is real and it grows, which is why it should be reviewed quarterly and attributed to the features generating it rather than simply watched.

On premise still makes sense in specific cases. An application talking constantly to a system already inside your network. A plant floor that cannot depend on an external link. A sector where your compliance advisers require the data to remain on your own infrastructure. What arrives with that choice is the operational work: patching, capacity, backup verification and the hardware relationship all become yours or your provider's, and the deployment pipeline has to reach into the network somehow.

Local hosting in Pakistan is a third option and it gets overlooked more than it should. Billing in rupees removes an exchange rate variable from a multi year cost, and latency from a Karachi office is lower than to a distant region. Check what a provider actually offers before committing, because managed database services, identity and object storage are not uniformly available, and an architecture that assumes them will need rework.

  • Cloud as the default, with cost reviewed quarterly and attributed to features
  • On premise where an application is chatty with systems already inside your network
  • Residency requirements confirmed with your compliance advisers rather than assumed
  • Local hosting considered where rupee billing removes exchange rate exposure
  • Managed service availability checked before an architecture comes to depend on it
How we deliver

Delivering Development & SaaS

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

Software you can change is the only kind worth owning

The value of custom software is not in what it does on the day it launches. It lies in whether you can change it in two years, when the process it encodes has moved on and the person who wrote it has not been in the building for a while. Everything above is aimed at that single property.

Pipelines, tests, documentation and honest handover are not process for its own sake. They are the difference between an asset and a liability with a login page. That distinction becomes visible at exactly the moment you need a change quickly, which is also the moment at which it is too late to acquire any of it.

Products, internal applications and team extension all sit in this practice, and we either support what we deliver or hand it over cleanly. Where the honest answer is that configuring something you can already licence beats building from scratch, we will put that in writing before you have spent anything with us.

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

Development & SaaS: the questions we are asked

Published market ranges put a business website at PKR 80,000 to 200,000, an e-commerce build at PKR 120,000 to 500,000 and upwards, and a custom web application at PKR 200,000 to 1,000,000 and upwards. Hourly, full stack work is quoted at PKR 3,500 to 8,000. Integrations and data migration move the figure more than feature count does. We quote after discovery, against a written scope.

Reported timelines in Pakistan put a focused first release at six to twelve weeks, a mid sized product at three to six months, and enterprise scale work at nine to twelve. Those describe the first live release rather than the end of the work. Data quality, third party APIs and slow decisions cause most of the delay, and none of them sit in the code.

Salary levels and cost of living, mostly. Published comparisons put Pakistani rates roughly 60 to 80 percent below Western equivalents, with international billing for the same skills quoted at USD 15 to 50 an hour. The difference is economic rather than a difference in standard. What varies between suppliers here, as anywhere, is engineering discipline: testing, deployment, documentation, and whether anyone else can maintain the result.

You own it, and the assignment is written into the contract before work starts rather than negotiated at handover. The repository, the pipeline and the environment credentials sit with you from the first day. Where a customer of yours requires source code escrow with a neutral third party, we arrange it and sign what it needs. We do not withhold code to force a support renewal.

No, and that is deliberate. A security test commissioned from the team that wrote the code is worth very little, regardless of what the report says. Engage an independent firm with no stake in the build. We prepare the environment, remediate the findings and support the retest, and we will not issue a security opinion on our own work.

Fix the phase rather than the product. Phase one gets a defined outcome, a defined budget and a defined date, because that is the part where the requirement is understood well enough to price honestly. What follows is planned using the pace that phase actually demonstrated. A fixed price on a whole product carries either a defensive scope or a margin for uncertainty, and usually both.

Yes. It suits an application that talks constantly to systems already inside your network, or a sector where your compliance advisers require data to stay on your infrastructure. What comes with it is the operational work: patching, capacity, backup verification and the hardware relationship. Local hosting in Pakistan is a third option, and rupee billing removes an exchange rate variable.

It means the OWASP Top Ten is used as a review checklist rather than a claim on a website. Input validation, authorisation checked on every path and not only the visible ones, secrets held in a managed store, and dependency versions recorded so a vulnerability announcement can be answered quickly. OWASP publishes guidance, not certificates, so treat any supplier claiming OWASP certification carefully.

Weighing a build against a platform?

Describe the process and we will give you an honest read on whether custom development is the right call, including when it is not.

Book a consultation See all practices