Web apps and internal tools.
The logged-in side of a business. Client portals, booking systems, dashboards and field tools that work on a phone with one hand.
Four reasons internal tools stay broken.
Public websites get fixed because customers complain. Internal tools do not, because the people using them have no choice.
Captive users generate no pressure to improve.
Across 42 organisations' intranets, employee task success was 74%, statistically unchanged from 75% ten years earlier, while public websites improved over the same period. Nothing forced the internal ones to get better.
The workaround becomes the process.
Someone builds a spreadsheet to get around the system, then a second spreadsheet to reconcile the first, and within two years that is how the department runs.
It only works at a desk.
Half the people who need it are on site, in a workshop or in a vehicle, and the tool assumes a keyboard, two hands and a full-size screen.
Legacy eats the budget.
Legacy systems typically consume 70 to 75% of total IT budget and around 80% of total cost of ownership. Most of that is spent keeping something alive rather than making anything better.
What we build.
Tools people open because they help, not because they are made to.
Client and customer portals
Where a customer checks their own order, document or job without emailing anyone.
Booking and scheduling
Availability, confirmations and reminders, without a phone call in the middle.
Dashboards your team will open
The five numbers that matter, not forty. Built around a decision someone actually makes.
Field tools that work one-handed
Phone first. Big targets, few taps, and the camera where a photo is needed.
Roles and permissions that make sense
People see what they need. Nobody works around the system to get their job done.
Built to hand over
Your accounts, your data, your code. Documented so another developer can pick it up.
We design around the decision, not the database.
Most internal tools are laid out the way the data is stored. Every field the system holds gets a box on a form, in the order the table lists them, and the person using it has to know which twelve of the forty matter for what they are doing.
We start from the other end. What is the person deciding, where are they when they decide it, and what is the least they need on screen to decide it well. Everything else moves behind a second click or off the screen entirely.
Our process.
- 01
Work out what it has to do
One written scope, agreed before anything is designed or built. Most of the risk on a project lives here.
- 02
Design and build it
You see it working in stages, not at the end. Unlimited revision rounds inside each phase.
- 03
Hand it over
Every file, login and account is yours. We show your team how to run it before we finish.
- 04
Keep it running
Updates, backups and monitoring, so it does not quietly stop working.
What else we do.
Same team, same accountability. Most clients start with one of these and add another later.
Websites
Sites that win work and help you hire.
Brand identity
Marks, colour and type that hold up everywhere.
AI tools
Narrow tools for one repetitive job, done well.
Custom software
Replaces the spreadsheet holding the business together.
SEO
Getting found by people and by AI answers.
Hosting and support
Someone whose job it is to keep it running.Common questions.
A website is read by people who are not signed in. A web app is used by people who are, and it holds their data. Different problem, different build, and the logged-in part is where the value usually sits.
It depends on how many kinds of user it has and what each is allowed to do. A booking tool for one team is a different job from a portal your clients log into. We scope the roles and the workflows before putting a number on it.
We put a working piece in front of real users early rather than building for months in private. Captive users generate no pressure to improve, so the sooner the people who have to use it every day can react, the better the result.
That is often the whole point. Field tools are built to work on a phone with one hand, because the person using them is holding something else. A tool that only works at a desk gets filled in later from memory, which is how data goes wrong.
Yes, and that is one of the commonest reasons to build one. A client portal removes the emails asking where something is. What each client can see is controlled by roles and permissions we agree with you before the build.
It runs on hosting registered to you, so the accounts are yours. Running costs depend on how many people use it and how much it stores, and we will show you the figure before you commit rather than after.
Often, and we will tell you honestly if it is not worth it. Legacy eats the budget, and sometimes the maintainable answer is to rebuild the part that matters rather than keep paying to patch the whole thing.
We map who needs to see and do what before the build, because retrofitting permissions is expensive and error prone. Roles that make sense to the people using them are part of the design, not a setting switched on at the end.
It can, where the work genuinely happens somewhere without signal. Offline capability adds real complexity, so we build it when a site, a vessel or a warehouse actually needs it, and not because it sounds useful.
Yes, and most useful tools grow. What we avoid is building everything anyone might want before anyone has used it. Ship the piece that removes the worst problem, watch what people actually do, then decide what is next.
Already have a website?
Not every firm needs a new one. Sometimes the structure is sound and it just needs better content, a proper update and a tidy-up. We will tell you which one you are, and we will say so if a refresh is the honest answer.
Talk to us about a refreshTell us what the website has to do.
No pitch and no deck. One call to work out whether the problem is the one you think it is.
- Reply within one working day
- No obligation, and no sales sequence
- Over 100 projects since 2023