Our stack, and why we chose it
We default to React and Next.js on the front end, Node on the back, and PostgreSQL where a relational database fits — which is most of the time. This is a deliberately unexciting stack, and the reason is hiring and handover rather than technical superiority. You can find another team who knows it. Your own developers probably already do. The documentation and the answers to obscure problems already exist.
Next.js in particular buys things that are otherwise expensive to build: server rendering for content that needs to be indexable, static generation for pages that do not change per request, an image pipeline that is a genuine Core Web Vitals lever, and a routing model that does not need a separate front-end framework decision.
We deviate when the brief demands it — a different database for genuinely different data shapes, a different runtime where the hosting environment dictates it, WordPress where the requirement is really content management. What we avoid is anything where we would be the only people able to maintain it afterwards. A proprietary framework is a commercial decision dressed up as a technical one.
How AI-assisted development changes cost and timeline
Worth being specific here, because the claims made about this are usually unfalsifiable. Our engineers use AI tools — Claude, Cursor, GitHub Copilot — daily, in specific places: scaffolding boilerplate, writing tests against existing behaviour, refactoring across many files, reading unfamiliar codebases and API documentation, and producing first-draft documentation.
Those are the mechanical parts of building software, and compressing them is where the 48 to 72 hour turnaround on a standard build comes from. What does not compress is deciding what to build, choosing an architecture that will survive the second and third round of requirements, reviewing generated code that looks correct and is not, and being accountable when something breaks in production at an inconvenient hour.
We do not publish a productivity percentage, because we have not measured one we would be willing to defend and the numbers circulating in this market are marketing rather than data. What we will say is that the saving shows up most on well-understood work and least on genuinely novel problems — which is the opposite of how it is usually sold.
The build process, phase by phase
- Technical discovery — what the system must do, what it must integrate with, and what is actually fixed versus assumed
- Architecture and scope — data model, integration points and the decisions worth making before code exists, with the risks written down
- Build on staging — implementation in reviewable pieces, with AI assistance on the mechanical work and human review on all of it
- Testing and QA — cross-browser and device, the failure paths deliberately exercised, performance and accessibility measured rather than assumed
- Launch — redirects mapped where anything is being replaced, monitoring attached before traffic arrives, rollback path confirmed
- Handover and support — documentation written for someone who was not in the build, then ongoing maintenance if you want it
What custom web development costs, and what drives the number
We do not publish rates. That is a considered position rather than evasiveness: the range across projects that all describe themselves as custom web development is wide enough that any figure printed here would be wrong for most readers, and quoting a low one to win the click and revising it on the call is a worse experience than saying this.
What we can do is tell you exactly what moves the number, so you can estimate the shape of your own project before speaking to anyone.
- Bespoke interface versus design system reuse — how much is drawn once and how much repeats
- Depth of custom logic — rules, calculations, workflows and states behind the screens
- Number and quality of integrations — a well-documented API with a sandbox is a fraction of the work of an undocumented one
- Data migration — volume, structure, and how much of it needs cleaning on the way
- Access control and compliance — roles, audit trails and anything that must be provably enforced
- Ongoing support — whether we maintain it or your team takes it over at handover
We quote a fixed figure against a scoped brief rather than working open-ended time and materials, so the commercial risk of an estimate being wrong sits with us rather than with you. Where a requirement is genuinely undefined, we scope a discovery phase separately instead of pretending to price something nobody has specified yet.
Performance, accessibility and security standards
These are build requirements rather than a final phase, because retrofitting any of the three costs several times what building them in does. Core Web Vitals are measured before handover, not asserted. Semantic markup, keyboard navigation, visible focus states and colour contrast are checked against WCAG 2.2 AA. Dependencies are audited for known vulnerabilities, secrets live in a secret store rather than a repository, and inputs are validated on the server regardless of what the client already checked.
None of this is remarkable. It is table stakes that a surprising amount of custom work still skips, usually because it was scoped as a set of screens rather than as a system somebody has to run.
