Custom software for real business needs.
We design and build web applications around the way your business already works: the internal tools, dashboards and client portals your team opens in a browser. Nothing to install, one version for everyone, and support after launch from the people who built it.
- Built around your business
- Clear stages, seen early
- Supported after launch
A web application tailored to your business.
Off-the-shelf software is built for the average business, and for accounts or email that is usually right. Where your work is not average, an application is built for it — and an application is not a website. A website is read once; an application is used, by the same people, all day, which changes who may sign in, what happens when two people edit the same record, and what the business does on the morning it will not load.
- Built around your process, not an industry average
- Opens in a browser on any modern device — nothing to install
- People see only what their role allows
- Changes as the business changes, not at a redesign every few years
- Monitored and supported after launch, as part of the arrangement
- Client portalsYour customers sign in to their own information
- Internal toolsThe screens your team works in all day
- Custom systemsJobs, records and stock, run your way
- IntegrationsConnected to systems you already use
- AutomationThe repetitive steps, done for you
- DashboardsLive figures, not exports
Manual processes hold your business back.
Usually not a competitor's product. Usually a spreadsheet, a shared drive and a great deal of copying between the two.
- Time lost to copying, re-typing and chasing
- Information scattered across spreadsheets, inboxes and drives
- Errors from four versions of the same spreadsheet
- Reporting that means exporting, pasting and hoping
- A system nobody can reach from a customer's site or from home
- Off-the-shelf software that almost fits, and a workaround for the rest
A custom web application helps you:
- Take the repetitive steps out of the work
- Keep information in one place, current for everyone
- Cut the errors that come from re-typing and copies
- See the live picture without an export step
- Change the software as the business changes
- Have the screens your job actually needs, and no others
A spreadsheet that has outgrown itself is a good sign: somebody has already worked out what the software needs to do.
What businesses use them for
Job and project tracking
Work from enquiry to completion, with the stage, the owner and the history visible to everyone involved.
Management dashboards
The handful of figures the business is run on, current when you open them.
Approvals and requests
Quotes, purchases, time off, discounts — with a record of who approved what.
Staff and resource planning
Who is where, what is booked and what is free, visible from outside the office.
Stock, assets and equipment
What you own, where it is, its condition and when it is next due attention.
SaaS products
Software you sell: accounts, plans, permissions and the operational side of running it.
If the application is for your customers rather than your team, that is a client portal — same technology, different set of questions.
What a project includes, and what it does not.
Part of the project
- Discovery: what the application must do, and for whom
- Design of the screens people will work in
- Secure sign-in, roles and permissions
- The application itself, built and tested
- Database design, backups and a tested restore
- Deployment to hosting we agree on, with monitoring
- A period of real use before it replaces anything
- Handover: source code, documentation and a support arrangement
Separate, and quoted separately
- Native iOS or Android apps published to the app stores
- Hosting and third-party service charges, which are yours directly
- Migrating data out of an old system, before we have seen it
- Integrations with other systems — scoped as their own piece of work
- Changes beyond the agreed scope
- Any guarantee of uptime or performance before the hosting is agreed
A web application runs in a phone's browser and can be added to the home screen, which is enough for most business use. If you genuinely need a store-published native app, say so early — it is a different project.
The parts nobody sees until they fail
What decides whether an application is still trusted in year three.
Authentication
Hashed passwords, proper sessions, multi-factor sign-in where the data justifies it.
Roles and permissions
Checked on the server for every action — a hidden button is not a permission.
Input and output
Parameterised queries, validated input, escaped output, CSRF protection.
Backups and restores
Automatic backups, and a restore performed before launch.
Monitoring
We hear it is down from monitoring, not from your team ringing.
Kept current
Platform and dependency updates under the support arrangement.
From idea to a solution that works.
In stages, so you see working software early rather than everything at the end.
1. Discover
Who uses it, what they do and what it must get right. Written down, and yours whether or not we build it.
2. Design the screens
The screens people will spend their day in, agreed before anything is built behind them.
3. Build in slices
One complete, usable piece at a time. You use it, we adjust — the requirements nobody could write down turn up here.
4. Harden and test
Permissions, edge cases, backups, restores and behaviour when something it depends on is down.
5. Launch and support
A planned changeover, monitoring from day one, and an agreed arrangement for what comes next.
A long-term partner for your software.
Once your business depends on an application, the question stops being "is it finished" and becomes "who looks after it". That is an arrangement we agree with you — not something left to whoever is free.
- Uptime and error monitoring
- Platform and dependency updates
- Faults in what we built, fixed
- Backup and restore checks
- New features, quoted first
- A named person who knows your system
Web application questions
What is the difference between a website and a web application?
A website is mostly read — someone visits, finds what they need and leaves. A web application is used: people sign in and do work in it, repeatedly, and it holds data that matters to your business.
That difference drives the cost. An application needs accounts, permissions, a database designed for the job, backups you can restore from, and monitoring — none of which a brochure website requires.
Do we need an app on the App Store?
Usually not. A web application opens in a phone's browser and can be added to the home screen, where it behaves much like an installed app. Store publication is worth its extra cost when you genuinely need things only a native app can do — push notifications, offline-first working, or the camera and sensors in a serious way.
Can it work with the systems we already have?
Often, yes. If your existing system offers an API or can export and import reliably, the two can be connected rather than one replacing the other. That is its own piece of work — see API integrations.
How many users can it handle?
For the size of business we work with, the honest answer is that the number of users is rarely the constraint — how much data it holds and what it has to calculate matter far more. We will size the hosting for your actual use and tell you what would need to change if that grew significantly.
Where is the data stored?
Wherever we agree, and we will tell you before you commit. For most clients that means hosting in the EU. If you have a requirement about where data may live, raise it during discovery — it affects the choice of hosting and is awkward to change afterwards.
What happens if we stop working with you?
You have the source code and the data, and the documentation describes how it is deployed. Another developer can pick it up. We would rather you did not go, but being difficult to leave is not a strategy we use.
Let's create a solution for your business.
- No obligation
- No charge for the conversation
- Bring the spreadsheet you use now