Delivery model
Understand. Design. Build. Run.
Every engagement passes through four stages with a named deliverable at the end of each: a problem statement, an architecture with agreed measures, tested software and a handover with an operating plan. A steering committee, maker-checker controls for AI actions and documented acceptance are part of the model.
One delivery model for Indian enterprises, GCCs and their European subsidiaries, with the same four stages wherever the work sits.
Four stages
Four stages to a system in daily use
Every stage closes with a named deliverable and gives your team a defined part.
Understand
We study the business problem, the stakeholders and the systems in place, and decide with you whether AI is the right answer at all.
Activities
- Interviews with the staff who do the work today
- A look at systems, data access and limits
- Early view of risk, DPDP duties and, where relevant, EU AI Act classification
- A shortlist of use cases with a measure for each
Deliverable
- Problem statement
Your part
Give us context, arrange access to the right people and set priorities.
Design
We select an architecture, define success and plan the first release, including how quality, security and approval steps will be demonstrated.
Activities
- Design of architecture and integrations
- Test plan: test sets and quality thresholds for AI
- Security, privacy and maker-checker design
- Release plan and team composition
Deliverable
- Architecture and agreed measures
- Plan for the first release
Your part
Confirm measures and priorities, and decide on data location, hosting and who approves what.
Build
We deliver short, tested increments you can see and use, with every change reviewed by a peer, tested and documented as it is merged.
Activities
- Increments shown on working software
- Automated tests, code review and security scans
- AI output measured against the agreed thresholds
- Documentation written with the code
Deliverable
- Tested, working software
- AI test results
Your part
Review each increment, try it with real users and formally accept what is ready.
Run and improve
We hand the system over or operate it, monitor it in production and improve it with you, guided by actual use.
Activities
- Monitoring of quality, cost and response time
- Review of doubtful and escalated cases
- Runbooks and knowledge transfer to your team or GCC
- Improvement releases at a fixed rhythm
Deliverable
- Operating plan and handover
Your part
Take ownership or agree who operates it, and choose the next improvements.
The cycle then restarts from what operation has taught us: real use decides the next priorities.
Working together
Working alongside your teams and GCC
A joint team with common goals, visible progress and decisions recorded in writing.
A single delivery lead
One delivery lead is answerable to you for scope, quality and progress, supported by architects and specialists as the work demands.
One team, one backlog
Your specialists and ours work from a shared backlog. Priorities are agreed jointly and every change is visible to all stakeholders.
A fixed cadence
Short planning cycles, demonstrations on working software and regular reviews bring problems to light early, well before go-live.
Decisions in writing
Architecture and design choices are recorded with their reasons, so they can be revisited, explained to auditors and handed over.
Governance
Steering, escalation and change control
A steering committee that decides
A small steering committee meets at a fixed interval and decides on scope, priorities and risks. The escalation matrix is agreed at kick-off, before anyone needs it.
One risk register
Risks, dependencies and assumptions sit in a single register with an owner each, and the steering committee reviews them at every meeting.
Governance for AI
For each AI system we record the intended purpose, the risk review, the data sources and the maker-checker points, with the India AI Governance Guidelines in view and, where output is used in the EU, what the EU AI Act asks of providers and deployers.
Change control
Changes to scope, data or model behaviour follow an agreed change process, with the effect on cost, quality and compliance stated before anyone approves them.
Quality assurance
AI tested like the rest of the system
Software quality and AI quality are handled as one discipline from the first increment.
Automated tests
Unit, integration and end-to-end tests run on every change in the release pipeline, and one failing test blocks the release.
Peer review and security scans
No change ships until a second engineer has reviewed it. Code, dependencies and infrastructure are scanned on every build, and security testing is planned for each release.
Accessibility testing
Interfaces are checked to WCAG 2.2 AA, and to IS 17802 where you need it, using automated tools and manual testing with assistive technology.
Measuring AI output
Quality thresholds and test sets are agreed with your experts; AI output is measured against them before release and continuously afterwards. Where the system is unsure, a person takes the decision.
The test cycle we agree with you for each AI feature. Thresholds, criteria and review steps are set per use case.
Read the diagram as text
The diagram shows a cycle of five steps.
Step 1, criteria and test set: your experts agree quality criteria and a test set built from real cases. Step 2, test before release: AI output is measured against those cases and criteria. Step 3, release decided by a person: you review the results with us and decide whether the feature goes live. Step 4, production monitoring: quality, cost and response time are tracked on live use. Step 5, doubtful cases: staff handle the cases the AI cannot handle with confidence.
What staff decide in step 5 is added to the test set of step 1, so each new round of testing reflects real use.
Documentation and handover
Your team keeps the knowledge as well as the code
Handover planning starts in week one, so your team can operate and change the system on its own.
Architecture documentation
Up-to-date diagrams and descriptions of components, integrations and data flows, revised whenever the system changes.
Decision log
Why each major choice was made, which alternatives were weighed and what would justify reopening it.
Runbooks and operating plan
How to deploy, monitor, restore and support the system, and who is responsible for what after go-live.
Knowledge transfer
Pair work, walkthroughs and handover sessions with the team that will own the system, whether an internal IT team or a GCC, spread over the engagement instead of crowded into the final weeks.
Delivery teams
Teams formed from 2,400+ people
Teams are formed from 2,400+ colleagues across AI engineering, software, cloud, data, integrations and our practices for Salesforce, SAP and Odoo. A team starts small during discovery and grows with the work, up to a full programme.
We aim to keep the same people on your programme from design to handover, because continuity is what lets a system last. Team composition, and the way it works with your own staff or GCC, is agreed for each engagement.
- Services we offerThe services our teams come from.
- Enterprise platformsOur practices for Salesforce, SAP and Odoo.
Public sector
Public-sector discipline
Our approach to public work comes from 600+ projects for European public administrations: tender phases, procurement rules and the documentation they require are part of the plan from the first day.
The same discipline fits Indian public procurement, where the General Financial Rules, 2017 set the framework and GeM and the CPPP carry the process. Accessibility to GIGW 3.0 and data protection under the DPDP Act belong in discovery and design, not in the last test round, and decisions are documented so they can be explained to auditors and citizens.
- Government & public sectorWhat we build for government and the public sector.
India
Indian and EU rules, planned in from the start
An Indian enterprise with European customers or subsidiaries usually answers to two sets of rules at once. At home, the DPDP Act and DPDP Rules bring the Data Fiduciary duties from May 2027, and CERT-In’s Directions require listed incidents to be reported within six hours. In Europe, the EU AI Act can apply when AI output is used in the Union, the GDPR covers offers to people there, and the Cyber Resilience Act sets duties for products with digital elements. We plan for both in the Understand and Design stages, so they shape the architecture rather than delay go-live. The legal reading of each rule stays with your legal advisers.
- DPDP Act 2023Digital Personal Data Protection Act, 2023, also covering processing outside India connected with offering goods or services to Data Principals in India (opens external site)
- DPDP Rules 2025Digital Personal Data Protection Rules, 2025, brought into force in three steps over eighteen months (opens external site)
- CERT-In Directions 2022CERT-In Directions of 28 April 2022 under s. 70B(6) of the IT Act: reporting of listed cyber incidents within 6 hours, log retention, time synchronisation (opens external site)
- EU AI ActArtificial Intelligence Act, Regulation (EU) 2024/1689 (opens external site)
- GDPRGeneral Data Protection Regulation (EU) 2016/679 (opens external site)
- Cyber Resilience ActCyber Resilience Act, Regulation (EU) 2024/2847 (opens external site)
Questions about our delivery model
How long is each stage?
That depends on scope, the systems involved and how quickly decisions are taken. A plan for each stage is agreed at the start, and progress is visible throughout. We give no durations before we understand the problem.
Can we begin with a small engagement?
Yes. Many engagements begin with the Understand stage alone, or take one use case through all four stages before scaling. Every stage leaves a deliverable you can use, even if you choose not to continue with us.
What remains with us afterwards?
You receive the documentation, decision log and runbooks needed to operate and change the system; handover is planned from the start. Ownership of code and intellectual property is set out in the contract for each engagement.
How do you check that AI output is reliable enough?
Quality thresholds and test sets are agreed with your experts, output is tested before release and measured again in production, and doubtful cases go to a person. We report the measured results; accuracy percentages are not promised in advance.
Can you work with our IT team, our GCC and other vendors?
Yes. Joint teams and multi-vendor programmes are common for us. Clear interfaces, one shared backlog and written decisions keep each party’s responsibility visible.
How do you handle public procurement requirements?
Our experience comes from 600+ projects for European public administrations, including tender procedures and the documentation they require. Contact us with the reference of a specific procurement and we will pass it to the right team.
Begin with the business problem
Describe what you are working on and the systems in place. We will propose the stage to begin with and the deliverable you would hold at its end.