Design it, build it, ship it, keep it running

With a conversation, not a proposal. You tell us what the product needs to do and where it is stuck now, we ask the questions that change the answer, and you get back a written outline of the approach, a realistic timeline and the parts we think are risky. That costs nothing and carries no obligation. If we think you would be better served by a smaller piece of work, or by someone else, we say so at that point rather than after you have paid for a discovery phase.

It depends on scope, and anyone quoting before they understand the workflow is guessing. What we can tell you is how we price: a defined piece of work is quoted as a fixed scope with a fixed number, and open-ended work runs monthly with an agreed capacity. In both cases you see the sequence in advance, so you know what lands first and what can wait. Small integrations run in weeks. A platform that replaces a real operational process runs in months, and we would rather say that at the start than discover it at month four.

Usually, yes, and it is a good part of what we do. We begin with a short review of the current state: what it does, what is fragile, what would break if you changed it, and which of those actually matters to you. From there we propose the shortest sequence of changes that reaches your outcome. A full rewrite is the last option we reach for, not the opening move, because it throws away years of edge cases somebody already paid to learn.

Yes, and it works better than running a parallel track. We join your repositories, your board and your review process rather than setting up a second one beside it. Where your conventions differ from ours, we use yours, because the code has to make sense to your team long after we have stopped touching it.

Yes. Interface, API, data model and infrastructure are normally one engagement, which is the point: most of the awkward bugs in a product live on the boundary between two of those, and they are far cheaper to prevent than to negotiate between two suppliers later.

Both. An early product gets a narrower scope and a lighter architecture, and it should, but it gets the same standards for testing, security and handover. First versions have a habit of still being in production five years later, so we build them as though yours will be.

It usually does, and that is fine as long as it is visible. When a request will not fit the timeline, we say so while there is still room to reshape it, and we set out the options: move the date, drop something else, or narrow the request. What we do not do is absorb it quietly and hand you a surprise at the end.

Yes. Product configurators, real-time material and finish preview, interactive catalogues and data visualisation, built with WebGL and Three.js. The part people underestimate is performance: we test on mid-range phones, not just the machine it was built on, and we design a sensible fallback for the devices that cannot run it.

Usually. It works best pointed at one defined job, such as classifying a queue, pulling structured data out of documents, drafting a first version or making a search behave sensibly, rather than bolted on as a general assistant. We scope it against a task you can measure, design for the cases it gets wrong, and keep a person in the loop wherever being wrong is expensive.

Two options, and you choose. Either your team takes full ownership using the handover package, which is code, documentation, infrastructure and access in a state somebody else can pick up, or we stay on an agreed cadence covering updates, monitoring and defect response. Nothing about the first option is designed to make the second one necessary.

You do, from day one rather than at the end. Repositories, infrastructure, domains and third-party accounts are created in your name wherever possible, and transferred to you at handover where they are not. Nothing important should sit in an account only we can open.