Question 1

What kinds of projects do you take on?

Accepted Answer

Custom software, web applications, integrations between existing systems, technical advisory, and ongoing support. The brief varies widely: sometimes a specific product feature the internal team has not had capacity to ship, sometimes a full new build, and often a piece of integration or data work that has sat on a backlog for months. We are happy to start small. A short discovery, a targeted two-week engagement, or a code review is a reasonable way for both sides to decide whether the working relationship makes sense before anyone commits to something bigger.

Question 2

How do engagements usually start?

Accepted Answer

An introductory conversation, usually 45 minutes, where we listen more than we pitch. If there is a good mutual fit we follow up with a short written scope that sets out what we would deliver, how long it is likely to take, and where the honest risks sit. We avoid high-pressure sales and prefer to share a realistic view of cost and timeline before anyone commits. If a project is not a fit for us — wrong domain, wrong size, wrong moment — we will say so directly and, where we can, point to someone better suited.

Question 3

Do you work with new-build or existing systems?

Accepted Answer

Both, and in practice a significant share of our work is on software that already exists. That includes modernising older codebases, stitching together systems that were never designed to talk to each other, and extending products originally built by other teams. We are comfortable with inherited architectural decisions, partial documentation, and code we did not write. Greenfield work is welcome too, but we are equally happy picking up something mid-stream and getting it into a state where it can keep moving.

Question 4

Can you work alongside our internal team?

Accepted Answer

Yes. We are comfortable joining an existing team and adapting to its stack, sprint rhythm, and review practices, or leading delivery independently with agreed check-ins. Depending on what is useful we can embed a senior engineer for a specific capability, pair with your team on unfamiliar parts of the codebase, or pick up a well-defined workstream and report in at whatever cadence suits. The shape of the collaboration is something we agree in the written scope and adjust once we can see how the work is actually landing.

Question 5

Do you collaborate with partner firms?

Accepted Answer

Yes. For larger or regulated scopes, or for disciplines that sit outside our core engineering focus, we regularly deliver in partnership with trusted firms. You get the specialist input without losing a single accountable contact on our side. Typical partners include design studios when a project needs heavier visual work, legal or compliance specialists on regulated builds, and infrastructure or security partners when the work is meaningfully ops-heavy. We are transparent from the outset about who is doing what and how the commercials sit.

Question 6

How do you handle confidentiality?

Accepted Answer

We sign mutual NDAs as standard. Anything we talk about publicly — on this site, in new-client conversations, or elsewhere — is anonymised unless a client has explicitly asked to be named. A large share of our work sits under confidentiality agreements, which is one reason the public case material is a small fraction of what we have delivered. We also take repository access, credential handling, and data hygiene seriously: access is scoped, time-bound, and revoked at the end of an engagement.

Question 7

Do you offer ongoing support after launch?

Accepted Answer

Yes. We offer explicit support and maintenance agreements with defined response windows, a named engineering contact, and regular reviews of what is happening in the codebase. That includes security patching, dependency upgrades, light feature work, and the small improvements that keep a product healthy but rarely warrant a standalone project. We are equally willing to hand a project over to an internal team and step back cleanly — a documented handover, including architecture notes and an operational runbook, is included in every build we deliver.

Question 8

How do you price work?

Accepted Answer

Most engagements are scoped as fixed-price phases, which makes the commercial relationship predictable for both sides. For work that is genuinely open-ended — exploratory spikes, ongoing support, and advisory retainers — we use time-and-materials with a monthly cap agreed up front. Every proposal sets out the assumptions behind our estimate, the definition of done for each phase, and how change control works when scope shifts. We would rather raise a change request and discuss it openly than quietly absorb drift and surprise the invoice.

Question 9

Where are you based?

Accepted Answer

We are a remote-first team and work with clients internationally, across Europe and further afield. Most of our work happens over shared repositories, scheduled calls, and written documents. When an on-site session genuinely helps — an initial discovery, a cross-team workshop, a critical release — we are happy to travel. Clients rarely need to travel to us. We work comfortably across time zones, and agree a core overlap window at the start of each engagement so nothing gets stuck waiting on a reply.

Thequestionspeopleaskusmost

Engagements

Delivery and collaboration

Support and commercial

Still have a question?