SmartLink
Software engineering

Custom application development in Pakistan

Custom application development in Pakistan is usually bought to close one gap: a process the packaged system refuses to model, handled today in a spreadsheet somebody updates before breakfast. SmartLink Services builds those applications from Karachi against the ERP, database or HR system you already run, on React, TypeScript, Node and PostgreSQL. Below are the questions a proposal rarely reaches. What a build costs at market rates, how long it takes once system access exists, and how to tell a genuine custom requirement from something the platform you own could be configured to do. Source code and environments stay yours throughout, and we put a recommendation against building in writing when that is the honest answer.

Discuss this service
Targets
Web \u00b7 mobile browser
Integration
Existing ERP / DB
Ownership
Code is yours
Overview

The gap a package leaves is usually specific and small.

Packaged systems cover the common case well and stop at the edge of it. What remains is often a single process that matters a great deal to one department: a dispatch approval that needs three signatures in a particular order, a field inspection that happens where there is no signal, a reconciliation between two systems that somebody performs every morning in a spreadsheet. These are not large requirements. They are specific ones, and specificity is exactly what packaged software is bad at accommodating.

Building against the systems you already run, rather than beside them, is the distinction that matters most. An application keeping its own copy of customer master data creates a second version of the truth and a reconciliation problem that outlives whoever built it. We read from and write to the ERP or the database that already owns each item, and where a write is genuinely not possible we make that constraint explicit rather than working around it with a nightly copy nobody remembers.

We start with a prototype that can be clicked through before anything at all is built. It is far cheaper to change a screen in a design tool than in production, and requirements written as prose get agreed with a great deal more confidence than they actually deserve. Users approve documents they have not fully imagined, which is nobody's fault and entirely predictable. They give much better feedback on something they can walk through, which is why the prototype stage tends to save more time than it costs.

Scope

What Custom application 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

  • Requirement workshops and clickable prototype before build
  • Role-based web application development
  • Mobile-responsive interfaces for field and floor use
  • Integration with ERP, HRM and database sources
  • Offline and intermittent-connectivity handling where needed
  • Deployment, monitoring and support arrangement

What you get at handover

  • Deployed application with environments
  • Prototype and approved specification
  • Source code and build instructions
  • Test cases and results
  • User and administrator guides

Typically involves

REST APIs
Discuss this service
01

Reading and writing against a system you do not own

Building on top of an ERP means accepting somebody else's model of the world. The fields you want may not exist, the validation you need may live in a screen rather than in the data layer, and a direct database write can bypass logic that keeps the ledger consistent. The first task is establishing what is genuinely safe to write, which is a question for the ERP owner and sometimes for the vendor, and it is worth settling before design rather than during testing.

Where a supported interface exists, use it even when it is slower than the alternative. Direct table writes are tempting and they are the reason some organisations can no longer upgrade. Where no interface exists, an adapter isolating the integration into one component keeps the awkwardness contained, so when the underlying system is upgraded the change lands in one place. Caching reference data locally is reasonable. Caching transactional data usually is not, and that distinction deserves an explicit argument.

Failure behaviour needs deciding at design time rather than in production. If the ERP is unavailable, does the application refuse the action, queue it, or record it locally and reconcile later. All three are legitimate and they suit different processes. What causes real damage is not deciding at all, because the default in that situation is that the application appears to succeed while the data quietly diverges, and somebody in finance discovers it several weeks later.

  • Safe write paths agreed with the system owner before design, not discovered during testing
  • Supported interfaces preferred over direct table access, even where slower
  • Integration isolated into an adapter so an upgrade touches one component
  • Reference data cached locally where appropriate, transactional data generally not
  • Explicit agreed behaviour for the case where the source system is unavailable
02

Applications that work where the network does not

Field and floor applications meet conditions that office applications never do. A warehouse with dead spots between the racking, a plant room with no signal at all, an inspection route through a site with intermittent coverage. If the application requires connectivity in order to record anything, people will use paper and transcribe it later, which is precisely the process the application was commissioned to replace, now carrying an additional step and an additional chance to introduce errors.

Offline capability is a real engineering cost and should be scoped rather than assumed. Reading cached reference data offline is straightforward. Recording new entries offline and synchronising them afterwards is moderate. Allowing offline edits to the same record from two devices is genuinely hard, and it needs a conflict rule decided by the business rather than invented by a developer. Most requirements need only the first two. Occasionally the third is necessary, and it should be priced honestly when it is.

