Custom Web Application Development.
Custom web application development is building a browser-based system around one organisation's actual workflow, covering the interface, the API, the data model, authentication, payments and deployment, rather than configuring a general-purpose product to almost fit.
This is the bulk of the catalogue: payroll and ERP platforms, healthcare booking, client portals, marketplaces, fleet and logistics tooling, ESG reporting. Different industries, but the same failure mode when they go wrong, which is a data model that was designed around the first screen somebody drew.
The parts worth getting right are rarely the visible ones. Whether concurrent bookings can double-book the same slot, whether a payout can be traced back to the events that produced it, whether re-running last month's payroll gives the same answer twice, whether access control is enforced at the data layer or merely hidden in the interface.
Those decisions are what the engineering write-ups on the Impact page are about, and they are the reason these systems are still running.
What the engagement covers
Data model first
The schema designed around the workflow and its edge cases before the screens, because the screens are cheap to change and the schema is not.
Authentication and access control
Permissions enforced at the data layer from one central policy per module, not implemented by hiding buttons in the interface.
Payments
Stripe with pricing verified on the server, idempotent webhooks, and payment bound to the transaction it belongs to so a failure cannot leave a half-committed booking.
Correctness under concurrency
Constraint-backed locking where two users can collide, such as booking slots and inventory, so the database refuses the double-booking rather than the interface hoping to prevent it.
Auditability
Events stored raw with derived figures computed from them, so any number in a report can be traced back to its source during an audit.
Deployment and handover
CI, environments, logging and documentation, written so your own team can take it forward.
How it runs
Model the workflow
How the work is actually done today, including the spreadsheet nobody mentions. The exceptions in that spreadsheet are usually the real requirements.
Design the schema and the boundaries
Entities, relationships and module boundaries agreed before interface work starts, along with what is deliberately out of scope.
Build the critical path first
The one journey the business cannot operate without, working end to end and deployed, before anything peripheral is added.
Harden and hand over
Failure paths, permissions, logging and documentation, then a walkthrough with whoever inherits the system.
Projects built this way
Payroll System
Automated payroll platform handling salary calculation, tax compliance and benefits, with date-effective rules so re-running a past month stays reproducible.
Healthcare App
Healthcare appointment booking with constraint-backed slot locking, so concurrent requests cannot double-book, and payment bound to the booking transaction.
ERP Car Rental
End-to-end ERP for car rental businesses: fleet, bookings, billing and maintenance as four bounded modules, with GPS telemetry on a separate ingestion path.
Client Portal
Secure client portal for project tracking, communication and deliverables, with access control enforced at the data layer rather than in the interface.
Zipo Tracking
Views-to-earn platform that stores view events raw and derives earnings from them, so any payout can be traced back to its source events during an audit.
Furniture Marketplace
Furniture marketplace on Sanity CMS with Stripe payments, server-verified pricing, idempotent webhooks and query-level filtering for a large catalogue.
Questions about web application development
- What counts as a custom web application?
- Anything built around one organisation's workflow rather than configured from a general-purpose product: internal dashboards, client portals, booking and scheduling systems, marketplaces, payroll and ERP tools, and reporting platforms.
- Can you add features to an application we already have?
- Yes. Much of the work here is an addition to something already running, including custom booking logic built as a WordPress plugin so a theme update could never touch it. Existing code gets read and assessed honestly before anything is proposed.
- Do you handle payments and subscriptions?
- Yes, usually with Stripe. Pricing is verified server side rather than trusted from the client, webhooks are made idempotent so a retry cannot double-charge, and the payment is bound to the transaction it belongs to.
- Who owns the code?
- You do. The repository, the infrastructure and the documentation are yours, and the handover is written on the assumption that your own team, or another engineer, picks it up next.