Web applications for the work people do every day.

Cost follows scope, so the honest answer is a range against a defined brief rather than a number in advance. What moves it most is the number of distinct user journeys, how many roles and permission levels the application needs, how much it has to integrate with other systems, and how much discovery and design is required before engineering starts. A focused internal tool with one workflow and two user types is a very different proposition to a customer-facing platform with billing, reporting and half a dozen integrations. We would rather scope it properly than quote blind, so we start with a conversation about what the application has to do and give you a realistic range once the scope is clear.

It depends on how much of it has to exist on day one, which is the decision that changes a timeline more than any other. The most useful early work is usually separating what the first release genuinely needs from what can follow it—that often halves the time to something real people can use. We give estimates after discovery and definition, once the scope, the user journeys and the technical approach are agreed, rather than committing to a date before anyone knows what is being built. Once we start, we deliver in iterations, so you see working software early and regularly instead of waiting for one delivery at the end.

Often, yes. We take on applications where the original team has moved on, where the interface has fallen behind what users now expect, or where shipping anything new has become slow and risky. We start by understanding the current codebase, data model and infrastructure before proposing anything, then agree a sequence: what to improve first, what to leave alone, and what genuinely needs rebuilding. A full rewrite is occasionally the right answer but it is rarely the cheapest one, so the default is to keep a live application stable and working while it improves around the parts that matter most.

Yes, and for most applications it is a significant part of the work. We build APIs so your application can be consumed by other systems, and we consume third-party APIs so it can talk to the tools your users and customers already depend on—payment providers, CRMs, accounting systems, internal services. The important part is designing those connections to fail safely: retries, sensible timeouts, queued work and clear error handling, so that a third party having a bad day degrades one feature rather than taking the whole application down.

Yes. We design and build responsively, and where a journey is genuinely mobile-first we treat it that way from the start rather than shrinking a desktop layout at the end. Resova is a useful example: guests book on their phones while operators run the back office on a laptop, so the same platform had to serve two quite different contexts properly. We work out early which users are on which device for which task, because that shapes the interface rather than being a finishing touch.

We choose the stack to suit the application rather than applying the same one to every brief. In practice that means modern, well-supported web technologies with a large talent pool behind them, chosen so you are not locked into anything obscure and could hand the codebase to another team if you ever needed to. The decisions that matter more than the framework are the data model, the tenancy and access model, and how the application is deployed and monitored—those are the ones that determine whether it is still quick to change in year three.