Device reality matters as much as the code does. A screen in direct sunlight, a phone inside a protective case, gloves, a scanner that does not pair reliably, a battery that will not last a full shift. We test on the devices people will actually carry, in the place they will actually use them, because a demonstration on a desk proves very little about a stores area or a site perimeter at seven in the morning.

  • Offline scope defined explicitly: cached reads, queued writes or full conflict resolution
  • Conflict rules decided by the business where two devices can edit the same record
  • Synchronisation state visible to the user, so nobody wonders whether an entry was saved
  • Testing on the actual devices, in the actual conditions, before release
  • Battery, scanner pairing and sunlight readability treated as requirements rather than surprises
01

What custom application development costs in Pakistan

Published market pricing in Pakistan puts a custom web application at PKR 200,000 to 1,000,000 and upwards. That band is carrying an enormous amount of weight, because it covers an internal tool used by nine people in one office and a system three departments depend on to release stock every morning. Where a mobile client is needed for field or floor use, published pricing for a mobile application adds PKR 400,000 to 800,000. A business website sits at PKR 80,000 to 200,000 and is a different kind of purchase altogether, which is where a good deal of disappointment begins.

Hourly rates give the other view. Junior work in this market is quoted at PKR 500 to 1,000, full stack development at PKR 3,500 to 8,000, and senior specialists at the top of that band. Smaller applications tend to be quoted by the hour and larger ones by the phase, so ask for both against the same written scope if you want a comparison that means anything.

Integration is the largest driver, and it is seldom the part a client expects. Reading a stock figure from an ERP through a supported interface is one price. Reading it where no interface exists, so an adapter has to be built against a database the vendor supports on their terms, is another price entirely. Roles come next, since each additional one multiplies the test matrix rather than adding a screen. Offline capability for a field inspection or a floor terminal changes the architecture, because two people editing the same record on two phones with no signal is a conflict rule somebody has to decide. Data carried across from the old system is routinely the largest single line and routinely missing from the first estimate. Then the running cost, which every application in daily use generates: hosting, support hours and a steady trickle of small changes. All of that is market pricing rather than our quotation. A real figure follows discovery, once the integration points, the roles and the state of the existing data are on paper.

  • Custom web application pricing published at PKR 200,000 to 1,000,000 and upwards
  • A mobile client priced separately, at a published PKR 400,000 to 800,000 for the application
  • Each integration point costed against the far system rather than as a single line
  • Offline working treated as an architectural decision with a written conflict rule
  • Migration of existing data scoped as its own workstream with an owner
02

How long a custom application takes to build

Reported delivery timelines in this market put a focused single scope go live at six to twelve weeks and a mid sized build at three to six months. Most internal applications belong in the first band or just past it, as long as the scope is one workflow rather than a department's entire year of wishes.

Access decides more of the schedule than the code does. A read only database account, an API key, a test environment that behaves like production: each has an owner, an approval and sometimes a security review, and asking for them in week three instead of week one is the commonest self inflicted delay we see. Where the far system belongs to a vendor, their response time is added to yours and it is rarely measured in hours.

Prototype approval is the second gate and it deserves protecting. People approve written requirements they have not fully pictured, then react honestly to a screen they can click through. That reaction is the whole point, and it is far cheaper in a design tool than in production. It does need the people who actually do the work in the room rather than a manager describing what they think happens.

Then there is the data. An application starting with three years of history inherits the duplicates, the free text sitting where a code belongs and the customer spelled four different ways. Cleaning that is project work with a name and a date against it. We put content, access and data owners on the plan beside the technical milestones, and we say plainly what moves when one of them slips.

  • Six to twelve weeks reported for a focused single scope go live in this market
  • System access, keys and a test environment requested before the first sprint begins
  • Vendor response time on the far system included in the plan as a known queue
  • Prototype reviewed by the people who do the work rather than by their managers
  • Existing data profiled early, since cleansing effort cannot be judged before it is
03

Building the application or configuring the system you already run

Ask the awkward question first. Can the system you already pay for be made to do this? Most enterprise platforms carry extension points nobody in the building has been trained on: user defined fields, approval routes, a validation hook, a report writer, a low code builder that arrived with the licence and was never opened. We have watched a three month application request turn into a fortnight of configuration and one training session, leaving the client with a maintenance burden of nothing at all.

