What we build
Web application development
A web app is software your team opens in a browser and works in all day. No installing anything, no version that is out of date on one laptop, and no per seat licence for a product that does four fifths of what you need.
What it is
A web application is the middle ground between a spreadsheet and a product you buy. It has logins, its own database, screens built for the jobs your people actually do, and rules that stop the wrong thing being saved.
It is the right shape when the work is done at a desk, when more than one person needs to see the same thing at the same time, and when what you need does not map onto anything you can buy. It is the wrong shape when a product already does the job, and we will say so.
When a business needs one
- The real system is a spreadsheet, and only one person fully understands it
- Two people have edited the same row and neither knows whose version is live
- You pay per seat for a tool where most of the seats use a quarter of it
- The process only works because somebody remembers to do a step that is written nowhere
- Getting a straight answer about the state of the work means asking three people
What we can build
Capability, not a claim about work already delivered. What we have actually built and run is further down the page.
- Screens built around a job rather than a database table, so the work reads in the order it happens
- Accounts, roles and permissions, so people see what is theirs and nothing else
- An audit trail of who changed what and when
- Search and filtering across everything, rather than opening records one at a time
- Bulk actions, so a change to forty things is not forty clicks
- Exports that a finance person can open without being handed a weapon
- Notifications that reach the person who has to act, at the point they have to act
How we approach it
We start from the work, not the screens. What happens now, who touches it, and where it currently goes wrong. Most of what a first version needs is already visible in the spreadsheet somebody has been maintaining by hand.
The first release is deliberately narrow: the one part of the process that costs the most time, built properly and used in anger. Everything after that is decided by what the people using it hit first, which is rarely what anyone predicted.
Things we have already built
Live in software we have delivered, and part of the 123 things we have built.
What the team is doing, live
You can see a bad week on the Tuesday, while there is still time to change it.
A screen that tells you what today is
The day starts already decided, so the first hour goes on work instead of triage.
Grouping customers the way you actually think about them
The system organises people the way you already do, so nobody has to translate between the two.
A record of who changed what, and when
When something looks wrong you can answer who did it in a minute, rather than reconstructing it from memory.
Everything out to a spreadsheet, without handing over a weapon
Your data is yours to take out, and the file you send a client cannot execute something on their machine.
Numbers that cannot contradict each other
Every number in the system comes from one calculation, so nobody has to work out which screen to believe.
Related to this
Tell us what you are trying to fix
Describe the job in your own words and we will tell you what we would build, roughly what it would cost, and whether something you can already buy would do it cheaper.
