The questions that come up before anyone signs anything.

With a short, low-commitment piece of work that frames the problem — a few conversations and a look at the systems involved. It ends with a written problem statement you own, whether or not you continue with us. That is deliberately the cheapest point at which to discover the project should not go ahead.

Mostly organisations with an existing system that has to keep running while it changes — that is where the interesting constraints are. We are a small practice, so we take on fewer projects than a large agency and are correspondingly more selective about fit.

No. AI is what we lead with because the gap between demo and production is currently widest there, but a lot of our work is the plumbing underneath it: data pipelines, integrations, infrastructure. Those are frequently what an AI project turns out to need first.

Time and materials against a fixed scope and timebox, with a written estimate and its assumptions attached so you can see which ones move the number. Dedicated team engagements run monthly with a notice period rather than an annual lock-in.

Usually, and we prefer to. We start with a short review and tell you honestly whether extending what you have or replacing part of it is the better bet. We have no interest in recommending a rewrite that is not warranted.

You do, from the first commit. Work happens in your repository under your accounts, and we do not build on proprietary components of our own that you would have to keep licensing from us. There is no version of an engagement ending where you are left needing our permission to run your own system.

Yes, and some of our work is covered by one — which is why one of the case studies on this site describes a project in detail without naming the client. If confidentiality matters to you, say so early and we will get the agreement in place before there is anything to protect.

For a well-defined first use case, typically eight to twelve weeks from kickoff to production, with something usable to look at within the first three. Projects that take substantially longer usually do so because the required data turned out not to exist in a usable form — which is why we look at your data before quoting a timeline rather than after.

Whichever fits the constraints. We benchmark candidates against your evaluation set and show you the trade-off between quality, latency and cost per call. The architecture keeps the provider swappable, so a better or cheaper option later is a configuration change rather than a rewrite.

Yes. Open-weight models can be deployed in your cloud account or on-premise, which is often the answer where data residency or regulatory constraints apply. Expect a higher infrastructure cost and lower ceiling on quality than the frontier hosted models — we will quantify that trade-off for your specific case rather than asking you to guess.

You cannot reduce that risk to zero, and anyone who tells you otherwise is selling something. What you can do is measure the rate, ground answers in retrieved sources the user can check, constrain the system to a defined job, and route low-confidence cases to a human. We design for the failure being visible and recoverable rather than silent.

Access to representative data, and a person on your side who knows what a good answer looks like. That second one matters more than it sounds — the evaluation set is built from their judgement, and no amount of engineering compensates for its absence.

It depends on volume and model choice, and we model it explicitly during discovery so the number is not a surprise. Running cost is a design input for us, not an afterthought: it changes what architecture makes sense, and there are usually large savings available from caching, routing simple cases to smaller models, and not calling a model where deterministic code would do.

Time-and-materials against a fixed scope and timebox, with a written estimate and its assumptions. Genuinely fixed-price only works when the requirements cannot move, which is rare in product work — and when it is forced, both sides end up arguing about change requests instead of building.

Usually. We start with a short review to find out what we are dealing with and tell you honestly whether extending it or replacing part of it is the better bet. We have no interest in recommending a rewrite that is not warranted — rewrites are where projects go to die.

TypeScript across the stack by default, with a mainstream framework and a relational database. For mobile we use native or Flutter depending on how much platform-specific behaviour you need. If your team already has a stack they can maintain, matching it usually beats introducing ours.

You do, from the first commit, in your repository. No proprietary components, no licensing that follows you, no dependency on us to keep it running. If you want to take the work in-house at any point, that should be a decision rather than a negotiation.

Yes, and we prefer to. Interface decisions and implementation constraints inform each other constantly, and splitting them across two vendors adds a translation layer where detail gets lost. If you have a design partner already, we work with them directly.

Whatever you need and nothing you do not. Some clients take the work in-house immediately, which is a fine outcome and one we plan for. Others keep us on a support arrangement sized to the system’s real criticality. We review that arrangement periodically and will tell you when it stops being worth its cost.

Often not. It earns its operational overhead when you are running enough services, with enough scaling variability, that orchestration saves more than it costs. For a single application with predictable load, a managed platform is usually cheaper, simpler and easier to hire for. We will tell you which situation you are in before proposing work.

The major providers, and self-hosted or hybrid infrastructure where that suits your cost profile or data residency requirements. We run our own production workloads on self-managed infrastructure, so the trade-offs are ones we live with rather than ones we have only read about.

In most cases yes, using parallel running and staged cutover, though it costs more than a maintenance window and is not always worth it. We will price both and let you choose. What we will not do is attempt a cutover with no tested way back.

By measuring first. Most overspend concentrates in a few places: oversized instances, storage nobody deleted, data transfer nobody accounted for, and non-production environments running around the clock. Those are usually addressable without touching architecture.

That is the explicit goal. Everything lives in your repositories and your accounts, with runbooks written for someone who was not present when it was built. We would rather hand over cleanly than hold a dependency — a client who cannot operate without us is a liability for both of us.

Yes, sized to the system’s real criticality rather than a standard tier. For many clients that is business-hours support with an escalation path, not a 24/7 rotation they are paying for and never using.

Usually. Options range from database replication to file-based exchange to, in the worst case, a carefully built scraper against a legacy interface. Each carries different fragility, and we will be explicit about which one we are proposing and what will break it. Legacy integration is normal work, not a blocker.

By establishing which one is authoritative for each field, in writing, before building anything. Most reconciliation pain comes from that question never having been answered — two systems both believing they own the customer record. This is a business decision more than a technical one, and we will push for it to be made explicitly.

Only if you are combining sources or need history your operational systems do not keep. If you have one main system and want better reports out of it, that is a reporting problem and considerably cheaper. We would rather point that out than sell you a warehouse.

Yes. The warehouse and pipelines are the part that matters and are tool-agnostic; whichever BI layer your team already knows is usually the right one to keep. Switching tools rarely fixes a problem that originates upstream in the data.

A straightforward two-system integration is typically a few weeks. What extends it is almost never the code — it is access, credentials, undocumented behaviour in the third-party system, and edge cases nobody remembered. We front-load discovery of those precisely because they dominate the timeline.

Off-the-shelf platforms are a good fit for common connections between popular tools, and if that is your situation you should use one. Custom work earns its cost when the logic is specific to your business, the systems are unusual, or per-record pricing at your volume exceeds the cost of building it. We will say which case you are in.

One month, with a notice period after that. We do not ask for annual commitments — if the arrangement is working you will want to continue it, and if it is not, a contract should not be what keeps it alive.

Yes. You interview candidates and approve them before they start, and we do not substitute people afterwards without your agreement. Continuity is most of the value in this model; a rotating pool is just a more expensive way to lose context.

It is faster to start and faster to stop, which is worth paying for when the need is uncertain or time-boxed. Direct hiring is usually better value for a permanent, well-understood role. If that is your situation we will say so — it is a shorter engagement for us and the right answer for you.

We agree an overlap window with your team up front and staff accordingly. Some work suits asynchronous collaboration and needs very little overlap; anything involving live debugging or design discussion needs several hours a day. Which one you need is worth deciding before the engagement rather than during it.

You do. The engineers work to your priorities and your definition of done. We handle employment, holiday cover and the pastoral side, and we will flag it privately if we think the direction is going wrong — but the backlog is yours.

It stays with you, by design. Work is documented as it happens rather than in a handover scramble, and the closing weeks include an explicit transfer to whoever is picking it up. An engagement that ends with your team unable to continue has failed, regardless of what was shipped.