Custom Salesforce app development costs what its scope costs: the screens and objects it covers, the kinds of users who log in, the systems it connects to, the AI it includes, and who maintains it afterward. Licensing a portal costs something different: a recurring fee that grows with every customer or partner you invite. For a Build-vs-Buy IT Leader, the real comparison is a mostly one-time build that you own against a per-user bill that never stops, and the answer shifts toward building as your user count and your need for a differentiated experience grow.
There are no prices in this post on purpose. Every honest number depends on your org, and a cost post that quotes figures without seeing your scope is guessing.
Who this is for, and what the bill looks like today
This is for the IT leader who owns the build-or-buy call for a customer or partner portal on Salesforce, often at a mid-market lender, insurer, or distributor. You may already run a hand-built portal that one developer maintains, or a configured Experience Cloud site that works but keeps getting more expensive, or both at once.
The license side is structural, and it is worth understanding before any vendor gives you a number. Salesforce sells external-user access to Experience Cloud sites as member-based or login-based licenses. Member licenses suit frequent users. Login licenses are bought as a monthly pool, and each external user consumes one login per day they sign in. Whichever model you choose, the cost line scales with people, and it recurs every year.
Build cost behaves differently. It is concentrated at the start, and afterward it is mostly maintenance. That is why the comparison tilts as a portal grows: the license line keeps climbing with users, while the build line stays roughly where it was.
What actually drives the cost of a custom Salesforce app
When we scope a custom app on Salesforce, five things decide most of the effort.
Scope. How many objects, screens, and workflows the app covers. A portal that lets customers view orders and open cases is a small app. One that runs onboarding, document collection, approvals, and payments is a large one. Starting with a narrow slice is the single most effective way to control cost.
Users and how they sign in. Employees, customers, and partners have different identity and licensing paths in Salesforce. This choice affects both build effort and ongoing license cost, so it belongs at the start of the conversation, not the end.
Integrations. Every system outside Salesforce, such as billing, a loan origination system, or a data warehouse, adds design, testing, and long-term upkeep.
AI. An assistant that answers from your knowledge and records, or an AI agent that takes actions, adds work on grounding, permissions, and review. It also adds the most value per hour when it is scoped tightly.
Maintenance. Someone has to own the app after launch: Salesforce releases, security reviews, and new requests. A standard codebase your team can hire for keeps this line small.
The three ways to put a portal on Salesforce
Here is how the main options compare on the questions a Build-vs-Buy IT Leader actually asks. The point is not that one option always wins. It is that each one fits a different situation.
| Question | Experience Cloud site | SF Custom Portal Template (implementation package) | Custom React app on Salesforce |
|---|---|---|---|
| Recurring per-user license | Yes, per member or per login | No per-login Experience Cloud license | Depends on how external users sign in |
| Upfront effort | Configuration, plus custom components for anything unusual | Implementation on your org | A real build, scoped to your needs |
| Who owns the code | Salesforce owns the platform; you own customizations | You do, after handoff | You do |
| How different it can look and behave | Within the builder’s limits | Your brand, modules, and objects, by configuration | Anything your team can design |
| Best fit | Standard self-service on standard objects | A branded portal on your own data, fast | A differentiated customer experience |
Experience Cloud is the right call more often than its critics admit. If your portal is standard self-service on standard objects and the user count is modest, configuring a site is quick and well supported.
The SF Custom Portal Template is our answer for the middle ground: a branded customer, vendor, partner, or internal portal that runs inside your org, with unlimited members and no per-login Experience Cloud license. We deliver it as an implementation package rather than software you subscribe to, so after handoff the portal is yours.
A custom React app is the right call when the experience itself is the product. Since Salesforce Multi-Framework reached general availability on July 16, 2026, React is a supported way to build apps that run natively on the platform, with Salesforce authentication, security, and governance applied automatically. One honest caution: a customer-facing React external app deploys to an Experience target, so confirm the external-user licensing your design needs before you assume the license line disappears. Our implementation and configuration service covers how we design and build these apps, delivered on App Kit as a build you own rather than a product you license.
If your team already maintains a hand-built portal, the comparison is slightly different. The question is whether to keep paying a developer to maintain a one-off, consolidate onto a supported React codebase on the platform, or move the standard parts onto a template and keep custom code only where it earns its keep. We cover the migration side in why companies move from Experience Cloud to own-code portals.
How Funnelists approaches it as your AI advisor
Most portal projects are really AI projects waiting to happen. Once customers or partners sign in to one place, that place becomes the natural home for an assistant that answers from your own knowledge, an agent that opens or updates cases, or a guided workflow that cuts the back-and-forth.
So we scope the portal with the AI decisions in view from day one. Which data an assistant may read, which LLM provider your security team approves, and which actions need a person to sign off all influence how the portal should be built. Getting them right early is cheaper than retrofitting them later.
That is also why we treat the portal as a starting point. It is a practical first project that saves money on licensing, and it gives us a working foundation on your own org for the AI work that follows, whether that is a Salesforce Multi-Framework app for a second audience or agents in Service Cloud.
Honest limitations
- Building means owning. A custom app needs someone to maintain it. If no one on your team or ours will own it after launch, licensing may be the safer choice.
- Multi-Framework has prerequisites. It requires a Hyperforce org on the Summer '26 release or later. Check that before you plan around it.
- Scope creep is the real cost risk. Most overruns come from adding screens mid-build, not from the technology. A narrow first release protects the budget.
Decision framework: license, template, or build?
License an Experience Cloud site when:
- The portal is standard self-service on standard objects.
- The user count is modest and unlikely to grow quickly.
- You have no one to own a codebase after launch.
Use the SF Custom Portal Template when:
- You want a branded portal on your own Salesforce data, live quickly.
- Per-login licensing is already a budget conversation.
- Configuration, not custom code, covers what users need.
Build a custom React app when:
- The portal experience is a competitive difference, not a utility.
- You need workflows or a design that no builder or template can produce.
- You will serve several audiences from one codebase and want your team to be able to hire for the stack.
Cost depends entirely on scope, which is why we size it on a free 30-minute intro call rather than publishing a number that would not fit your org. Bring your current portal, your user counts, and the one thing users complain about most.
FAQ
What does custom Salesforce app development cost?
It depends on scope, the kinds of users who sign in, integrations, AI features, and maintenance. Any credible estimate starts from those five factors in your own org, not from a published figure.
Is it cheaper to build a portal than to license Experience Cloud?
Often, as user counts grow. Experience Cloud licensing recurs per member or per login, while a build is mostly a one-time cost plus maintenance. For small, standard portals, licensing can still be the better value.
Should I build a custom Salesforce app or use a managed package?
Use a package or template when it covers your needs through configuration. Build custom when the experience itself is a differentiator or the workflows are unique to your business.
Can I build a customer-facing app on Salesforce in React?
Yes. Salesforce Multi-Framework, generally available since July 2026, supports React apps that run natively on the platform. Customer-facing apps deploy to an Experience target, so plan for external-user licensing in your design.
Does a custom portal weaken Salesforce security?
Not when it is built on the platform. Apps built this way inherit your sharing rules, profiles, and permission sets instead of recreating them outside Salesforce.
The takeaway
The cost of custom Salesforce app development is a scope question, and the cost of licensing is a headcount question. If your portal is small and standard, license it. If it is branded but standard in function, start from a template you own. If the experience is the product, build it in React on the platform and own the code. Make that call with your user growth in view, and with the AI work that will follow already in mind.
Read Next
Why Build-vs-Buy IT Leaders Decouple the Salesforce Frontend for Custom Customer Portals
Build-vs-Buy IT leaders are decoupling the Salesforce frontend to own the customer experience while keeping Salesforce as the secure, automated backend. Here is the decision framework they actually use.
How Do SF Platform Architects Implement Salesforce Micro Frontends Without Framework Lock-In?
SF Platform Architects implement Salesforce micro frontends with Multi-Framework and MFE Developer Preview using sandboxed iframes and the Platform SDK to avoid framework lock-in.
How Do SF Platform Architects Build Headless Salesforce Experiences with Multiple Frameworks?
SF Platform Architects build headless Salesforce experiences by exposing core data through APIs and composing frontends from React, LWC, Vue and more—without framework lock-in.
