01
Customer portals
A place your customers log in to see their own data: orders, documents, invoices, requests and status. Usually replaces a mailbox that one person is manually working through.
Web application development
Web applications built to be used,not just launched.
Customer portals, dashboards, booking systems and internal tools, scoped honestly and demoed working on a live link every week.
The problem
Why do so many web application projects disappoint?
Because the scope was written by people who will never use the software, and nobody sees it working until it is finished.
How it usually goes
- Scope written from a feature list nobody pressure tested
- Four months of silence, then one big reveal
- Every change priced separately, so nobody raises them
- Code and servers held in the agency name
- Handed over with no documentation anyone can follow
- The team moves on the week after launch
How we do it
- Scope written with the people who will use it daily
- Working software on a live link every week
- Small changes absorbed, real ones quoted in writing
- Repository and cloud accounts in your name from day one
- Documentation another team could pick up tomorrow
- We stay reachable long after the launch date
How it works
How the application fits together
Every layer has one job and one owner, drawn out before any code exists. Adding a mobile app or a partner later becomes an addition rather than a rewrite.
- 01
Visitors
- Browser and mobile web
- Search engines too
- 02
Application
- Next.js, server rendered
- Fast on slow networks
- 03
API layer
- Rules and validation
- Documented, versioned
- 04
Database
- One source of truth
- Backed up and restorable
- 05
Integrations
- Payments and email
- Your existing tools
Web application development
What we build most often
02
Operations dashboards
One screen that shows the business what is actually happening, pulled from the systems that already hold it, so decisions stop waiting on somebody assembling a spreadsheet.
03
Internal tools and admin panels
The unglamorous software your team uses all day. Built around the real workflow rather than around the database tables, which is why most internal tools get abandoned.
04
Booking and scheduling systems
Availability, reservations, reminders and payments, wired into your calendar and your accounts rather than sitting in a silo somebody has to reconcile.
05
Marketing sites that convert
Fast, searchable and easy to edit without calling a developer. Built to be found, which most agency built sites quietly are not.
06
Replacing a spreadsheet that outgrew itself
The most common brief we get. A spreadsheet ran the business well until three people needed it at once and nobody could tell who changed what.
You should see the software working in week two, not month four.
As standard
In every build, not quoted separately
- 01Responsive on phones, tablets and desktop
- 02Search visibility built in from the first commit
- 03Core Web Vitals budgets, tested on mid range Android
- 04Accessible contrast, focus states and keyboard paths
- 05HTTPS, secrets outside the repository, least privilege access
- 06Repository, cloud accounts and documentation in your name
The timeline
What a typical project looks like
Dates are agreed before anything is built. If one ever comes under threat you hear it in that week demo, not at the end.
- Week 1
Requirement gathering
We sit with the people who will use it and write down what they actually need.
- Week 2
Scope and price signed
A written scope by module, with a fixed price and a date you approve first.
- Weeks 3 to 4
Design and architecture
Screens and data model agreed before code, so growth later is not a rewrite.
- Weeks 5 to 10
Build, demoed weekly
Work lands on a live link every week, so you redirect while it is still cheap.
- Week 11
Test and hand over
Checked on real devices, then deployed with everything transferred to your name.
- Week 1
Requirement gathering
We sit with the people who will use it and write down what they actually need.
- Week 2
Scope and price signed
A written scope by module, with a fixed price and a date you approve first.
- Weeks 3 to 4
Design and architecture
Screens and data model agreed before code, so growth later is not a rewrite.
- Weeks 5 to 10
Build, demoed weekly
Work lands on a live link every week, so you redirect while it is still cheap.
- Week 11
Test and hand over
Checked on real devices, then deployed with everything transferred to your name.
Questions
Questions about web application projects
It depends entirely on scope, which is why we do not publish a number. A focused internal tool is a different project from a multi tenant platform with billing, and any published price would be either wrong for you or padded to stay safe for us. What we can promise is that you see a fixed price against a written scope before you commit to anything or pay anything, and if it does not fit your budget we will tell you what can be phased or cut to reach it.
A focused web application usually runs six to twelve weeks from signed scope to launch. Requirement gathering and scoping take the first week or two, design and architecture another one to two, and the rest is build, test and handover. You get a specific date in writing before anything is built.
Yes, and we are asked this often. We start with a short audit of the existing code, database and infrastructure, then give you an honest verdict on whether it is worth continuing, partly rebuilding or starting again. Continuing is frequently the right answer and we will say so, even though a rebuild would be worth more to us.
That is decided by the architecture, before any code is written, which is why we treat design as its own phase. Data models, queues and APIs are laid out for the load you expect in three years, so growth becomes a configuration change rather than a rewrite.
Tell us what the software has to do.
Describe the business problem in your own words. We will come back with what it means in software, in writing, with a fixed price and a date against it.