Thequestionspeopleaskbeforetheyhireus.

You get a reply from an engineer within one working day, usually with questions rather than a calendar link. If the answers suggest a fit, we book one forty-five minute call to agree what the business actually needs to change.

After that call you get a written scope, a build sequence and a cost range. Neither the call nor the document is charged for, and neither commits you to anything. If we think the problem does not need custom software, or needs a different kind of firm, we say so at that point instead of quoting.

That is the normal starting point and it is not a problem. Most clients arrive with a business problem and a rough idea rather than a document — writing the specification is the first stage of the work, not a prerequisite for talking to us.

Discovery turns what you already know into a written brief: who uses the software, what it has to do, what it must integrate with, and what is explicitly excluded from the first release. You approve that document before anything is built, so the scope is something you signed rather than something you were told.

Yes, and a good share of our work is exactly that. We can take one product area end to end, add capacity inside your existing process, or run a build while your team owns a different part of the system.

In that arrangement we use your repository, your branching model, your CI and your review standards rather than importing ours. What we ask for in return is one technical decision-maker on your side, so architectural questions get an answer in a day rather than a fortnight.

Yes. We will sign your NDA before any detail of the project is discussed, and we will send ours if you do not have one ready.

Confidentiality is also written into the engagement agreement itself, so it covers the whole project rather than only the sales conversation. We do not publish client names, screenshots or case studies without written permission, which is why parts of our portfolio are described without naming the company behind them.

You get a written update and a running environment every week, for the whole project. The update states what moved, what is blocked, what changed in scope and what that change costs.

A staging URL goes up in the first week and you can open it whenever you like — progress is something you click rather than a percentage on a slide. If a week produced nothing worth showing, that is the update you get, in the week it happens rather than at the end.

Both, and roughly half of what we do is work on code somebody else wrote. Before changing anything we run a read-only audit: entry points, data model, dependency health, test coverage, and the paths most likely to break.

That audit arrives as a written document with a risk-ranked list, and it is useful on its own even if you take it no further. Rebuilds then run route by route with the old and new systems side by side, rather than as a single cutover weekend — a big-bang replacement is the way these projects usually fail.

You do. Ownership of everything we build for you transfers on full payment, and that is the only condition attached to it.

The work sits in your repository and your cloud accounts from day one, with full commit history, environment configuration and the deployment runbook included. There is no licence to renew, no component you keep paying us to use, and nothing that requires us to still be in the picture. Open-source libraries keep their own licences, and we list every one we depend on.

Most clients continue on a monthly support retainer covering dependency and security updates, monitoring and alert response, and an agreed number of change requests. It is optional, not a condition of the build.

Every project also carries a warranty period during which defects in what we built, measured against the agreed scope, are fixed at no charge. Clients who prefer to run the system themselves get the runbook, the alert configuration and a handover session with their own engineers instead.

TypeScript across the stack, Next.js and React on the web, Node with NestJS or Express on the server, PostgreSQL as the default database, React Native for mobile, and Python where the work is AI or data. Infrastructure is containerised and deployed through CI on AWS, Google Cloud or Vercel, depending on what you already run.

The choices are deliberately boring, with long support horizons and large hiring pools, because you have to staff this after we leave. If you already have a stack and a team that knows it, we work in yours rather than argue for ours — the exception is a dependency that is genuinely unmaintained, and there we will say so with the evidence attached.

You can, at any point, and everything needed to do it already exists. Code, infrastructure and third-party accounts are in your name throughout, so there is nothing to hand over that you do not already hold.

We will still run a proper handover: a walkthrough of the architecture and the decision record with your engineers, the deployment and rollback runbook, and answers on call for an agreed window afterwards. A system only we can maintain would be a badly built system.