Software, AI and data

The main drivers are the state of your data, the number of systems to integrate, how accurate the system must be, and how much human review the process needs. Running costs matter too: model usage, hosting and monitoring. We estimate after a short discovery, separate build cost from running cost, and show how running cost changes with volume so there are no surprises later.

Read more: AI developmentLink to this question

Build cost depends on the number and state of your sources, the integrations and permissions involved, and how strict the accuracy bar is. Running cost depends on usage, the model chosen, how much text is sent with each request and caching. We estimate both, and we show how a smaller model or better retrieval can bring the running cost down.

Read more: Generative AI and LLM integrationLink to this question

The main drivers are the state and accessibility of your data, whether labels exist or must be created, how many systems the model must connect to, and the level of explanation and documentation your regulators expect. Running costs depend on prediction volume and whether results are needed in real time or in batches. We estimate once the data review is done.

Read more: Machine learningLink to this question

Build cost depends on the number and complexity of sources, how clean they are, and how many subject areas and reports are in scope. Running cost depends on data volumes, refresh frequency and query patterns. We estimate both, design to control compute spend, and set up cost monitoring so usage does not grow unnoticed.

Read more: Data engineering and analyticsLink to this question

The number of document types and layouts, the quality of the scans, how many validation rules and systems are involved, and the volume processed. Running cost depends on volumes and the extraction services used. We estimate after testing a sample of your documents, and we show the expected share of documents that will still need a person.

Read more: Intelligent automation and document AILink to this question

Scope is the main driver: how many user roles, workflows and screens, how many systems the software must connect to, and how strict the security, audit and availability needs are. The state of your data and the number of people who must approve decisions matter too. We estimate after discovery, from a prioritised backlog, so you can choose what goes into the first release and what waits.

Read more: Custom software developmentLink to this question

The number of user roles and workflows, the integrations behind the application, the languages and layouts it must support, and its security and audit needs. Design depth matters too: a tool for a small internal team needs less than a public portal your clients rely on. We estimate from the backlog after discovery, so you can decide what goes into the first release.

Read more: Web applicationsLink to this question

The number of journeys and screens, whether you need a native app for each platform or one cross-platform app, the back-end work, and the security the app needs. Offline use, payments, device features and the range of devices to support add effort. Store releases and keeping up with new operating system versions are ongoing costs to plan for.

Read more: Mobile appsLink to this question

The number of applications and environments, how far they are from automated deployment today, the compliance controls you must meet, and whether workloads move between providers or out of your own data centre. Ongoing operation is a separate decision: we can run the platform with you, or hand it over once your team is ready.

Read more: Cloud and DevOpsLink to this question

Often, but we will not promise a figure before we have looked. Common savings come from resources nobody uses, oversized instances, storage that never expires and environments that run when nobody is working. We tag spending by team and service first, so savings are measured rather than guessed, and we rank what we find by effort and risk.

Read more: Cloud and DevOpsLink to this question

The number of applications and journeys in scope, how testable the current code is, the state of your test data and environments, and how many integrations need simulating. An older application without stable test hooks takes more effort than a new one built with testing in mind. We start with the highest-risk journeys, so the value arrives early.

Read more: QA and test automationLink to this question

The number of user groups and journeys, how much research is needed, whether a design system already exists, and how many platforms and languages the design must cover. Redesigning an established product with many screens takes more than designing a focused new tool. We scope design in stages, so you can review the findings and flows before committing to the full interface.

Read more: UX and UI designLink to this question

The size and complexity of the old system, the quality of its data, the number of systems that depend on it, and how much must change rather than be kept. Old languages and databases that few engineers know add effort. Because the work is incremental, you can fund it in stages and see each stage’s result before approving the next.

Read more: Legacy modernisationLink to this question