Our approach
Understand. Design. Build. Operate.
Every engagement passes through four stages. Each one closes with a deliverable your team can examine and retain: an agreed problem statement, an architecture with acceptance measures, software that has passed its tests, and a handover with a plan for running it.
Public authorities and companies go through the same four stages, whether in Malaysia or in Europe.
Four stages
From the first workshop to a system in production
Every stage names its deliverable and the part your team plays.
Understand
We look at the business problem, the people affected and the systems you run today, and we settle with you whether AI is the right tool at all.
Main activities
- Interviews with the staff who handle the work now
- A review of systems, data access and limits
- An early view of risk, personal data and AI Act class
- A short list of options and the measures for each
Deliverable
- Agreed problem statement
Your part
Give us the background, introduce us to the right colleagues and say what matters most.
Design
We select an architecture, fix the acceptance measures and plan the first release, including how quality, security and human oversight will be evidenced.
Main activities
- Design of the architecture and integrations
- An evaluation plan: test sets and quality criteria for the AI
- Design for security, personal data and human oversight
- Release plan and team composition
Deliverable
- Architecture and acceptance measures
- Plan for the first release
Your part
Approve the measures and priorities, and confirm choices on data, hosting location and oversight.
Build
We deliver in short increments that you can see and use, and every change is reviewed by a second engineer, tested and documented when it lands.
Main activities
- Each increment shown on running software
- Automated tests, code review and security scans
- AI output measured against the agreed criteria
- Documentation kept in step with the code
Deliverable
- Software that has passed its tests
- Evaluation report
Your part
Look at each increment, try it with real users and give formal acceptance for what is ready.
Operate and improve
We hand the system over or run it ourselves, watch it in production and improve it together with you on the evidence of real use.
Main activities
- Tracking of quality, cost and response time
- Review of uncertain and escalated cases
- Runbooks and knowledge transfer to your staff
- Improvement releases on an agreed schedule
Deliverable
- Handover and plan for operation
Your part
Take ownership of the system or agree who operates it, and choose the next improvements.
After that the cycle begins again: what the system shows in operation decides what the next round covers.
Collaboration
Working with your teams
A single team with common goals, progress you can see and every decision on file.
A single accountable lead
One delivery lead is answerable to you for scope, quality and progress, with architects and specialists added when the work calls for them.
Mixed team, single backlog
Your specialists and ours share one backlog. You and we set priorities together, and every change is visible to all of us.
A fixed rhythm
Short planning cycles, demonstrations on running software and scheduled reviews bring problems to light early instead of at the end.
Decisions written down
We record architecture and design decisions with the reasoning behind them, so anyone can review, explain or inherit them later.
Governance
Named owners, open risks and change under control
A steering group that decides
A small steering group meets on a fixed schedule and decides on scope, priorities and risks. Escalation paths are settled at the outset, before anyone needs one.
Risks kept visible
One register holds risks, dependencies and assumptions, each with a named owner, and the steering group reviews it at every meeting.
Governance for AI
For each AI system we record its intended purpose, risk class, data sources and the decisions that remain with an accountable officer, in line with the EU AI Act duties of providers and deployers and with Malaysia’s voluntary AI governance guidelines.
Change under control
A change to scope, data or model behaviour follows an agreed change procedure that states its effect on cost, quality and compliance.
Quality assurance
AI is tested as strictly as the rest of the software
We engineer software quality and AI quality side by side, starting with the first increment.
Automated tests
Unit, integration and end-to-end tests run in the delivery pipeline on every change, and one failed test blocks the release.
Peer review and security scans
A second engineer reviews each change before release. Scans of dependencies, code and infrastructure run automatically, and each release has its own security test plan.
Accessibility tests
We check interfaces against WCAG 2.2 level AA, with automated tools and with manual sessions using assistive technology.
Measuring AI output
You and we agree the quality criteria and test sets, and we measure AI output against them before go-live and throughout operation. Where the system is not confident, a person makes the call.
The evaluation cycle we set up with you for each AI feature. Criteria, thresholds and review steps differ by use case.
Read the diagram as text
The drawing shows a cycle of five steps.
Step 1, criteria and test set: your specialists and we agree quality criteria and a set of real examples. Step 2, measure before go-live: the AI output is scored against those examples and criteria. Step 3, release approved by a person: you review the results with us and decide whether the feature is switched on. Step 4, watch in production: quality, cost and response time are tracked during real use. Step 5, handle uncertain cases: staff take the cases the AI cannot resolve with confidence.
What staff decide in step 5 is added to the test set of step 1, so every new round of evaluation builds on real use.
Documentation and handover
Your organisation keeps the knowledge as well as the code
We plan the handover from the first week, so your staff can operate and change what we deliver.
Architecture documentation
Up-to-date diagrams and descriptions of the components, integrations and data flows, revised whenever the system changes.
Decision records
The reason for each major choice, the options set aside and the conditions under which we would reopen it.
Runbooks and plan for operation
How the system is deployed, monitored, restored and supported, and who is responsible for each task after go-live.
Knowledge transfer
Pair work, walkthroughs and handover sessions with the team that will own the system, held throughout the engagement instead of in the last weeks.
Delivery teams
Teams formed from 2,400+ people
Our teams combine skills from 2,400+ people in AI engineering, software development, cloud, data, integrations and the Salesforce, SAP and Odoo practices. A team begins small during discovery and grows as the work grows, up to a complete programme.
We try to keep the same engineers with you from design to handover, because continuity is what makes a system last. The team composition, and how it works with your own staff, is agreed for each engagement.
- What we offerThe services our teams come from.
- Enterprise platformsOur practices for Salesforce, SAP and Odoo.
Public sector
Working with public authorities
600+ government projects for public authorities in EU Member States, some completed and others still running, have taught us how tender phases, procurement rules and their documentation fit into a delivery plan.
For a public-sector reader in Malaysia, that experience translates into one habit: accessibility, security, protection of personal data and support for more than one language are settled in discovery and design, not left for the final tests. We record decisions so they can be explained to auditors, oversight bodies and the public.
- Public sectorWhat we design for public authorities and statutory bodies.
Malaysia
Delivery that takes Malaysian and EU rules into account
A Malaysian organisation usually meets its own rules first: the Personal Data Protection Act 2010 (Act 709), whose amendments came into force in stages from 1 January to 1 June 2025, and, for NCII entities, the Cyber Security Act 2024 (Act 854) in operation since 26 August 2024. Financial institutions add the revised Risk Management in Technology (RMiT) policy document of Bank Negara Malaysia (BNM), in effect since 28 November 2025.
Groups that sell into the EU or run companies there may also meet the EU AI Act, the EU General Data Protection Regulation (GDPR) and the Cyber Resilience Act. We address both sets of rules in the Understand and Design stages, so they shape the architecture rather than hold up go-live. The plan records where the rules differ, and your counsel gives the legal interpretation.
- Personal Data Protection Act 2010 (PDPA)Personal Data Protection Act 2010 (Act 709), as amended by the Personal Data Protection (Amendment) Act 2024 (Act A1727): data protection officer, breach notification, data portability (opens external site)
- Cyber Security Act 2024Cyber Security Act 2024 (Act 854): National Critical Information Infrastructure duties and licensing of cyber security service providers, administered by NACSA (opens external site)
- BNM Risk Management in Technology (RMiT)Risk Management in Technology (RMiT), policy document of Bank Negara Malaysia for financial institutions (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)
Common questions about our way of working
How long does a stage last?
That depends on the scope, the systems in play and how fast decisions can be taken. We plan each stage with you at its start and report progress at every step. We give no durations before we understand the problem.
Is it possible to begin with something small?
Yes. Many engagements begin with the Understand stage alone, or with one use case taken through all four stages, before they grow. Each stage closes with a deliverable you can use, even if you then decide to stop working with us.
What does our organisation retain at the end?
You receive the documentation, decision records and runbooks your staff need to operate and change the system, and the handover is planned from day one. The contract for each engagement sets out who owns the code and the intellectual property.
How do you check that AI output is reliable enough?
Your specialists and we agree quality criteria and test sets, we evaluate before go-live and we continue measuring in production. A person handles every uncertain case. We report the evaluation results and make no promise of an accuracy percentage.
Can you work with our in-house teams and other vendors?
Yes. Mixed teams and work next to other vendors are common for us. Defined interfaces, one shared backlog and written decisions keep each party’s responsibilities clear.
Do you follow public procurement rules?
In the EU, yes: our 600+ government projects for public authorities in EU Member States include tender procedures and the documentation those procedures demand. Public buyers expect a response that answers every requirement of the tender, and that is how we write for public authorities in the EU. Contact us with the tender details and the right colleagues will look at it.
Begin with the problem
Describe what you want to achieve and the systems you run today. We will propose the stage to begin with and what you would hold at its end.