Twenty questions,
answered plainly.

It cannot, which is why the validation sprint comes first. Two to three weeks of discovery, prototyping and specification produce a document precise enough to price against. Only then do we issue a fixed-price Statement of Work. Anyone quoting a full build price off a one-hour call is guessing and will recover the difference later.

Discovery workshops, user flows and information architecture, a clickable prototype of the core journeys, full UI design with a component library, a written functional specification with acceptance criteria, and an architecture and feasibility review. It costs a fixed fee and you keep everything even if you never build with us.

You do, from the first commit. The repository is created in your organisation, cloud infrastructure runs in your provider account, domains are registered in your name, design files sit in your workspace, and IP assignment is written into the contract rather than promised at handover.

You raise it, we assess it, and you receive a written change request with the cost and the timeline impact before anything is built. You approve or decline. Declined changes go into the phase-two backlog. Nothing is absorbed quietly and nothing appears as a surprise on an invoice.

A defect is behaviour that does not match the acceptance criteria in the signed specification — it is ours to fix at our cost. A change is anything not in the specification, including things that felt obvious. We will be explicit about which is which rather than quietly reclassifying one as the other.

If the overrun is ours, it is ours — the fixed price does not change. If it is caused by something on your side, such as a delayed sign-off or a third party we are waiting on, the timeline moves rather than the fee, and we flag it in the week it happens.

Thirty percent on Statement of Work signature, thirty on design sign-off, thirty on UAT sign-off and ten on go-live. Tied to gates rather than to the calendar, so we are never more than one instalment ahead of delivered work.

Yes. We take over existing products regularly. It starts with a paid technical audit rather than a promise, because the honest answer is sometimes that rebuilding costs less than rescuing. The audit fee is credited against a build engagement started within sixty days.

Yes to both. We work from your designs if they are complete enough to build from, and we run mixed squads with client engineers regularly. Responsibilities get written into the SOW so nobody discovers a gap during a sprint.

Mainstream, well-documented stacks — React and TypeScript on the front end, Node or Python on the back end, PostgreSQL for data, React Native or Flutter for mobile, and a major cloud provider. The specific choice is made in the validation sprint against your requirements and what you will need to hire for later.

You do, in your own account, billed directly at provider cost with no markup from us. We size it, configure it, monitor it and review the bill with you. A supplier who owns your hosting account owns your product, and we would rather not be in that position.

Sixty days of defect warranty at no cost, then an optional monthly support plan covering monitoring, patching, defect fixes and a build allowance for small features. Or you take it in-house entirely — the documentation and handover exist for exactly that.

Yes, before discovery begins, and we will sign yours rather than insisting on our template. Mutual is normal.

A squad rather than a rotating pool: a delivery lead, a technical lead, engineers sized to the scope, a designer who stays through the build, and independent QA. The same people from kickoff to handover, with one of them accountable for the whole thing.

Two-week sprints, each ending with a live demo on a staging environment you can access yourself and a written build note covering what shipped, what did not and why. No silent months.

Tell us early. Because scope is written down, it can be cut in a structured way — we can descope to a smaller working release rather than stopping with a half-finished product. What we cannot do is discover the problem at the final invoice.

Yes, in React Native or Flutter, with native where the product genuinely requires it. App store submission and review handling are included. It is priced as an add-on rather than assumed, because plenty of products do not need one at launch.

No. It sounds attractive early and it distorts every decision afterwards, on both sides. We build software for a fee and you keep your company.

The validation sprint. It is a complete piece of work with its own deliverables, and if the conclusion is that the product should not be built yet, you have spent the least possible to find that out.

A free forty-five-minute scoping call. If the idea needs building, we propose a validation sprint. If it does not, or if someone else is a better fit, we will say so in that call rather than three months into a contract.