Web portal development in Pakistan: customer, dealer and partner portals

What a web portal costs in Pakistan

A portal is priced as a custom web application rather than as a website, and published market rates for that work run PKR 200,000 to 1,000,000 and upwards. The lower end covers one external audience reading one thing: dealers checking order status, say, with a login and a read only view. The upper end covers several audiences, documents, ticketing, statements, exports and a permission model that has to be right the first time. A business website at PKR 80,000 to 200,000 is not the comparison, however similar the two look in a design.

Hourly rates are worth quoting alongside. Full stack development here is published at PKR 3,500 to 8,000 an hour, junior work at PKR 500 to 1,000, and a permission model is not junior work. Where a mobile application accompanies the portal for field or dealer use, published market pricing for that adds PKR 400,000 to 800,000.

User types set the price, and every organisation underestimates how many they have. A customer, a customer's accounts clerk who may see invoices but not prices, a dealer, a sub dealer under that dealer, a sales manager who sees a region, an internal administrator. Each is a permission rule and a test case, and the rules multiply rather than add. Reading from an ERP that was never designed to face the internet is the second line, and it usually means a service layer, a read replica or a cache with a defined staleness rather than a direct connection. Documents are third: statements and delivery notes have to be generated or fetched, stored somewhere with retention agreed, and served only to the account that owns them. Auditing external access is fourth and it is not optional. Everything above is market pricing. A real figure follows discovery, once the audiences, the data sources and the document flows are written down.

• Portals priced against custom application rates of PKR 200,000 to 1,000,000 and upwards
• Every external user type enumerated before pricing, since permission rules multiply
• A service layer or read replica costed rather than a direct connection to the ERP
• Document generation, storage and retention treated as scope in its own right
• A companion mobile application priced separately at a published PKR 400,000 to 800,000

How long a portal takes to build

Reported timelines put a focused single scope go live at six to twelve weeks, which fits one audience with one or two views: order status and invoice history for dealers, with a login and an audit log behind it. Three to six months is the honest band for several audiences with tickets, documents, exports and single sign on.

Access to the ERP is the first gate and it is rarely quick. A read account, a test environment holding realistic data, and agreement from whoever owns that system about what may be read and how often. Where the ERP belongs to a vendor under a support contract, their opinion is part of the schedule and their response time is not yours to manage.

Identity is the second. Deciding how an external user proves who they are, who may invite a colleague, what happens when a dealer's accounts clerk leaves, and how an account is suspended: these are business decisions with a policy behind them, and a portal built before they are settled gets rebuilt.

The third is data that is not fit to show. Statements that only balance after a manual adjustment, delivery notes filed under three naming conventions, prices that need a person to interpret them before they mean anything. A portal makes all of that visible to a customer, which is the point of it and also the risk, so we look at real records in the first fortnight rather than at a sample somebody tidied up for the meeting. Fixing what that exposes is often a separate piece of work and it is better found early than after launch.

• Six to twelve weeks reported for one audience with one or two views
• Three to six months once tickets, documents, exports and single sign on are in scope
• ERP read access, a realistic test environment and vendor agreement requested first
• Identity, invitation and suspension policy settled before the permission model is built
• Real records reviewed early, since a portal exposes data quality to your customers

Extending the portal your ERP already ships or building your own

Before commissioning anything, find out what you already own. SAP, Oracle, Dynamics, Odoo and most mid market products ship a customer or partner portal of some kind, and a proportion of the organisations that ask us for a portal are paying maintenance on one already. Where the requirement is order status, invoice history and a document download, the vendor module often covers it, and it comes with the vendor's authorisation model rather than one we would have to invent.

The costs of that route are real and they are commercial rather than technical. External users are frequently licensed, so a portal offered to nine hundred dealers is a licence conversation before it is a project. The interface is the vendor's, so it will look like the ERP rather than like your company, and the things it cannot do it cannot be made to do. Upgrade cycles apply to it too. Ask three questions before committing: what does an external user cost, what can be changed, and what happens to those changes at the next upgrade.

Building your own earns its cost where the portal has to do something the ERP does not model. Several systems behind one login, so a customer sees orders from the ERP, tickets from a service desk and documents from a file store without knowing there are three. An audience the ERP has no concept of, such as a sub dealer under a dealer. A workflow that belongs to your business, like a claim raised against a delivery with photographs attached. Or a licence position where per user pricing makes the vendor module absurd at your audience size.

What we advise against in both directions is a portal that adds a step. If a dealer still telephones to confirm what the portal told them, the portal has not removed the call, it has added a screen. So the measure agreed before anything is built is which specific queue this removes, whose telephone stops ringing, and what those people will do instead. We have recommended a client use the module they already licensed and walked away from the build, and we would do it again.

• Vendor portal modules checked for coverage before a custom build is scoped
• External user licensing established early, since audience size can decide the answer
• A custom portal justified by several sources behind one login or an audience the ERP lacks
• Workflows that belong to your business, such as delivery claims, built rather than forced
• The specific queue the portal removes agreed in advance as the measure of success