Scope and interface design
User roles, workflows and a data model written down with acceptance criteria. Then flows and screen designs, reviewed as a clickable prototype before engineering begins.
Web apps · Portals · DashboardsWeb application development
Web application development
for products that live in the browser.
We design and build custom web applications: customer portals, dashboards, booking and ordering systems, and browser-based products with accounts, roles and data behind them. One team covers interface design, front end, backend, database and deployment to infrastructure you control.
What a web app project coversFrom first sketch,
From first sketch,
to a system in production.
A web application is software that runs in the browser with accounts, data and logic behind it. There is nothing for users to install, one version for everyone, and updates ship the moment they are ready. We build the whole thing, not only the screens.
Front end
A responsive interface in React and Next.js with TypeScript: forms, tables, search, filters, charts and file handling that behave properly on a laptop and on a phone.
Backend and data
API, PostgreSQL database, authentication, role-based permissions, background jobs, email and third-party integrations. Business rules live on the server, where they can be tested and trusted.
Deployment and handover
Staging and production environments in your own cloud or VPS account, backups, basic monitoring, and a repository handover with setup and deployment documentation.
Who this is for
Companies that need software their users open in a browser.
Most web application projects we would take on look like one of these:
- A customer or partner portal. Clients log in to see orders, documents, invoices, bookings or project status instead of emailing your team for them.
- A dashboard. Data from several sources pulled into one place, with the filters, charts and exports people need to make decisions.
- A booking, ordering or quoting system. A transactional workflow with availability, pricing rules, payments and notifications.
- A new browser-based product. A tool you intend to offer to customers, tested on the web first because it is the cheapest platform to build and change.
How this differs from our neighbouring services
The boundaries matter because they change the scope:
- If the product is sold by subscription to many customer organisations, with plans, billing and tenant isolation, it is a SaaS product. See SaaS development.
- If the software is for your own staff and replaces spreadsheets and manual steps, see internal tools.
- If the main challenge is fitting software around existing systems, legacy code and business processes, see custom software development.
- If users need push notifications, device hardware or offline use, a mobile app may be the right front end for the same backend.
The processFour stages.
Four stages.
Working software early.
Ranges are planning figures for a first version with one to three user roles. Larger systems are split into releases of a similar size.
How we work in detail ↗Discovery · 1–2 weeks
Roles, workflows, data, integrations and constraints. Output: scope document with acceptance criteria, data model outline, technical approach, fixed quote and timeline.
Design · 1–3 weeks
Flows and interface designs for the main journeys. Data-heavy screens such as tables and reports are designed with realistic data, because that is where layouts break.
Build · 5–12 weeks
Short iterations on a staging URL you can open at any time, with written updates and a demo at each milestone. Payments follow the milestones.
Launch · 1–2 weeks
Cross-browser and device testing, data import if needed, production setup, backups, monitoring, and handover of code, accounts and documentation.
Technology approach
One language across the stack. Infrastructure you hold the keys to.
We prefer widely used, well-documented technology. It keeps hosting inexpensive and means the engineers you hire later will already know it.
| Layer | Typical choice | Why |
|---|---|---|
| Front end | React and Next.js, TypeScript, Tailwind | Fast interfaces, server rendering where search visibility matters, a very large hiring pool |
| Backend | Node.js with TypeScript | Shared types and validation between browser and server reduce a whole class of bugs |
| Database | PostgreSQL | Relational integrity for business data, strong reporting queries, cheap to run |
| Auth and file storage | Managed services such as Supabase or Firebase, or a custom implementation | Managed saves weeks; custom when single sign-on or unusual permission rules require it |
| Payments | Stripe or a regional provider | Card data never touches your servers |
| Deployment | Docker on your cloud or VPS account | Reproducible environments, no dependence on us to keep it running |
A well-structured single application on one database is the right architecture for most web apps for a long time. We add queues, caches and separate services when measurements call for them, not before. The reasoning is set out in our guide to SaaS architecture and stack choices, most of which applies to any web application.
Pricing factors
What moves the cost of a web app.
- User roles and permissions. Each role has its own screens and rules. “Managers see their region, except finance, who see everything” is real engineering work.
- Number of distinct workflows. A portal that shows data is small. One that lets users create, approve, amend and cancel things is several times larger.
- Integrations. Accounting, CRM, payment, shipping or identity systems. Effort depends mostly on the quality of the other side’s API and documentation. See API integration.
- Reporting and exports. Dashboards, PDF documents and spreadsheet exports are frequently underestimated.
- Existing data. Importing and cleaning years of spreadsheets or an old database is a task of its own.
- Security and compliance requirements. Single sign-on, audit logs, data residency and penetration testing add scope.
- Design ambition. A clean interface built on a component library is far cheaper than a bespoke design system.
We quote a fixed price against a written scope and split payments across milestones. Changes are priced before they are made. To sanity-check a quote yourself, the effort-times-rate method in our cost guide for SaaS and web products works for most web applications.
Common mistakes
Where web app projects go wrong.
Designing screens before the data model
Attractive mockups can hide the fact that nobody has decided whether an order can have two delivery addresses. Those decisions surface eventually; in discovery they cost an hour, in month three they cost a migration.
Forgetting the admin side
Someone has to create accounts, fix a wrong record, issue a refund and answer “what happened to my order”. If the admin area is not in the scope, your developers become the support desk.
Treating permissions as a detail
Access rules added at the end tend to be enforced only in the interface, which is not enforcement at all. Roles belong in the first version of the data model and on the server.
Importing data the week before launch
Old data is always messier than expected. Run a trial import early so the surprises arrive while there is still time to handle them.
Hosting in the vendor’s account
If the application runs in your developer’s cloud account, you do not fully control your own product. Register the hosting, domain and third-party services in your company’s name from the first day.
FitWhen BBR is the right team,
Good fit Not a fit
When BBR is the right team,
and when it is not.
We are a small independent studio. That shape suits well-defined products and is wrong for some others, so here is the honest version.
We are likely a strong match if
- You want one team responsible for design, front end, backend and deployment
- You can describe the users and what they need to get done, even if the details are open
- You prefer a fixed scope and price with milestone payments
- You want the code, hosting and third-party accounts in your name
- You are comfortable working remotely in English with written updates and scheduled calls
We will probably point you elsewhere if
- You need a marketing website or online shop that a site builder or hosted e-commerce platform already covers
- You need a large team on-site or a vendor with a specific compliance certification
- Your organisation mandates a stack outside ours, such as .NET or Java, for everything it runs
- You want open-ended staff augmentation managed entirely by your own leads
- You are looking for equity-only or deferred-payment development
Why outsource a web app
The project has an end. A hiring plan does not.
A web application needs a designer, front-end and backend engineering, and someone who can set up and secure a production environment. For a business whose main activity is not software, recruiting and managing that group for a build that lasts a few months rarely makes sense. After launch the workload drops to maintenance and periodic improvements, which a full-time team would be underused for.
Working with a studio gives you the complete team for the build and a smaller arrangement afterwards. Because we hand over the repository, documentation and infrastructure access, you can also move the work in-house later. We compare the routes in in-house vs outsourced development, and questions to ask a software development agency gives you a list to test any vendor against, including us.
If you need continuing capacity and not a single project, our product engineering service describes how that works.
QuestionsFrequently asked
Frequently asked
questions.
What is the difference between a website and a web application?
A website mostly presents information. A web application lets users sign in and do something: place orders, manage records, upload files, view their own data. That means accounts, permissions, a database, business logic and an admin area, and it is why a web app is an engineering project and not a template job.
How long does it take to build a web application?
As a planning range, a focused first version with one or two user roles usually takes two to four months including design and testing. Portals with many roles, several integrations or complex reporting take longer. We set dates in the scope document after discovery and do not quote them before.
How much does a custom web app cost?
Cost follows effort: the number of user roles, workflows, integrations and reports. We quote a fixed price against a written scope. The method in our SaaS development cost guide applies to most web applications if you want to estimate a range yourself first.
Which technologies do you use for web apps?
By default TypeScript across the stack: React and Next.js on the front end, Node.js on the backend and PostgreSQL for data, deployed with Docker to a cloud or VPS account that you own. If you already run a different stack we will discuss whether to follow it.
Can you take over or extend an existing web app?
Yes. We start with a paid review of the code, infrastructure and open issues, then tell you what can be kept, what is risky and what it would take to continue. Sometimes the right answer is a targeted fix, sometimes a staged rebuild of one part at a time.
Will the web app work on phones?
Yes. Responsive layouts that work on phones and tablets are part of the standard scope. If users later need push notifications, offline use or store distribution, the same backend can serve a mobile app.
Who owns the code and hosting?
You do. Ownership of the code transfers to you under the project contract, the repository is handed over with documentation, and the application runs in hosting accounts registered to your company.
Your next moveHave a web app to build?
Have a web app to build?
Send us the outline.
Describe the users, what they need to do and any systems it has to connect to. We reply with questions, a suggested scope and a realistic range.
Discuss your web app ↗