On this page
Web Applications
Custom Web Applications: Dashboards, Portals, and Internal Tools
Portals, admin dashboards, and business applications with solid backends and APIs—built for teams and customers who use them every day.
✓ $10K–$35K typical · ✓ 4–8 weeks · ✓ Integrations included in scope
Who This Is For
✓ Good fit for:
- • Customer portals and partner dashboards
- • Internal ops tools (CRM, booking, inventory)
- • Admin panels for existing products
- • Integrations with ERP, CRM, or legacy systems
Examples: booking systems, inspection portals, analytics dashboards.
Consider SaaS or mobile if:
- • You need multi-tenant billing → SaaS engineering
- • Users are mobile-first → Mobile apps
- • You only need marketing pages → static site (we can advise on scope)
Investment
Timeline & Pricing
Typical timeline
4–8 weeksScoping to production handover
Typical investment
$10K – $35KFixed price after written scope
Stack
Chosen in scopingSSR, SPA, or headless + API
What changes
Software your team and customers rely on.
An application people open every day, with a backend and an API behind the screens.
01
Portals, dashboards and business applications
02
A backend and APIs the interface can trust
03
Tested, reviewed and handed over
Is this you?
When this is the right service
Software with signed-in users, data and a workflow, including an app you already have.
- You need a portal, a dashboard or a business application.
- The backend and the APIs matter as much as the screens.
- People will use this on a normal working day.
- You may need us to take over an existing web app.
Good fit
- Signed-in users and data in the product.
- Integrations you can name in discovery.
- An interface we should design as part of the work.
Not a fit
- A campaign page with no application behind it.
- A native mobile app with no web application. That is the mobile service.
- A stack chosen before we know the architecture.
Services
What we build
The stack follows the architecture. Both are written into the scope.
Portals
Signed-in places for customers, partners or staff.
Dashboards
The working view of the data the scope says people need.
Business applications
The workflow your team or your customers repeat.
Backends and APIs
The server side the interface calls. The shape is chosen in discovery.
Integrations
Connections to systems you already run, when they are in the scope.
Takeover of an existing web app
Discovery on the app you have, then a scoped continuation or a handover.
Choosing an approach
The right architecture for your app
Choose the shape first. The tech stack is chosen during scoping, after this decision.
Three shapes cover the apps we are usually asked for. We pick one in discovery, then name the stack in the written scope. We do not start from a framework.
Server-rendered site
Fits portals and pages that should arrive with their data, and pages people open one at a time.
Single-page app
Fits a tool people keep open, where most of the work happens on one screen after sign-in.
Headless backend with separate frontends
Fits when the same data must serve a web app and another client, such as a mobile app.
How it works
From discovery to a live application
Design is part of the process, not an optional extra.
- 01
Discovery
We map users, data, integrations and whether we are taking over an existing app.
You get: a written scope and a fixed price for phase one, including the architecture choice.
- 02
UX and interface design
We design the screens for the people who will use them.
You get: those screens before the build sprints.
- 03
Build in sprints
We build the scoped application, backend and API included.
You get: releases you can try.
- 04
Test and launch
We test, review and launch the scoped release.
You get: the application in production for the users in the scope.
- 05
Support
We hand it over, or keep supporting it if that is in a later agreement.
You get: documentation and accounts in your name.
Built for production
How we make it dependable
Performance and security are part of the release, not a later project we hope to sell.
Testing
Tests around the workflows and APIs the scope says must keep working.
Code review
A senior engineer reviews every change, including AI-generated code.
Security checks
Sign-in, access and the integrations named in discovery.
Monitoring
A way to see errors and slow paths after launch. The tool is chosen during scoping.
Documentation
The architecture, the API and how to run a release.
Handover
Code, repositories and accounts stay in your name.
Technology
Tools we use, chosen per project
The framework is chosen after the architecture. It is named in the scope, not on this page.
Proof
Work in this area
Client names stay private. Studies are published on Work when they are written.
Ways to work together
How to work with us
A defined web application starts as a fixed-price phase.
Recommended
Fixed-price project
Best for a portal, dashboard or business application with a written scope.
How it works Discovery ends in a written scope and a fixed price for phase one. No price is listed on this page.
FAQ
Common questions
The stack, the integrations and the takeover plan are written in the scope.
Chosen per project, after we pick the architecture: a server-rendered site, a single-page app, or a headless backend with separate frontends. The stack is named in the written scope.
Yes, when discovery includes them. Integrations are part of the scope we quote.
Every release goes through testing, code review and security checks. We add monitoring, documentation and a handover. The detail is in the scope.
Yes. The process includes UX and interface design before the build sprints.
Yes. Discovery covers the app you have. We can keep building it, or hand it back with documentation after a scoped piece of work.