This is one of the hardest questions to answer honestly, because the true answer is “it depends,” and that’s not satisfying when you’re trying to budget. But I’d rather give you the actual framework for figuring it out than a fake number that doesn’t match your project.
Why the range is so wide
A custom web app can mean a simple client login portal showing order status, or a full multi-user system with permissions, integrations, payment processing, and custom workflows. Those two things can differ by a factor of ten or more in cost. Anyone quoting you a single number without understanding your specific requirements is guessing.
The variables that drive cost
Number of user roles and permission levels. A portal where every logged-in user sees the same thing is simpler than one where admins, staff, and customers each see different views with different capabilities. Every additional role adds real development time.
Integrations with existing systems. If the app needs to talk to your CRM, accounting software, inventory system, or a third-party API, that integration work is often a bigger cost driver than the interface itself. I always ask about existing tools early, because “just connect it to our system” can be a five-hour job or a fifty-hour job depending on what that system offers.
Custom logic versus standard patterns. Login, forms, and basic data display are well-understood, efficient to build. Custom business logic — a quoting engine with your specific pricing rules, a scheduling system with your specific constraints — takes real time to design and test properly.
Data complexity. An app that just displays information is simpler than one that lets multiple users edit shared data simultaneously, or that needs to maintain a history of changes, or that has to reconcile data from multiple sources.
Realistic ranges
For a straightforward client portal — login, view order or project status, download documents — I generally see projects land in the low five figures. Add custom workflows, multiple user roles, and a couple of integrations, and you’re moving into the mid five figures. Complex, multi-feature systems with significant custom logic can run higher, and that’s appropriate — that’s genuinely more work, not padding.
The honest advice I give every client: start with the smallest version that solves the actual problem. A portal that does one thing well and ships in weeks beats a sprawling spec that takes six months and tries to solve every future need up front. You can always add features once the core is live and you know how people use it.
How I scope these projects
Before I quote anything, I want a real conversation about what the app needs to do on day one, not a wish list of everything it might eventually do. That distinction matters — scoping the actual first version tightly is what keeps apps and portals projects on budget and on schedule. I also ask directly about existing systems it needs to connect to, since that’s so often where cost surprises come from later if it’s not addressed upfront.
If the project turns out to be smaller than an app — say, a contact form with some conditional logic, or a booking calendar — that’s sometimes better handled as part of a website build instead of a standalone app, and I’ll tell you that if it’s true, rather than upselling a bigger project than you need. If you’re still working out whether your project is a website problem or a portal problem, that’s worth settling before pricing anything.
FAQ
Is it cheaper to use an off-the-shelf tool instead of building custom? Often yes, for standard needs. Custom development makes sense when your workflow genuinely doesn’t fit existing tools, or when you need tight integration with systems those tools don’t support.
How long does a custom portal typically take to build? A focused first version usually takes several weeks to a couple of months, depending on integrations. Larger systems with multiple roles and workflows take longer.
Should I build the full feature set at once, or launch a smaller version first? Launch smaller. It’s faster to get real user feedback, cheaper to adjust course, and you avoid paying for features that turn out not to matter once people are using it.
Do I need to know exactly what I want before getting a quote? No — a good scoping conversation should help clarify that. But the more specific you can be about what the app needs to do on day one, the more accurate the estimate will be.
Send me a rough description of what you’re trying to build and I’ll give you a real range, not a placeholder number, before you commit to anything.