FREQUENTLY ASKED QUESTIONS

Do we need our processes documented before we start?

No. If your processes were accurately documented, you would probably have resolved much of this already. Discovery exists to establish what actually happens, which is generally different from what is recorded.

How long does a first engagement take?

Discovery is measured in weeks rather than months, depending on the number of processes in scope and how quickly we can secure time with the people doing the work. A first build depends entirely on the workflow; we give you a duration in the design document, before you commit to it.

What does it cost?

Discovery is a fixed fee against a fixed scope, so the figure is known before you start. Build is priced against the agreed design. Service is a monthly retainer tied to a service level agreement. We give indicative ranges early in the first conversation rather than requiring three meetings to establish whether we are in your bracket.

Will this reduce headcount?

Sometimes a role changes substantially, and we will say so plainly. More often, what we remove is work nobody wanted: re-keying, chasing, reconciling and checking. We address the likely impact openly at Design, because a change programme that surprises the operating team on go-live day rarely survives contact with them.

We already have an internal engineering team. Why appoint us?

In some cases you should not. Where your team has the capacity and the relevant experience, we are better used in an advisory capacity. Where they are fully committed to your own product, we build in a form they can inherit: clean structure, clear interfaces, documented decisions.

What if we want to bring it in-house later?

That is the intended end state for many clients. The build is structured for handover and the documentation is written for that purpose rather than for compliance. We would prefer to run your service because you want us to, not because you cannot extract yourself.

Which AI platforms do you use?

It depends on the workflow: on data sensitivity, accuracy requirements, latency and cost. We are not tied to a single vendor and the reasoning appears in the design document. We keep the technology discussion light in early conversations deliberately — the value lies in the engineering, not in naming whichever framework is prominent this quarter.

Can you work with sensitive or regulated data?

Generally yes, but the constraints shape the design, so raise them early. We would far rather build to a jurisdictional or tenancy constraint from the outset than discover it during testing.

What happens if something fails once it is live?

That is what the service agreement covers: a defined response time, named owners on both sides, monitoring and alerting agreed before go-live, and a roll-back plan. Workflows are designed to fail visibly rather than quietly.

Do you work with smaller organisations?

We work best where there is real operational volume, because that is where re-engineering a process repays the cost of engineering it. If you are unsure whether you are at that point, a first conversation will establish it quickly.