Custom web application development
A web application is not a website with a login. It has state, permissions, money, and a growing pile of edge cases. We build the kind that stays maintainable after the third feature request.
What we build most often
Two-sided marketplaces with listings, bookings, wallets and payouts. Internal dashboards that replace a spreadsheet somebody is quietly terrified of. Customer portals attached to an existing business system. Booking and scheduling tools where double-booking is the thing that must never happen.
The common thread is that they all have a rule that must hold under concurrency, and a set of humans who will use them badly. Both are design problems more than coding problems.
Performance is part of the build, not an upsell
On our own marketplace we took mobile Lighthouse from 74 to 89 and page weight from 1,208 KB to 758 KB. Most of that came from unglamorous decisions: self-hosting fonts so a render-blocking third-party stylesheet disappeared, localising every image off external hosts, and noticing that the rupee symbol alone was pulling in an 84 KB font subset that we split down to 8.6 KB.
This very page is the other example. The site you are reading went from a mobile Lighthouse score of 30 to 97, with largest contentful paint falling from 11.1 seconds to 2.5 and total blocking time from 69,920 milliseconds to around 60. Nothing about the design changed. The mobile rendering is pixel-identical to what it was before.
| Metric | Before | After |
|---|---|---|
| Mobile Lighthouse performance | 30 | 97 |
| Largest contentful paint | 11.1 s | 2.5 s |
| Total blocking time | 69,920 ms | ~60 ms |
| Third-party requests | 5 hosts | 0 |
Accessibility and the things that quietly lose you users
We check keyboard traversal and focus rings, respect prefers-reduced-motion properly rather than disabling one animation and forgetting the rest, and test with a screen-reader tree rather than assuming semantic HTML got us there.
We also remove anti-features. One site we inherited disabled text selection, blocked copy, and overrode window.print to return false. A prospect could not copy the phone number or send the pricing page to their finance director. That was costing real conversions to deter a threat that does not exist — anyone technical bypasses all of it in seconds.
How we scope, and what it costs to get it wrong
Most bad software projects are not badly built. They are badly scoped, and the build faithfully delivers the wrong thing. So we spend the first days on the parts that are expensive to change later: the data model, who is allowed to do what, and the one rule that must never break.
For a marketplace that rule is usually double-booking. For a billing tool it is that the ledger must reconcile. For a clinical system it is that a signed result cannot be silently overwritten. Naming it early changes the architecture; discovering it in week ten changes the budget.
We quote in phases rather than as one number, because a single fixed price for an unclear scope is either padded to protect us or optimistic in a way that ends badly for you. Each phase ends with something running that you can use.
What you get at handover
The code, in a repository you own, with the deployment scripts and the infrastructure configuration alongside it. A written architecture note covering the data model, the tenancy boundary and the operational runbook. And a walkthrough with whoever will maintain it.
We do not keep clients dependent through access. If you want to move to another team or bring it in-house, everything needed to do that is already in your hands. It has happened, and it went fine.
Frequently asked
Do you use templates or page builders?
No. Everything is written for the project. That is slower up front and considerably cheaper the first time you need a behaviour a template does not support.
Will it work on low-end phones?
That is the target we test against — throttled CPU and a simulated slow connection, not a developer laptop on office wifi. It is also how we catch the problems that only appear under load.
Can you improve an app we already have?
Often the best value we offer. Performance and reliability work on an existing product tends to pay back faster than a rebuild, and we will tell you if a rebuild genuinely is the answer.
Related
Want this built?
Tell us what you are trying to ship and we will tell you honestly whether we are the right team for it.