Web application development
Where the difficult part is not the pages but the behaviour: what happens on a slow connection, in two tabs at once, when the same booking is taken twice.
What this covers
- Scheduling, booking and availability, including timezones and double-booking prevention
- Dashboards where the numbers must reconcile with the underlying records
- File upload, processing and storage with sensible limits and validation
- Integrations with calendars, payment providers, messaging and accounting systems
- Long-running work moved out of the request cycle, with visible progress and retries
When a company needs this
When the product itself is the software rather than a website that describes it. Or when an internal tool has become the way work gets done and can no longer be a side project.
Also when an existing application works for ten users and falls over at two hundred.
Problems we find in existing systems
- Times saved without a timezone. Bookings shift by an hour when the clocks change and customers turn up at the wrong time. We store every time in UTC with the zone attached and test the changeover dates.
- Availability checked, then written separately. Two people clicking at once both get the same slot. We make the database reject the second booking, so double-booking is impossible, not just unlikely.
- A validation error wipes the form. People who typed a long request give up and leave. We keep what they entered and show exactly which field needs fixing.
- Errors hidden from the team. An integration stops and nobody notices until a customer complains. We log failures and alert a person the same day.
What we do
We identify the operations where correctness matters and make them safe at the database level: constraints and transactions rather than hopeful checks in application code.
Every external call gets a defined behaviour for failure, a retry policy where appropriate, and a record that someone can look at afterwards.
How the engagement runs
- Scoping phase covering the state machine, the failure cases and the integrations
- Build in phases, starting with the operation the business cannot afford to get wrong
- Test coverage focused on the rules, not on percentage figures
- Handover with runbooks for the integrations you now depend on
Tell us what the application has to get right.
The operations that cannot fail matter more than the feature list.