Web Application Development
We Build the Web App That Replaces the Spreadsheet.
Internal tools, admin panels, and customer portals for businesses that have outgrown Excel and no-code. Who can see what, how it talks to your other systems, and how staff will take to it are worked out in the first week.
Available for new projects
Who This Is For
If one of these is you, keep reading.
Operations-Heavy Small Businesses
The system is a spreadsheet, an email chain, and one person who understands both.
Businesses Drowning in 'Where Is It?' Tickets
Customers asking where things are. A portal answers them without a person in the loop.
Teams That Have Hit the No-Code Ceiling
Airtable, Retool, or Bubble stopped fitting, whether on price, permissions, or what it can connect to.
Owners Who Want a Live Dashboard
Instead of a report someone puts together by hand every month.
Regulated Firms
Audit trails and access rules the current tools can't show an auditor.
Why Replace the Spreadsheet
It usually starts with something in the day-to-day going wrong.
Spreadsheets That Turned into Systems
94% of operational spreadsheets have errors in them. When that spreadsheet quotes prices or works out pay, that's a real risk.
Customers Helping Themselves
Most support tickets are someone asking where their order, invoice, or job is. A portal answers that without anyone picking up the phone.
One Place the Truth Lives
When data sits in five tools and an inbox, every report means reconciling it all first. One system of record puts a stop to that.
Outgrowing No-Code
Airtable, Retool, and Bubble are the right way to start. Then the per-seat bill, the permission limits, and the things it can't connect to all turn up at once.
Compliance and Permissions
Audit trails and proper access rules. A shared spreadsheet or generic software can't give you those.
One Person Who Knows How It Works
One person understands the macro or the chain of Zaps. A proper application gets that knowledge out of their head.
What Makes Web Applications Hard
The code is rarely the hard bit.
Scope Creep
52% of projects get it. What you want on day one isn't what you need on day ninety, and the plan has to leave room for that.
Nobody Agreeing on What It Should Do
The Standish Group has put clear requirements near the top of the success list for decades. Most projects start without them.
Who Can See What
Broken access control is number one on the OWASP list. Every application OWASP tested had some form of it.
Talking to Your Other Systems
Old data in a server under someone's desk, accounting software that only exports CSV, a CRM nobody ever set up.
Getting Staff to Use It
Most internal tools launch with an email and a link. Then people go back to the spreadsheet. If nobody uses it, it's failed, however good the code is.
Staying Fast as You Grow
Quick with ten users and a thousand records has to stay quick with a hundred users and a million.
Web Applications in Numbers
Why small releases and permissions-first beat one big build.
94%
of operational spreadsheets contain errors.
45%
average budget overrun on large IT projects, which deliver 56% less value than predicted.
52%
of projects experienced scope creep, up from 43% five years earlier.
100%
of applications tested by OWASP had some form of broken access control.
Sources: Panko, What We Know About Spreadsheet Errors · McKinsey & Oxford, Delivering Large-Scale IT Projects · PMI, Pulse of the Profession (2018) · OWASP Top 10 (2025), Broken Access Control
Where Web App Builds Go Wrong
Five mistakes we've seen in other people's projects, and avoided in ours.
Trying to Build Everything at Once
Standish data shows small projects succeed far more often than big ones. The longer the timeline, the further off the estimate.
Nobody Wrote Down What It Was For
If nobody wrote the benefits down, nobody measures them, and nobody notices when the tool quietly stops delivering them.
Built for Managers, Used by Staff
Getting users involved is Standish's top success factor. Tools designed from the org chart get worked around by the people doing the job.
Treating Adoption as a Training Problem
Staff won't use a tool that makes their day harder. That's a design problem, and a training session won't fix it.
Permissions Added at the End
Bolting access rules on after the data model is set is exactly how the OWASP number-one failure happens.
How We Build It
We've shipped our own products. Small releases, the people doing the work in the room, and a data model that outlasts version one.
Map the Work First
We sit with the people doing the job and map how it happens, workarounds and all. The spreadsheet is the brief.
A Small First Release
The smallest version that replaces the current process for one team. Live in weeks, then extended based on what real use tells us.
Data and Permissions Before Features
Roles, who can see which rows, and audit logs are designed in at the start.
Talks to What You Already Run
CRM, accounting, ERP, support desk. Data gets entered once and matches everywhere.
Built So People Actually Use It
Screens shaped by the staff who'll use them, existing data brought across, and a rollout plan so the spreadsheet really does get switched off.
Built to Grow
Tested on the paths the business depends on. Still fast at ten times today's load.
What we build with
- Next.js
- React
- TypeScript
- Node.js
- PostgreSQL
- Supabase
- Prisma
- AWS
- Vercel
- Figma
Built the same way: Receivables · Banyan · Egis · Lift
Why We Ship in Small Steps
A year-long build with one launch day is how internal tools end up unused. We ship a new release every two weeks, and the spreadsheet stays open until the team stops needing it.
A First Release in Use in Weeks
One team, one workflow, live and in daily use inside the first month. Your staff are working in it.
The People Doing the Work Steer the Roadmap
Once a team is using it, what to build next stops being a guess. The screens they lean on get finished first. The ones they route around get rethought.
Stop at Any Point
Every two weeks you see a live demo of what shipped and make a decision: keep going, change direction, or stop. You are billed per step, so if you stop, you pay for what shipped.
Change Your Mind Cheaply
After a two-week step, a scope change costs days. After a big-bang build it costs months. The things we fix early are the data model and who can see what.
Hardest Parts First
The data model, permissions, the spreadsheet import, and the link to your least cooperative system get built before anything cosmetic. If something is going to be expensive, you find out in week two.
No Big Switch-Off Day
The old process and the new one run side by side until the team trusts the new one. Then the spreadsheet gets switched off.
How a Fixed-Price Web App Build Runs
Short loops. A small first release your team is using within weeks, then a new one every step. You own the code throughout.
- Typical timeline
- 8-16 weeks
- First release in use
- Week 4
- Live demo
- Every 2 weeks
- 01
Discovery Workshop
Week 1A fixed-fee week. We map the workflows, users, data, and other systems with the people who use them. You keep the map and the scope document whether or not you go ahead.
- Workflow map
- Scope document
- Fixed price for the build
- 02
Scope and Prioritise
Week 1-2A small first release for one team, plus a way of handling the changes that will come.
- First-release scope
- Permission model
- 03
Design With the People Doing the Work
Week 2-3Screens tested with the staff who'll use them every day.
- Clickable prototype
- Staff-tested screens
- 04
Build in Short Loops
Week 3-10Data model and permissions first, then features in two-week steps. The first release is in daily use by week four.
- First release, week 4
- New release every 2 weeks
- Live demo every 2 weeks
- 05
Connect and Migrate
Week 8-12Existing data brought across. Links to your other systems built and tested.
- Data migrated
- System links live
- 06
Security Review and Acceptance Testing
Week 12-14An OWASP review, then staff run the real workflow through it before launch.
- Security review
- Staff sign-off
- 07
Launch and Improve
Week 14-16, then ongoingHelp with the rollout, the old process switched off, improvements based on how it's used. On a monthly retainer, or handed over to your own team.
What It Costs
Fixed fee
Ends with a scope document and a fixed price for the build. Yours whether or not you go ahead.
- Scope document
- Fixed price
$20k - $100k
The number moves with how many workflows the tool covers, what it has to connect to, and how much data has to come across from the spreadsheet. An admin panel for one team sits at the low end; a customer portal with billing and support wired in sits at the top.
- Billed
- Per 2-week step
- Stop
- At any point
- Price moves
- Only if scope does
No-Code or Custom
Start with no-code. Move when you hit these.
Stay on No-Code While
The process is simple, one team owns it, there isn't much data, and the seat bill doesn't sting.
Move to Custom When
You need to control who sees which rows, connect to something the platform can't, keep it fast at scale, or the seats cost more a year than a build would.
Internal Tool or Customer Portal
Internal tools are built for speed for your staff. Portals are built for customers to help themselves and feel confident doing it. Same engine underneath, different front.
Common Questions
If yours isn’t here, book a call and ask.
What's the Spreadsheet Called?
Tell us what it tracks and who looks after it, on the call. If it's a fit, a one-week discovery follows, and at the end of it you have a first release scoped, with a timeline and a fixed price.