Web Apps People
Log
Into Every Day
Dashboards, customer portals and internal tools. The software a business actually runs on, day to day. We plan the accounts, roles and reporting at the start, because adding them once it hurts is far harder.
Is The Software
Getting In The Way?
If your team has to export everything to a spreadsheet to get anything done, or types the same record in twice, the tool is in their way. That’s the part we fix.
Everything Lives In Spreadsheets
Five versions of the same file and one person who understands the formulas. Which row changed last? Who changed it? Nobody can say.
Nobody Sees The Same Numbers
Sales has one figure. Finance has another. Both were pulled by hand, so there’s nothing to settle it and the meeting opens with an argument about the data.
One Login For The Whole Team
One shared password, because roles never got built. Fine at five people. At fifty it’s an audit finding, and a worry whenever someone resigns.
It Slows Down As You Grow
Quick at two hundred records, painful at twenty thousand. Usually it’s database queries nobody planned for, and they only show up once there’s real volume.
The Business Impact of
a Real Web App
Put the records and permissions in one place and most of the copying and chasing just stops. So does the argument about whose figure is right. (If you need a brochure or marketing site, that’s a different job. See web development.)
Web App Development
Dashboards, portals and internal tools that hold the records and reports your team is working around right now.
4–6
Weeks until a small internal tool has a working first version, with the people who’ll use it already trying it out.
Once
Entered once, then reusedCut The Copying And Chasing
Type a record in once. Approvals move to the next person by themselves, and when someone asks for the report it’s already there. Fewer handovers means fewer places for a job to get stuck.
View Our WorkGetting The Data Model Right
Before anything is built, we pin down who the users are and what each record has to hold. It’s slow, unglamorous work, honestly. Everything else sits on top of it.
Data ModellingDecide what a record must hold Role MappingAgree who may do whatRoles
We agree who can see or change each record before the first screen, and the server checks it every time.
What We Do
Differently
The people planning your app are the same people designing and building it. So when something doesn’t add up, we tend to catch it on paper, well before it’s in the code.
The Real Process First
First we sit with how the work happens today: who touches what, and which step everyone quietly dreads. Only then do we decide what the software should do about it.
A Data Model That Holds
We sort out the tables and indexes before any screens. That’s why the tenth feature costs far less than the first, and why the app doesn’t slow down at twenty thousand records.
Roles Built In, Not Bolted On
Permissions are agreed early and checked by the server on every request. A user can’t get round them by fiddling with the page.
Joined To What You Run
We wire in payments, accounting, your CRM and messaging during the build. An app that can’t talk to your other tools is just one more place for someone to type.
An Admin Side You Own
You can change users, permissions, content and settings from inside the app. Day-to-day running shouldn’t need a developer (or an invoice from us).
Post-Launch Support
Launch is roughly the halfway point. We stick around for fixes and the next module, plus the awkward cases that only turn up once real people start entering real data.
How We Build
Your Web App
Five steps, from the first conversation to the Monday morning your team logs in and starts using it.
Book a callMap how the work happens
We learn how the process really runs today and who does each part. And which step is costing you the most. Nobody suggests software until we know that.
Model the data and roles
We agree the user types, write the permissions down and define the records. Every screen after this depends on it, so we don’t rush it.
Build the application
We build it a module at a time. You’ll be clicking around in the app long before it’s finished, which is when the useful feedback tends to come.
Trial it on real data
A pilot group uses it with your actual records, and we throw the awkward cases at it on purpose. This is usually where the rule nobody mentioned turns up.
Roll it out and hand over
We move your data across and set up everyone’s accounts, then walk the team through it. The hosting and the code repository go into your name.
Who You’ll Be
Working With
A good demo is easy to show off. What matters is whether your staff are still using the thing a year later, and whether we kept you in the loop while we built it.
Experienced Builders
We’ve been shipping working software since 2019, including the kind of tool a whole company runs its day on.
Built Around Your Process
Your staff, your rules and what the business can afford all go into the brief. That way each technical choice has a reason we can point to.
No Middleman
There’s no account manager passing messages along. Got a question about a module? The person who built it answers.
One Build Or Ongoing
Some clients want a single build. Others want monthly support while the app grows. Either works for us.
Fixed Price Up Front
You get a fixed quote before we start. It lists what’s included, so the cost doesn’t creep once the work is underway.
A Free First Call
We’ll look at what you’ve got and tell you honestly if we’re the right people for it. Nobody commits to anything on that call.
Got An App
In Mind?
Tell Us About It
Web App
Questions
Not sure where to start? Send us a message and we’ll talk it through. It doesn’t need to be a finished brief.
Have a quick chat first
Tell us what the app has to do and when you need it. We’ll explain how Web{X} Studio would go about it.
What counts as a web app rather than a website?
A website mostly shows the same thing to everyone. A web app has accounts, so what you see depends on who you are: your records, your permissions, the job you left half-finished yesterday. It also remembers where you were between visits. Think dashboards, client portals, booking systems and internal tools.
The real difference is underneath. A site needs pages and a CMS. An app needs a database, logins and rules about who can change what, which is why we scope and quote it differently from a marketing site.
How long does building a web app take?
A small internal tool with one kind of user usually takes 4–6 weeks. A customer portal with roles, notifications and a payment step is more like 8–14 weeks. For a full SaaS product with billing, teams and an admin side, expect around four months at least.
What really moves the timeline is how much of your process is already written down. We prefer to get a narrow first version in front of real users at six weeks, then grow it based on what they actually use.
Can it connect to the systems we already use?
Usually, yes. If a tool has an API we can connect to it, and most business software does these days: payment gateways, accounting packages, CRMs, email and SMS providers, even spreadsheets.
Where there’s no API we look at exports, webhooks or a scheduled sync before suggesting you replace anything. We check all of this during planning on purpose. Finding out in week six that a system is closed off is how timelines fall apart.
How do you handle user roles and permissions?
We design roles in from day one. Before the first screen is built, we agree the user types and exactly what each one can see, create, edit or delete. Adding permissions later to an app that assumed one kind of user is close to a rewrite.
Every check runs on the server as well as showing up in the interface. Hiding a button is a convenience for the user. It isn’t what actually protects the record.
Who owns the data once it is live?
You do. The database sits in an account in your name and you can export all of it whenever you like, without asking us. We don’t hold anything back, and we don’t reuse your data anywhere else.
Scheduled backups start on day one, before anyone has had a scare. Access to live data is limited to the people who need it, and once you’re up and running that shouldn’t include us.
What do you need from us to get started?
Show us how the work happens today. The spreadsheet, the group chat, the one person who checks everything before it goes out. The app has to replace the process you really have, mess and all.
After that we need to know who’ll use it and what each person is allowed to do, plus access to anything it has to connect to. If none of that’s written down yet, that’s fine. We’ll work it out together first.