The test that matters is whether you are configuring or rebuilding. Adding a field, an approval route, a validation rule and a report is configuration, and it survives the vendor's next upgrade because it uses shapes the vendor supports. Replacing the platform's own posting logic, or growing a parallel screen because the standard one asks for something a manager dislikes, is rebuilding inside somebody else's software. That is the most expensive option available and the hardest to leave, because the upgrade you can no longer take is invisible until the morning you need it.

Custom earns its cost in narrower circumstances than most requests assume. The process is genuinely how you compete, so encoding a vendor's version of it gives away the part that makes money. No product models the domain, which here often means a local commercial or regulatory practice nobody built software for. The requirement crosses several systems, belongs to none of them and cannot sensibly live inside one. Or the work continues where there is no signal, which packaged web software handles poorly.

Two patterns are worth naming because they keep recurring. A department asks for an application that is, described plainly, a cheaper version of a product they could licence this month, and those economics do not survive security patching, platform changes and whoever maintains it in 2031. We say so and decline rather than take the work. The second is an application that quietly keeps its own copy of customer or item master data. That is a second version of the truth and a reconciliation job outliving everybody who agreed to it. Where a write back to the system of record is genuinely impossible, the constraint gets written down rather than covered with a nightly copy nobody remembers.

  • Platform extension points examined before a build is scoped, including the low code tools already licensed
  • Configuration preferred wherever it uses shapes the vendor will still support after an upgrade
  • Custom reserved for competitive process, absent product fit, cross system scope or offline work
  • A written recommendation against building where a licensed product covers the requirement
  • No second copy of master data, and any unavoidable constraint recorded rather than hidden
How we deliver

Delivering Custom application 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

Yours to keep and to change

The code, the build instructions and the environments are yours. That sounds like a formality and it decides how the next three years go, because an application you cannot change without its original author is a dependency rather than an asset. We write for somebody else to read, keep the dependency list conservative, and document the parts that are genuinely surprising rather than the parts any competent developer would work out in an afternoon.

Handover works better as an overlap than as an event. Your developers in the repository during the build, a runbook covering the recurring operational tasks, and a period where they make changes while we review. Where you have no internal team, a support arrangement is a perfectly legitimate answer, and it should be an explicit choice made at the start rather than a situation you end up in by default.

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 Custom application development

Published market pricing puts a custom web application at PKR 200,000 to 1,000,000 and upwards, with a mobile client adding a published PKR 400,000 to 800,000. Hourly, full stack development here is quoted at PKR 3,500 to 8,000. Integration points, user roles and the state of the data you are bringing across move the figure far more than screen count does. We quote after discovery.

Reported timelines give a focused single scope go live at six to twelve weeks and a mid sized build at three to six months. Most internal applications sit in the first band. Getting database access, API keys and a usable test environment is the commonest delay, followed by data that turns out to need cleaning before it can be loaded at all.

Look at the platform first, including the low code builder and report writer that arrived with the licence and were never used. Adding fields, approval routes and reports is configuration and survives the next upgrade. Replacing the product core behaviour is rebuilding inside somebody else software, which costs most and is hardest to escape. We will recommend configuration where it fits.

Read, almost always. Write, only where a supported interface exists or the ERP owner confirms a direct write is safe. Bypassing the validation that keeps a ledger consistent is how organisations lose the ability to upgrade. Where no supported route exists we build an adapter that isolates the awkwardness in one component, so a later upgrade lands in one place.

Yes, and the assignment is written into the contract before development starts rather than negotiated at handover. The repository, the build pipeline and the environment credentials are yours from the first day. We work inside your accounts using named access that can be revoked without touching anything else. We do not hold code back to secure a support renewal.

Yes, and it is a written arrangement rather than goodwill. Hours, response times, who may raise a request, and what counts as a change rather than a defect. Every application in daily use generates a steady trickle of small changes, so the only question is whether that trickle is planned or handled by whoever happens to be free. Field applications working offline need more of it.

More in Development & SaaS

More Development & SaaS services

Software engineering

SaaS product development

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

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 →

Is a spreadsheet holding a process together?

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

Book a consultation All development & saas