Skip to main content
Agentic Online

From idea
to impact.

A disciplined path from discovery to delivery.

See how we work

Phases

What happens, and what you receive

Not every engagement uses all nine — a support takeover starts at phase nine, an advisory piece may stop at phase two. The sequence is what does not change.

Our delivery method is published in full: what each phase produces and, stated explicitly, the failure it exists to prevent. We are a new company, so this is what you can check instead of a track record. Hold us to it.

Discovery and problem definition

Establish what problem is being solved, and for whom.

We start with the people doing the work, not the technology. That means observing the current process, identifying where time and errors actually accumulate, and separating the stated request from the underlying problem. We also establish what success would look like in measurable terms, and whether the problem is worth solving with software at all.

The failure this prevents: Building a well-engineered solution to the wrong problem — the most expensive failure in software, and the hardest to detect early.

You receive

  • Problem statement agreed with the people affected by it
  • Current-process map with the cost and failure points identified
  • Success measures defined before any solution is designed
  • Constraints register: regulatory, technical, commercial and organisational
  • Recommendation on whether to proceed, buy a product, or stop

Requirements and solution design

Turn the agreed problem into testable requirements and a design.

Requirements are written as statements that can be verified, not as descriptions of intent. The solution design covers data model, integration points, non-functional requirements and the decisions we are consciously making — including the options rejected and why. Where AI is involved, we specify its behaviour, its boundaries and what happens when it is uncertain or unavailable.

The failure this prevents: Ambiguous requirements that appear agreed until acceptance, when each party discovers the other read them differently.

You receive

  • Requirements and acceptance criteria written as testable statements
  • Solution and data architecture, with integration contracts
  • Non-functional requirements: availability, performance, recovery, accessibility
  • Architecture decision records covering options considered and rejected
  • Estimate and delivery plan with the assumptions stated

Prototype or proof of concept

Answer the riskiest open question before committing to build.

Where a material uncertainty remains — whether extraction is accurate enough on your documents, whether an integration is feasible, whether users will accept the interaction — we build the smallest thing that answers it. A proof of concept has a defined question, a pass/fail threshold agreed in advance, and a stated end date. We are explicit that it is not production software.

The failure this prevents: Discovering a fundamental feasibility problem after the budget is committed — and the related failure of a prototype quietly becoming the production system.

You receive

  • Working prototype addressing the specific uncertainty
  • Measured result against the threshold agreed in advance
  • Recommendation to proceed, adjust the approach, or stop
  • Revised estimate informed by what the prototype revealed

Security and architecture review

Establish the security position before code depends on it.

We threat-model the design, decide how data is classified, stored, transmitted and retained, and define identity, access and secrets handling. For AI systems this is where we set the data boundary, scope what tools an agent may call, and design prompt-injection containment. Findings are addressed in the design rather than logged as future work.

The failure this prevents: Security treated as a late review, when the cheapest fixes are already architecturally unavailable.

You receive

  • Threat model with prioritised findings and design responses
  • Data classification, residency and retention decisions
  • Identity, access and secrets management design
  • AI-specific controls: data boundaries, tool scoping, output validation, injection containment
  • Evidence pack structure agreed for later audit or assessment

Agile implementation

Build in reviewable increments you can use before completion.

Work proceeds in short iterations against a backlog you prioritise. Every increment is demonstrable, deployed to an environment you can reach, and covered by tests that run in the pipeline. Progress is visible as working software rather than as percentage complete, and change is handled through an explicit process rather than absorbed silently until the schedule breaks.

The failure this prevents: Progress that is reported but not demonstrable, and scope creep absorbed until it surfaces as a missed date.

You receive

  • Working software deployed to a reviewable environment each iteration
  • Prioritised backlog you control, updated in the open
  • Automated tests written alongside the code, running in CI
  • Iteration reviews with demonstrations, not status reports
  • Change log recording scope changes, their cost and their approval

Testing and quality assurance

Verify the system against the criteria agreed in phase two.

Testing is layered: unit tests for logic, integration tests for the boundaries where systems actually fail, end-to-end tests for the journeys that matter, and automated accessibility checks. AI components are evaluated against a curated test set measuring accuracy, refusal behaviour and regression between changes. Acceptance is against the written criteria, not against a demonstration.

The failure this prevents: A system that passes a demonstration but fails on real data, real load, or with assistive technology.

You receive

  • Automated test suite in the pipeline: unit, integration, end-to-end, accessibility
  • Evaluation results for AI components, including refusal and regression behaviour
  • Accessibility conformance review against WCAG 2.2 AA with remediation notes
  • Performance verification against the agreed budgets
  • Acceptance record mapped to the criteria agreed at design

Deployment and change management

Put the system into service without disrupting the work it supports.

