Web applications with logins, roles and real data — dashboards, portals and internal tools in Next.js, Vue and Angular.
A web application is what you build when a website is no longer enough — when people need to log in, see different things depending on who they are, and change data that other people depend on.
That is a different discipline from a marketing site. It is state, permissions, edge cases and the screens nobody demos: the empty state, the error, the row somebody deleted while you were looking at it.
Not a list of technologies — the things that exist at the end and the state they are handed over in.
Dashboards, tables that stay fast at ten thousand rows, forms that validate before they frustrate, and search that finds things.
Including the screens nobody demos: the empty state, the error, the deleted row.
What each role can see and do, enforced on the server as well as hidden in the UI.
Hiding a button is not a permission model.
Live updates, notifications and presence, used where it changes the work rather than as decoration.
Usable on the phone your staff actually carry, keyboard navigable, with contrast that survives a bright office.
On any public-facing part: server rendering, correct metadata, structured data, and Core Web Vitals treated as a requirement.
Four stages, each ending in something you can open rather than a status report.
The screens, the roles, and the one workflow that has to be excellent.
Agreeing what happens on each screen is faster to change in a sketch than in code.
One working screen at a time, on a staging URL you can open whenever you like.
Source, deployment, environment variables and a walkthrough.
Server rendering where it helps the user or the search engine, backed by whichever API fits — often the one we built alongside it.
The systems on the work page are the front ends as much as the back ends.
Admissions, timetables, attendance, exams and fees behind one login, with separate portals for parents and students. The same record renders as a Grade at a school, a Year at a university and a Level at an institute — the interface takes on the customer's vocabulary rather than making staff learn ours.
Runs hiring through to payslip.
Project management priced and shaped for teams here.
All are built and deployed to a pre-production environment — not yet running in production for a paying customer.
See the work →Scope decides the number, so there is no price on this page. Here is what replaces one.
Who logs in, what they need to get done, and the one workflow that has to be excellent. Written down before anything is built.
Scope decides the cost, so there is no number on this page. You get a fixed written quote after scoping — not an hourly meter.
A focused internal tool is often six to ten weeks. A full platform with several roles is longer, and the scoping call gives you a real range rather than an optimistic one.
Interface design is part of the build, not a separate purchase. Taking over an existing app is common too — that starts with a short audit so the estimate reflects the actual code.
If what you need is a page that presents a product and collects enquiries, that is a different — and much quicker — job.
Scope decides it, so there is no number on this page. You get a fixed written quote after a scoping conversation.
A focused internal tool is often six to ten weeks. A full platform with several roles is longer, and the scoping call gives you a real range rather than an optimistic one.
Yes — that is common. It starts with a short audit so the estimate reflects the actual code.
Yes. Interface design is part of the build, not a separate purchase.