Depth D1 · Questions

Questions before you hire us

The questions a buyer asks a new supplier, answered in writing. Questions about one service line, one sector or the contact form are answered on that page and listed at the end of this one with a link.

Working together

How does a first project with you start?

With an email describing the problem. We reply with the questions we need answered, then send a written scope: what we will do, what we need from you, what we will hand over and how it will be checked. Work starts when you accept that scope in writing.

Link to this answer
Do we need to know which service line we need before we write?

No. Describe the symptom, such as pages missing from search, a slow checkout or a process that takes too many hands. We place it on the depth scale and tell you which line it belongs to, or that it belongs to none of them.

Link to this answer
Can one engagement cover more than one depth?

Yes, when the problem runs through more than one layer. A slow site can be a front end issue at 14 and a database issue at 20. We scope each depth as its own item so you can approve them separately.

Link to this answer
Do you work in time zones outside the UK, and in which language?

Yes. Most of the work is written and asynchronous: tickets, pull requests and reports. For calls we agree a fixed overlap window with your team at the start. Every document, code comment, ticket and call is in English.

Link to this answer

Scope and pricing

How do you price the work?

A scoped project gets a fixed price for the written scope. A retainer and an embedded arrangement are priced per month for an agreed amount of time. We do not publish prices, because they depend on the scope, and we give the price in writing before any work starts.

Link to this answer
What does the smallest engagement look like?

A scoped review of one part of your stack, such as a crawl and index audit or an access review. It has a fixed price, ends with a written finding you keep, and carries no obligation to continue with us.

Link to this answer
What happens if we are not happy with the work?

You tell us against the scope, which states how each deliverable is checked. We fix what fails that check before the stage is closed. Work runs in stages you approve one at a time, so you can stop after any stage and keep everything delivered up to that point.

Link to this answer
What happens if a project goes wrong?

We tell you as soon as we know, in writing, with what went wrong and what we propose. Because work is split into small reviewed stages, a problem usually affects one stage rather than the whole project. If we cannot deliver what the scope says, we say so instead of shipping something weaker under the same name.

Link to this answer

Ownership and access

Who owns the code, the accounts and the documents we produce together?

You own all of it. Repositories, cloud and tool accounts are created in your name, and every document we write is handed over in a format you can edit. Our access is granted by you and can be withdrawn by you.

Link to this answer
What access do you need, and how is it removed?

Each person gets their own named account with the least access the work needs, never a shared login. Secrets are kept in a password manager or secrets store, not in email or chat. At the end of the work we list every access we held so you can remove it, and we confirm in writing once it is gone.

Link to this answer
Will you sign our NDA before we share details?

Yes. We sign a reasonable mutual or one way non-disclosure agreement before you share anything confidential, and we can send our own if you do not have one.

Link to this answer

Security and data

What do you do with our data?

We process it only for the work in the scope, inside the systems you give us access to. Production data is not copied to our machines unless the scope requires it, and then only as a reduced or masked extract. When the work ends we delete what we held and confirm it in writing. Personal data is handled under the UK GDPR and the Data Protection Act 2018; the privacy policy sets out the rest.

Link to this answer

AI specifically

Do you use AI tools on our code and documents?

Only with your written agreement, and only tools whose terms exclude training on your inputs. The tools are named in the scope. Every AI assisted change goes through the same human review as any other change before it is merged.

Link to this answer
Who is accountable when a model gets something wrong?

We are, for the system we built, and it is designed for that case. Answers carry their sources, uncertain cases go to a person, and an evaluation set catches regressions before release. When a wrong answer reaches a user, we log it, add it to the evaluation set and fix the cause, and the change record shows what was done.

Link to this answer

After launch

What happens after handover?

You receive the code, the accounts, the runbooks and the list of every access we held. Support after that is optional: a retainer with response arrangements written into the contract, or nothing at all. The work is documented so that another team can take it over without us.

Link to this answer
What do you not do?

We do not resell software licences, take commissions from vendors, give legal advice or run paid advertising. We do not start work without a written scope, and we do not keep access after the work ends.

Link to this answer

Answered on other pages

Each of these has one answer, on the page it belongs to.

Ask the question that is not here

Write it down as plainly as you would ask it in a meeting. We answer in writing.

Ask your question

A written reply, no call needed.