Data-heavy web applications people use all day without complaint
A website is read. A web application is worked in, often for hours, by people who will notice every unnecessary click. That difference changes almost every technical decision.
What is web application development?
Web Application Development is building software that runs in a browser and is used as a working tool rather than read as a page, covering data-heavy interfaces, permissions, real time updates and offline tolerance. It suits Australian organisations replacing spreadsheets and manual processes with a system staff use every day.
Get a fixed written quote- Typical timeline
- 14 to 26 weeks
- What drives cost
- Role count and permission complexity, integration count, data migration difficulty.
- Best for
- Internal tools, operational systems and customer facing portals used regularly
- You own
- The repository, the data and every hosting and service account
- Built with
- React or similar, typed APIs, server-side data handling, offline tolerant sync
Your handover
What separates a web application from a website
A marketing site optimises for a first time visitor who arrives, reads and leaves. Success is a fast first paint and a clear message. A web application optimises for the hundredth session of someone who knows exactly what they came to do and wants it done in three keystrokes. Success is throughput. The two goals pull in different directions often enough that treating an application like a site produces something that looks lovely and is exhausting to operate.
- 01Data model and permission model documented before build
- 02Interface prototypes tested with real operators
- 03Application built in tested, typed, reviewable code
- 04Server enforced authorisation with an audit trail
- 05Offline tolerance and conflict handling where field work requires it
- 06Data migration with reconciliation against source records
- Performance testing at production scale volumes
- Role-based training recordings for each user group
- Deployment, monitoring and rollback documentation
The rest of the answer
That changes the engineering priorities in web application development. Keyboard navigation stops being an accessibility checkbox and becomes a productivity feature that power users depend on. Bulk operations matter more than beautiful individual records, because someone has forty of these to process before lunch. Table density, saved filters, sensible defaults and remembering the last view are what staff notice. So is behaviour when things go wrong: what happens to a half completed form when the connection drops on a train between Sydney and Newcastle. Getting the boring parts right is most of the job, and it is why we prototype the two or three highest volume screens with real users before building the rest.
Pagination and cursor based navigation instead of loading everything.
State, caching and the sync problem nobody scopes
The hardest part of a serious web application is knowing what is true. The server has a version of a record, the browser has a cached copy, a colleague has it open in another tab, and one of them is about to save. Most software handles this by pretending it does not happen, which is fine until two people edit the same job and one silently loses their work.
More on state, caching and the sync problem nobody scopes
We deal with it explicitly. Server state and client state are separated rather than dumped into one global store, so the application knows which data can be stale and which cannot. Records carry a version so a conflicting save is detected and the user is told, instead of the last writer quietly winning. Optimistic updates make the interface feel instant while the request is in flight, with a defined rollback if it fails. Where staff work in the field with poor coverage, we build offline tolerance deliberately: queue the actions, sync when connectivity returns, and design what happens when the sync finds a conflict. This is real work with real edge cases, so we scope it as a feature rather than assuming a framework will provide it.
How the engagement runs
How a web application build runs
We sequence web application development so the riskiest and highest volume parts get built and tested first. The screen someone uses two hundred times a day deserves more attention than the settings page, and that is not always where a feature list puts the emphasis.
- 01Process and data discoveryCurrent workflow, the spreadsheets running beside it, and the data model underneath
- 02Stage 2Permission and role model agreed and documented before interface design begins
- 03Stage 3Interface prototypes for the highest volume screens, tested with the people who will use them daily
- 04FoundationsAuthentication, authorisation, audit logging, error handling and the deployment pipeline
- 05Stage 5Feature slices delivered end-to-end, each usable and reviewed by real operators
- 06Stage 6Data migration from the existing system or spreadsheets, reconciled against source records
- 07Stage 7Load and edge case testing with production scale volumes rather than a demo dataset
- 08Stage 8Pilot with one team, then staged rollout, training recordings and handover documentation
Two decisions on your side that keep the project moving
Real data enters the project early. Prototypes built on tidy sample records hide the problems that matter, because your actual data has duplicate customers, records with missing fields and a client name long enough to break a layout. We load a realistic extract into the development environment in the first fortnight.
Design permissions before you design screens
Permissions built after the fact become a maze of conditional checks nobody can reason about, and they are the source of a disproportionate share of security incidents. We define the model up front: who can see which records, who can change them, who can approve, and what happens to a record when the person who owns it leaves.
In Australian operations the model is rarely a simple hierarchy
In Australian operations the model is rarely a simple hierarchy. A national business might scope visibility by state, a franchise group by territory, a professional services firm by client with an ethical wall between two teams, and an NDIS provider by participant with strict rules about who may read a support plan. Those rules belong in one authorisation layer enforced on the server, checked on every request, with the interface merely reflecting them. Hiding a button is presentation, not security. We also build the audit trail at the same time, because knowing who viewed or changed a sensitive record is usually a requirement in these sectors and it is far cheaper to build alongside the permission model than to add later.
Performance when the dataset is genuinely large
Applications feel fast in development because the database holds two hundred rows. At two million the same screen takes eleven seconds and nobody planned for it. This is the most common reason an internal tool gets abandoned within a year, and it is avoidable.
Pagination and cursor based navigation instead of loading everything
We test against realistic volumes from early on and design accordingly. Pagination and cursor based navigation instead of loading everything. Search delegated to an index rather than a wildcard query across a large table. Virtualised rendering so a long list only draws the visible rows. Expensive reports moved to background jobs that notify when ready, rather than a request that times out. Database indexes chosen against the queries the application actually issues, verified by looking at query plans rather than hoping. Where the reporting need is genuinely analytical rather than operational, we separate it entirely and feed a reporting tool covered in Power BI, because an application database serving both jobs does neither well.
When a spreadsheet or an off-the-shelf tool is the better answer
A spreadsheet that three people use and understand is not a problem to be solved. It becomes one when it is emailed around, when two versions disagree, when it holds personal information without access control, or when the person who wrote the formulas leaves. Until then, web application development is a cost with no return, and we will say so.
Look hard at existing products first
Look hard at existing products first. Project management, ticketing, general CRM and document approval are mature categories with capable tools, and a configured product beats a custom build for a standard need. If the gap is that two systems do not talk to each other, that is workflow automation rather than a new application. If what you need is a place for clients to see their own information and submit things, a client portal is a smaller and better defined project. And if the users are mostly on phones in the field, look at a progressive web app or a mobile app before committing to a desktop shaped interface they will resent.
How we scope it
Four ways to scope your Web Application Development project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
Discovery build
A scoped build with the architecture settled first
Fixed written quote, agreed before work starts
- Data model and permission model documented before build
- Interface prototypes tested with real operators
- Application built in tested, typed, reviewable code
Product build
A working product your customers or staff use daily
Fixed written quote, agreed before work starts
- Everything in Discovery build
- Server enforced authorisation with an audit trail
- Offline tolerance and conflict handling where field work requires it
- Data migration with reconciliation against source records
Platform build
A platform with SSO, audit trails and a security review
Fixed written quote, agreed before work starts
- Everything in Product build
- Performance testing at production scale volumes
- Role-based training recordings for each user group
- Deployment, monitoring and rollback documentation
Product care
A named engineer, a roadmap and real service levels
Rolling monthly, quoted in writing
- A named engineer rather than a ticket queue
- A roadmap you set, worked through each month
- Dependency patching, monitoring and incident response
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
Ownership and handover
Do we own the application and the data in it?
Yes, without qualification. The repository is under your organisation, hosting and service accounts are in your business name, and your data is exportable in a standard format at any time. There is no per user licence payable to us and no proprietary runtime in the middle. If you later move to another development partner, they get the same documentation we work from.
What happens after launch and during the first busy period?
We run a support window after go live where defects against the agreed specification are fixed at no charge, and we monitor error rates and slow queries actively during the first weeks because real usage always finds something. Beyond that most clients keep a monthly allocation for improvements, since an application people use daily generates a steady stream of small changes worth making.
Detail and edge cases
How long does a web application take to build?
Usually 14 to 26 weeks, with a pilot version in front of one team well before the end. The variables are the number of distinct user roles, how many systems it must integrate with, and the state of the data being migrated. Applications replacing a long standing spreadsheet often take longer than expected, because the spreadsheet contains undocumented rules that only surface during discovery.
What makes one web application cost more than another?
Role count and permission complexity, integration count, data migration difficulty, and whether real time or offline capability is genuinely required rather than merely wanted. Most of the range comes down to those four. Screen count matters far less than people assume, since screens built from an established component set are quick. We scope in discovery and issue a fixed written quote for the agreed build.
Will it work on phones and tablets?
It will work, and the honest question is how well the workflow suits a small screen. We design the high frequency mobile tasks properly, typically approvals, lookups, status updates and photo capture, and accept that a dense administrative table belongs on a desktop. Trying to make every screen equally good on a handset usually produces something mediocre everywhere, so we prioritise instead.
Can it replace the spreadsheets our team currently relies on?
Usually, and the migration deserves respect. Those spreadsheets carry years of accumulated rules, exceptions and workarounds that nobody has written down. We spend discovery time extracting that logic, decide with you which parts to keep and which were compensating for a limitation that no longer applies, then migrate the data with reconciliation so the totals in the new system match the old ones on day one.
Related services
Describe the process you want to replace
Tell us who uses it, how often, and what the current spreadsheet cannot do. Reply inside one business day, fixed written quote once the scope is agreed.