Web Application Development Services
We build web applications that several kinds of people log into and use to do their job.
That is a specific category. Not a website with a form on it, and not a consumer app with one type of user. Platforms where an administrator, a manager and a customer each see a different version of the same data, where permissions are a real design problem, and where the thing has to keep working when the business changes shape.
Most of ours start the same way: a spreadsheet, a shared inbox, or a process held together by one person who knows how it works. The hard part is almost never the screens. It is modelling what the organisation actually does, including the exceptions everyone forgot to mention.
What We Build
Not every project needs all of this. These are the parts we go deep on when a product calls for them.
-
SaaS platforms
Multi-tenant products with sign-up, subscription state, per-account configuration and isolation between customers that holds. The tenancy model is a decision made once and regretted for years, so we make it deliberately.
-
Internal tools and operational systems
The systems a business runs on. Lower glamour, higher stakes: if it is down, people cannot work. Built for the actual process, including the parts of the process nobody documented.
-
Roles and permissions
Who can see what, who can change what, and who can approve it. Modelled properly rather than accumulated as a series of conditionals, because that is the part that becomes unmaintainable first.
-
Workflow and process
Approvals, states, handoffs, audit trails. Systems where a record moves through stages and somebody has to be able to prove what happened and when.
-
Reporting and data views
The screens that answer questions rather than capture input. Where that is the heart of the product, see [LINK: dashboard and data visualisation design | /services/design/dashboard-data-visualization/].
-
Integrations
Payment, CRM, ERP, email, document generation, and the in-house system with no documentation. See backend and API development.
-
Migration from what exists
Getting years of data out of a spreadsheet, an old system or both, cleaned and into the new model. Routinely underestimated, and we scope it as its own piece of work.
-
Performance and quality
Numeric targets set during scoping and tested against, plus WCAG 2.1 AA as a line in the estimate rather than an aspiration.
When Teams
Come to Us
-
The spreadsheet has become load-bearing
It works, one person maintains it, and the business would stop without it. That is a risk with a replacement cost, and it is the most common project we take.
-
An internal tool outgrew its origins
Built quickly for one team, now used by four, and nobody planned for that.
-
Several parties log into the same system
Customers, staff, contractors, auditors. Different views, different permissions, one source of truth.
-
A product that has to scale past its first version
It worked for the first hundred users and the structure will not hold. Sometimes a rewrite, more often a set of specific changes we can identify before quoting.
-
An existing application nobody can safely change
An inherited system with no documentation and no original developer. We audit before committing. See project takeover and modernisation.
Do You Have a Project Idea?
Tell us what you want to build. We come back with a rough estimate and an honest view of what it takes, before anyone signs anything.
How We Work
What the system has to do, who uses it, and what the real process is rather than the documented one. The output is a scope you can price and argue with.
Data model, permissions model and integration points agreed before anything is built. The stage clients most often want to skip and the one that saves the most money.
Sprints, with something usable at the end of each one.
Automated and manual, across the browsers and roles that matter.
Deployment pipeline, monitoring and data migration, rehearsed rather than attempted once.
Every project includes one month of bug fixing after launch at no extra cost.
Stack
- Frontend: React, Next.js, TypeScript
- Backend: PHP with Laravel, Node.js with NestJS, Python with Django
- Databases: relational by default, with the schema designed rather than inherited from a tutorial
- Auth: OAuth 2.0, JWT, role-based access control, Supabase, Firebase Auth
- Async: queues, workers, scheduled and event-driven jobs
- Testing: Playwright for end to end, plus unit and integration coverage
- Delivery: CI pipelines, staged deployment, error and performance monitoring
Which backend we reach for depends on what you already run and who will maintain it. If your team writes PHP, we will not hand you a Node service because we felt like it.
Performance and Quality
We set numeric targets during scoping and test against them, rather than describing the system as fast and hoping.
That usually means page and response time budgets on the screens that matter, a load profile the system has to hold, and a ceiling on database time per request. Yours will be different. The point is that they exist, they are written into the estimate, and QA checks them before release.
Accessibility works the same way. WCAG 2.1 AA is a line in our estimates, not an aspiration.
Selected Work
- Planit. Construction planning and scheduling platform with 4D scheduling and structured data extracted from building models.
- Compliance Auditing Tool. Multi-role auditing platform with a configurable rule set and structured reporting.
- Pet Boarding Management SaaS. Multi-tenant operational platform handling bookings, capacity and customer records for boarding businesses.
Industries We Build For
Construction and PropTech is where our web platform work goes deepest. We also build for healthcare, booking and scheduling systems, and travel and mobility.
How We
Work Together
-
Fixed scope
A defined build, priced per module, with a timeline. Suits a clear brief. -
Ongoing team
Developers, QA and design working to your roadmap. Suits platforms that will keep changing. -
Discovery first
Where the scope is not yet knowable, a short discovery engagement produces one. See [LINK: product design | /services/design/product-design/]. -
Support retainer
After the first month of free bug fixing runs out. SeeA typical build runs with two developers, a QA engineer and a designer. Larger platforms scale from there.We price every project individually. There are no packages, because the work does not arrive in packages.
Questions We
Get Asked
-
We give you a rough estimate as soon as we understand what the system has to do. The detailed number comes after we have agreed the scope with you, once the goals and the functionality are settled. At that point we break the estimate into modules and price each one, so you can see what a permissions model or a reporting layer actually costs and decide what belongs in version one.
-
Yes, and the migration is its own piece of work rather than a final step. Years of a spreadsheet usually contain inconsistencies, duplicates and special cases that have to be decided on rather than imported blindly.
-
Yes. Code, infrastructure definitions, documentation and accounts are yours, and we build so that another team could pick it up without an archaeology phase.
-
Yes, and a good share of our work is shaped that way — our people in your process, your repository and your standards.
-
Yes, and most projects go better that way. See UI/UX design. If you already have a designer, we will work with them, and we will flag anything in their design that will be expensive to build while there is still time to change it.
-
Every project includes one month of bug fixing at no extra cost. After that, ongoing work runs as a support retainer with agreed response times. See application support.