A custom customer portal budget should cover discovery, design, development, integrations, testing, launch, and ongoing operation. The biggest variables are usually what customers can do, which systems the portal connects to, and how access is separated between accounts. A login screen and dashboard are only the visible part of the work.
For an operations leader or technology buyer, the useful question is: “What will it cost to deliver our first complete customer workflow reliably?” This guide explains US versus India delivery costs, what AI tools change, and how to scope a portal budget you can explain internally.
How much does a custom customer portal cost?
There is no defensible single price without a defined scope and delivery rate. Use this model: initial budget = estimated delivery hours × agreed blended hourly rate + third-party setup costs + contingency. Then budget recurring hosting, licenses, support, and improvements separately.
Illustrative calculation only: if your scoped release requires 800 hours and your agreed blended rate is $50 per hour, delivery costs $40,000. Adding a hypothetical 15% contingency makes the planning allowance $46,000 before third-party fees, taxes, and ongoing costs. These inputs demonstrate the calculation; they are not Salt pricing, a market average, or a quote.
The example assumes the hours include discovery, UX, engineering, project coordination, QA, and release preparation. If a proposal counts developer hours alone, it is not directly comparable. Ask each supplier to identify included roles, assumptions, exclusions, and what could change the estimate.
US development team vs. an Indian agency: how do costs compare?
An Indian development agency can offer a lower delivery cost than a US agency, but compare equivalent scope, seniority, and delivery responsibilities. Hiring US employees is a third option with a different cost structure. Salary, agency fees, and the price of a completed portal are not interchangeable.
For context, Clutch’s software development pricing guide, updated September 21, 2026, lists location-based hourly ranges of $50–$99 for US companies and $25–$49 for companies in India. These broad directory benchmarks are not portal-specific estimates or Salt’s rate card. Specialist teams and individual proposals can fall outside them.
| Agency location | Published hourly benchmark | 800-hour calculation |
|---|---|---|
| United States | $50–$99 | $40,000–$79,200 |
| India | $25–$49 | $20,000–$39,200 |
The 800 hours are an assumption for comparison, not an estimate for your portal. These totals exclude contingency, taxes, third-party costs, and ongoing operation. Confirm that each quote includes the same design, engineering, QA, management, and launch work; a published hourly band does not establish that coverage.
What if you hire your own US team?
The US Bureau of Labor Statistics reports a median software developer wage of $135,980 annually in May 2025. Two developers employed for three months at that annualized wage would represent $67,990 in wages alone. That excludes benefits, employer costs, recruiting, equipment, and other delivery roles. It is a staffing illustration, not a portal estimate or a comparison with 800 agency hours.
An internal team can make sense when you have a continuing product roadmap and engineering leadership. An agency can make sense when you need a defined delivery team without recruiting every role yourself. If employees are already on staff, compare their available capacity and the work they would postpone, rather than treating their full salaries as a new project expense.
Where an Indian agency like Salt can add value
Salt’s engineering center in Pune gives US buyers an India-based delivery option for custom portal development. Request a scoped proposal identifying team allocation, responsibilities, milestones, and support. The opportunity is to combine a suitable delivery cost with relevant experience and coordinated execution.
Include your own review time, working-hour overlap, handoffs, and integration dependencies in the comparison. Agree who answers questions during your US business day and who owns release decisions. Geography alone does not establish quality, and a lower hourly rate does not guarantee a lower total cost.
Which portal scope are you actually buying?
Two projects called “customer portals” can have very different delivery requirements. Classify the workflow before comparing prices.
| Portal scope | Example first release | Main effort drivers |
|---|---|---|
| Information access | Customers view approved account documents and status information. | Identity, account mapping, document permissions, and data freshness. |
| Service workflow | Customers submit requests, upload files, and follow progress. | Assignment rules, notifications, staff tools, exceptions, and audit history. |
| Connected transactions | Customers place orders or update records across business systems. | Write access, validation, approval rules, synchronization, retries, and reconciliation. |
Start with the smallest scope that completes a real task. A request form that still leaves your team manually copying every submission into another system may move work around without reducing it.
Seven decisions that change the development budget
1. Customer accounts and permissions
List who can view, create, approve, download, and delete each type of record. A customer with several locations may need account administrators, branch users, and external advisers. Define how invitations, account transfers, and revoked access work. Test that one customer cannot retrieve another customer’s records or files.
2. CRM, ERP, and other integrations
Identify the source of truth for every record and whether the portal only reads data or also changes it. Review API documentation, licensing, a test environment, rate limits, and failure handling before agreeing to a fixed integration scope. “Connect to our ERP” is not a complete requirement.
3. Workflow rules and exceptions
Describe the normal path and the uncomfortable cases: duplicate requests, rejected documents, cancelled orders, missing approvers, and unavailable upstream systems. Decide what the customer sees and which employee owns recovery. These rules affect both engineering and testing effort.
4. Existing data and migration
Separate migrating historical records from connecting live data. Duplicate customer accounts, inconsistent identifiers, and unclear document ownership create additional work. Agree who cleans the data and how migrated records will be checked before launch.
5. Security and accessibility acceptance
Put identity, access control, file handling, monitoring, and security review into the scope. Agree an accessibility target and include checks for keyboard use, labels, error messages, and focus behavior. The W3C Web Content Accessibility Guidelines overview explains the accessibility standard and its testable criteria. A supplier should explain how the agreed criteria will be verified.
6. Internal operations and support tools
Customers need a useful interface; staff need a way to resolve problems. Budget for request ownership, safe administrative actions, activity history, and support visibility. Avoid making routine corrections depend on a developer editing production data.
7. Rollout and ongoing ownership
Define the pilot group, acceptance owner, training, monitoring, rollback plan, and support handover. If a third-party system is unavailable, agree whether the portal should show the last known status, pause the action, or queue it safely. Responsibility should be clear before customers depend on it.
Should you buy an existing portal or build a custom one?
Evaluate an existing product first when its workflow, permission model, and integrations meet your needs. Compare configuration effort and recurring license costs with custom development and maintenance. Check limits around customer seats, API access, branding, data exports, and required add-ons.
Custom development becomes more relevant when your customer journey spans several systems, permissions are unusual, or the workflow is a meaningful part of your service. A hybrid approach can also work: keep an established CRM or ERP as the system of record and build only the customer experience and integration layer you need.
Use the same demonstration scenario for every option: one customer signs in, completes a request, receives an update, and sees only their own information. Ask the vendor to show an exception as well as the successful path.
How have AI tools changed customer portal development?
AI coding tools and app builders can shorten the path to a working draft. They can help produce interface scaffolding, routine code, test drafts, and documentation. A business team can use an early prototype to explain its workflow and get feedback before committing to a larger build.
GitHub’s guidance for Copilot describes assistance with repetitive code and test generation while retaining the need for human review. Generated code and tests still need to be checked against the intended behavior. Using AI to build a portal is also different from adding AI features inside it: you can use coding assistance without shipping a chatbot or model-powered workflow.
| Work area | Where AI can help | What the team must verify |
|---|---|---|
| Customer interface | Draft screens, forms, and reusable components. | Real workflows, accessibility, error states, and mobile behavior. |
| Business systems | Draft integration code from supplied API details. | Actual API behavior, record mapping, retries, and duplicate prevention. |
| Access and testing | Suggest checks and generate test scaffolding. | Account isolation, server-side authorization, and independent acceptance tests. |
| Launch and operation | Assist with configuration and documentation drafts. | Secrets, backups, monitoring, rollback, and support ownership. |
Does AI automatically make the whole project cheaper?
No fixed percentage applies to every portal. Savings depend on which tasks can be accelerated, the quality of generated output, and how much correction and verification it needs. Ask a partner to identify where AI changes its effort estimate and which responsibilities remain included.
Illustrative scenario: in an 800-hour plan, suppose 40% of the effort is suitable for AI assistance and that portion takes 25% fewer hours. That saves 80 hours, or 10% of total effort, before any additional review or rework. It does not make the entire project 25% cheaper. These are hypothetical inputs, not measured Salt productivity results.
Compare the revised delivery estimate plus tool subscriptions, usage charges, platform hosting, and review effort. With a fixed-price engagement, agree on the deliverable and price; faster coding does not automatically change the contract. If using an app builder, check source export, data export, integrations, and migration options before choosing the platform.
Why work with an agency when AI can build a portal?
For a business-critical portal, an experienced agency can turn an AI-assisted draft into a system with defined delivery and operating responsibilities. Its value comes from understanding the workflow, making architecture decisions, validating the implementation, and owning the agreed handover and support—not simply producing code.
For example, an order-status screen may look complete while using sample data. A production release must map the signed-in customer to the correct ERP account, enforce that restriction on the server, handle an unavailable ERP, and prevent another customer from downloading the order document. Those behaviors need explicit acceptance checks.
- Scope and architecture: decide what to build, what to reuse, and how systems and permissions fit together.
- Code and data review: inspect generated changes, dependencies, secrets handling, and the rules for sharing project data with AI tools.
- Independent validation: test real user journeys and failures rather than relying only on tests generated alongside the code.
- Delivery continuity: establish repository access, documentation, deployment ownership, and named release responsibilities.
- Post-launch care: agree who handles defects, dependency updates, monitoring, and future changes.
A capable in-house engineering team can provide these responsibilities too. A simple prototype using dummy data may be reasonable to build yourself. Agency support becomes more valuable when the portal serves real customers, holds sensitive information, updates business systems, or lacks an experienced internal owner.
When evaluating Salt or another agency, ask who reviews AI-generated work, which tools and data policies apply, and how acceptance and support are documented. Judge the partner by those commitments and relevant project evidence. If you already have an AI-built prototype, discuss a production-readiness review with Salt before deciding what to retain, improve, or rebuild.
What should a first portal release include?
For a hypothetical B2B service portal, a focused release could serve one customer group and one request type, connected to one business system. The following are example acceptance criteria, not claims about a delivered Salt project:
- An invited customer can sign in and access only their account.
- A customer can submit a request with the required information and permitted attachments.
- A named internal owner can review the request and publish a customer-visible status.
- The agreed system receives the record, and failed synchronization is visible to an operator.
- Notifications do not expose another customer’s information.
- Agreed security, accessibility, and user acceptance checks pass before rollout.
Defer additional workflows and optional reporting until the first task works end to end. Set a baseline for repeated status enquiries, request completion, and staff handling time so you can evaluate whether the release helps.
How do you compare portal development proposals?
Give each partner the same brief. Ask for an estimate broken into discovery, UX, engineering, integrations, QA, project coordination, and rollout, with dependencies and exclusions next to each item.
- Scope: Which customer and staff workflows are included?
- Evidence: Can the partner show relevant portal work and explain its actual delivery role?
- Estimate: What effort range is proposed, what assumptions support it, and how are changes priced?
- Ownership: Who controls the repository, deployment accounts, documentation, and third-party licenses?
- Acceptance: Who signs off, against which criteria, and what happens when a defect is found?
- Operations: What support hours, response arrangements, maintenance, and recurring fees are included?
A lower headline price can exclude work that another proposal includes. Normalize the scope before comparing totals. Our software development partner selection guide provides a broader evaluation framework.
What does a portal cost after launch?
Separate running the current portal from adding capabilities. Your operating budget should identify hosting, storage and backups, email or messaging, identity services, paid APIs, monitoring, maintenance, and support. State usage assumptions such as active accounts, file volume, retention, and notification frequency.
Use a three-year comparison: initial delivery + third-party setup + 36 months of recurring operating costs + planned improvements. For example, a purely hypothetical $1,000 monthly operating allowance adds $36,000 over three years. Obtain actual supplier and infrastructure estimates rather than treating that number as a benchmark.
Where does Salt Technologies fit?
Salt Technologies develops custom customer and partner portals and related business software. In the MyPowerStock engagement for Power Promotions, Salt’s documented scope covered a custom inventory and sales enablement portal, product engineering, and CI/CD and DevOps support.
That case illustrates relevant portal delivery experience; it is not a pricing benchmark. The public project summary does not publish a budget, timeline, or measured return, so none is implied here.
If your team needs a partner to coordinate delivery, explore managed development teams. If you already lead the work and need engineering capacity, consider dedicated developers.
Customer portal development FAQs
Can you estimate a portal before detailed specifications exist?
Yes, as a provisional estimate with explicit assumptions. Share the main workflow, user roles, connected systems, and constraints. Use discovery to resolve the highest-risk unknowns before treating the budget or dates as commitments.
How long does customer portal development take?
A reliable schedule depends on scope, team allocation, integration access, and review turnaround. Ask for milestones covering discovery, a working workflow, integration validation, acceptance, and rollout. Developer availability alone does not determine the launch date.
Does a customer portal need AI?
No. Secure self-service and connected workflows can provide value without AI. Consider search, classification, or assistance only when there is a defined task, suitable data, and a way to evaluate errors. AI should not replace account-level access controls.
What should we send Salt for a scoping conversation?
Send your customer workflow, approximate user volume, role list, CRM or ERP names, current pain points, target date, and budget constraints. An anonymized example is useful; do not send passwords or live customer records through an enquiry form.
Discuss your customer portal with Salt to review the first useful release, dependencies, and information needed for an estimate.