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.
What usually goes wrong
- Times stored without a timezone, so bookings drift twice a year
- Availability checked before writing, with nothing preventing two writes at once
- Forms that lose everything the user typed on a validation error
- Failures that are swallowed silently, so nobody knows an integration stopped
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 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.