Deployment is automated, repeatable and reversible, with health checks and a tested rollback. The organisational side matters as much: the people whose work changes need training, documentation and a route to raise problems. Where a manual process is being replaced, we run both in parallel until the new one is trusted rather than switching on a date.

The failure this prevents: A technically successful deployment that fails in practice because the people affected were not prepared, or because there was no way back.

You receive

  • Automated deployment pipeline with health checks and tested rollback
  • Cutover plan, including parallel running and the criteria for retiring the old process
  • User documentation and training for the people whose work changes
  • Support route defined and communicated before go-live
  • Post-deployment verification against the acceptance criteria in production

Monitoring and ongoing improvement

Know how the system behaves in production, and act on it.

Monitoring is designed around user-visible behaviour, not only server health: errors, latency on the journeys that matter, and the measures defined as success in discovery. For AI components we continue measuring accuracy and refusal rates against a maintained evaluation set, because model behaviour and input distributions both drift over time.

The failure this prevents: Silent degradation — a system that still runs but no longer performs as designed, and AI behaviour that drifts without anyone measuring it.

You receive

  • Monitoring and alerting tied to service-level objectives
  • Dashboard covering the success measures agreed at discovery
  • Continuing evaluation of AI components against a maintained test set
  • Periodic review of incidents, usage patterns and improvement opportunities
  • Prioritised improvement backlog maintained with you

Maintenance and support

Keep the system healthy, and keep you free to leave.

Ongoing ownership covers patching, dependency currency, backup verification, capacity review and incident handling under response targets agreed in writing. Equally deliberate is the exit: source code, infrastructure definitions and documentation are yours throughout, and a documented handover is available on request rather than as a negotiation.

The failure this prevents: Dependence on a single supplier — including us. A client who cannot leave is a client who is not being served well.

You receive

  • Support model with agreed response and resolution targets
  • Patching and dependency currency schedule, security updates prioritised
  • Verified backups and tested restore procedures
  • Periodic service review covering incidents, risks and recommendations
  • Handover documentation kept current, so transition is available at any time

Programme governance

Six things we manage across every phase

Phases describe sequence. These describe control — and they are where most engagements actually succeed or fail.

Risk

  • Risks recorded with owner, likelihood, impact and a mitigation — not as a list of worries
  • The riskiest assumption is tested first, in a prototype, rather than deferred
  • Every increment leaves a working system, so risk does not concentrate at a cutover
  • Rollback defined and tested per release, not only for the programme as a whole

Scope

  • Acceptance criteria written as testable statements before build begins
  • Change requests priced and approved in writing, never absorbed silently
  • Backlog priority owned by you; sequencing recommendations owned by us
  • Explicit out-of-scope list, because what a project excludes is as important as what it includes

Quality

  • Automated tests written with the code and run in the pipeline on every change
  • Definition of done includes tests, documentation and accessibility, not just working code
  • Code review on every change, with architecture decisions recorded
  • Performance and accessibility budgets treated as acceptance criteria

Security

  • Threat modelling during design, with findings answered in the architecture
  • Least-privilege access and managed secrets from the first environment onwards
  • Dependency, secret and container scanning automated in CI
  • AI-specific controls: data boundaries, tool scoping, output validation, injection containment

Cost

  • Estimates state their assumptions, so a changed assumption explains a changed number
  • Discovery and proof of concept offered at fixed fee, so the first commitment is bounded
  • Running costs modelled before build, including model inference and infrastructure
  • Spend reported against plan at each review, with variance explained rather than reported

Stakeholder expectations

  • Demonstrations of working software instead of percentage-complete reporting
  • The people whose work changes are involved from discovery, not consulted at training
  • Bad news delivered early, when there are still options
  • One named point of accountability for the engagement, not a rotating contact
We do not publish generic service-level figures on this page. Response and resolution targets belong in your agreement, sized to your actual service, rather than in marketing copy that commits us to nothing.

Getting started

The first two weeks

Almost every engagement starts the same way, deliberately: with the smallest commitment that produces something useful to you whatever happens next.

  1. A conversation, at no cost

    Thirty minutes on the problem. If we are not the right people, we say so and suggest what kind of supplier is.

  2. A fixed-fee discovery sprint

    One to two weeks observing the process, defining the problem, agreeing success measures and costing the options. Indicatively S$8,000 to S$18,000, agreed in writing before it starts.

  3. A decision you can actually make

    A problem statement, a recommended approach and a costed plan — yours to keep, and to take to another supplier if you prefer.

Start with the smallest useful step

A fixed-fee discovery sprint gives you a defined problem, a recommended approach and a costed plan. You keep all three whether or not we build anything.

We reply to every enquiry within one business day.

Request a consultationRead our FAQs