Web application development

We quote a fixed price after a scoping call rather than publishing a number, because builds have no typical size. What we can tell you is what moves it: the number of distinct user roles, whether the product is multi-tenant, whether it takes subscription payments, how many third-party systems it integrates with, whether existing data has to be migrated, and whether admin tooling is in scope. Those six factors account for most of the difference between two projects that sound the same in a sentence.

Anything substantial is split into milestones that each end at something deployable, so the useful answer is per milestone rather than for the whole thing. The scope document sets those out before you commit. A small, single-tenant application with one user role and no payments is weeks; a multi-tenant product with subscriptions, several integrations and admin tooling is months.

Yes, and it is common. We work in your repository in branches and pull requests, so your engineers review what we do and can pick it up at any point. Where there is an existing team we would rather agree a clear boundary — a service, a surface, a milestone — than interleave, because two teams editing the same files without a boundary is slower than either alone.

Usually, and we start with an audit rather than a quote. The honest reason is that inheriting a codebase blind means either padding the estimate heavily or discovering the real state halfway through, and neither is good for you. The audit tells us both what condition it is in, and it tells you something useful even if you then hire somebody else.

TypeScript, React with Next.js or Astro, Node or Python on the server, and Postgres — often via Supabase or Neon — for data, deployed to Vercel or Cloudflare. We are deliberately conservative about this: a stack that is boring and widely known is a stack you can hire for after we are gone, which matters more than any individual technical merit.

Yes, entirely, and it lives in your repository on your accounts from the first commit. There is nothing to transfer at the end and no proprietary layer of ours left behind. Our own pre-existing tools and templates stay ours, and you get a perpetual license to anything of that kind embedded in the work.

That makes it faster and we would rather you did. We build to Figma or to whatever exists. If there are no designs, we build a plain, consistent interface from a component library and say plainly that it is functional rather than distinctive — which is often the right trade early, and is always better than us improvising a brand.

It is built with the things we are usually hired to retrofit: authorization enforced on the server, database policies with tests that assert cross-tenant access fails, secrets that never reach the client bundle, validated input on every write, and rate limiting where it matters. What we do not do is issue a security certificate or run a penetration test — those are a different discipline, and if you need one for a customer or an auditor you should engage a specialist firm.

You get a written handover covering the architecture, the decisions behind it, how deploys and rollbacks work, and what the monitoring will tell you. From there you can run it yourself, hand it to your own team, or take a care retainer for monitoring, dependency updates and small changes. Plenty of projects need no retainer at all.

Yes, and it is a common reason people come to us. The work is usually less about the application code than about the data: getting it out cleanly, modelling it properly, and moving customers across without a gap. We would scope that migration explicitly rather than folding it into a build estimate, because it is frequently the larger half.