When the site is really an application
Dashboards, customer portals, booking and quoting systems, configurators. Projects where people log in and do work rather than read pages — and where forcing a CMS to cope costs more than building it properly.
What we build
Customer portals
Accounts, documents, order history, support requests — the self-service layer that stops your team answering the same email.
Dashboards
Numbers pulled from several systems into one screen, refreshed on a schedule you control rather than on page load.
Booking and scheduling
Availability, capacity rules, confirmations and reminders — where the rules are specific enough that no off-the-shelf tool fits.
Quoting and configurators
Multi-step pricing with real logic behind it, producing a document at the end rather than an enquiry form.
Internal tools
The spreadsheet your team has outgrown, turned into something several people can use at once without overwriting each other.
Headless front ends
A React interface over an existing CMS or API, when the content stays where it is but the experience needs to be faster.
Is it a website or an application?
It matters, because the answer changes the platform, the cost and who can maintain it. Rough test:
- Do people log in to do work? Application.
- Does it hold state between visits? Application.
- Are there rules the content team can’t express in a page? Application.
- Would losing it stop work rather than stop marketing? Application.
If none of those are true, you want a website, and it’ll cost less. We’d rather tell you that up front than build the expensive version.
What you get
- Full source code, yours to keep
- A data model documented before anything is built on it
- Role-based access designed in, not retrofitted
- A test suite where the logic justifies one
- Security review before launch
- Deployment instructions, and deployment if you want it
- A defined support window after launch
Applications need maintaining more than brochure sites do — dependencies age and security advisories arrive. That can run under a care plan.
Common questions
React or .NET?
Usually React for the interface, with the back end chosen to match what it integrates with — .NET inside a Microsoft estate, otherwise whatever your team can maintain. The decision is about your environment, not our preference.
Can it live alongside our existing site?
Yes, and that’s common — the marketing site stays where it is, the application runs on a subdomain or a path, sharing sign-in if it needs to.
Can we start small?
We’d encourage it. Build the part that solves the most painful problem, put it in front of real users, then extend. Specifying everything up front is how projects get abandoned half-built.
What about hosting?
We’ll advise and set it up, but it stays in your name on your account. We don’t resell hosting or hold your infrastructure.
Describe what people will do in it
Who logs in, what they’re trying to get done, and what it has to connect to. We’ll tell you whether it’s an application or a website.