Skip to main content

How we work

Discover. Define. Design. Engineer. Validate. Launch. Evolve.

Two things govern every engagement. The philosophy is the CLARITY Method — the Veda group’s discipline of putting the business problem before the technology. The execution model is a seven-stage software lifecycle that carries a requirement from first conversation through to long-term evolution, with a decision gate at the end of every stage.

The thinking discipline

CLARITY puts the business problem before the technology.

CLARITY is the Veda group’s method, shared across the ecosystem: Veda AI helps organisations identify and prioritise the right opportunity. Veda Flow makes workflows and dependencies visible. Veda Software engineers and delivers the technology.

On a software engagement, CLARITY is why we ask about margins before we ask about features — and why the commercial reason comes before the recommendation, every time.

The CLARITY Method at Veda AI
  1. C

    Capture

    Map how the business actually works today — not how the org chart says it does.

  2. L

    Locate

    Pinpoint where time, money, capacity or control is being lost.

  3. A

    Analyse

    Size each loss and find its root cause, so priorities are commercial, not cosmetic.

  4. R

    Recommend

    A short, sequenced plan — including the honest option of not building anything.

  5. I

    Implement

    Build the fix that fits how the business actually runs.

  6. T

    Translate

    Land the change with the people who have to live with it.

  7. Y

    Yield

    Measure what improved, and decide what earns attention next.

The lifecycle

Seven stages, each ending in a decision.

Every stage produces something you can hold — notes, a specification, recorded decisions, a working release — and ends with a gate: an explicit decision to continue, change course, or stop.

Stages get skipped when a deadline shouts louder than the requirement. It always costs more later. We hold the sequence because it protects your money, not our process.

  1. 01

    Discover

    We sit with the people who own the problem — and the people who live with it. We map the current systems, data, constraints and commercial context before anyone talks about features.

    You receive
    Discovery notes — a written record of the problem, the constraints, the systems involved and the risks we can already see.
    Stage gate
    Agreement on the problem worth solving. If the honest answer is that software won’t fix it, we say so here.

    If this stage is skipped: Projects scoped from assumptions build the wrong thing confidently. Most failed builds fail at this stage — before a line of code exists.

  2. 02

    Define

    We turn discovery into a written specification: what the system must do, for whom, in what order — and what is explicitly out of scope.

    You receive
    A written specification with priorities and acceptance criteria — the document all build work is measured against.
    Stage gate
    Scope sign-off. Nothing is engineered until what “done” means is agreed in writing.

    If this stage is skipped: Without a specification, scope gets negotiated mid-build — the most expensive place to have that argument.

  3. 03

    Design

    Architecture before implementation. We decide the data model, integrations, security posture and technology choices — each with a commercial reason attached, not a preference.

    You receive
    Architecture decisions, recorded and explained in plain language, so the reasoning outlives the people who made it.
    Stage gate
    Architecture review and approval. Technology choices are challenged here, while changing them is still cheap.

    If this stage is skipped: Structural mistakes discovered during build cost multiples of what they cost on paper.

  4. 04

    Engineer

    We build in staged, reviewable releases under version control, with separate environments for development, testing and production. A senior engineer reviews every release before it moves forward.

    You receive
    Staged releases you can see and use as they land — working software at intervals, never a reveal at the end.
    Stage gate
    Each release is reviewed and accepted before the next begins.

    If this stage is skipped: Long silences followed by a big reveal are how projects drift months off course without anyone noticing.

  5. 05

    Validate

    QA and testing are deliverables here, not afterthoughts: functional testing, edge cases, performance and security checks — with fixes made before launch, not logged for later.

    You receive
    Test evidence — what was tested, what was found, and what was fixed.
    Stage gate
    Agreed readiness for launch, based on evidence rather than optimism.

    If this stage is skipped: Skip validation and your users become the test team — on live data, at the worst possible moment.

  6. 06

    Launch

    A controlled release: launch plan, data migration where needed, a rollback path, monitoring in place, and handover to your team with documentation shipped alongside the system.

    You receive
    A launch plan, documentation, and a system live in accounts you own.
    Stage gate
    Stable in production, with your ownership of the codebase and accounts confirmed.

    If this stage is skipped: Unplanned go-lives turn small issues into outages. A rollback path is cheap insurance — and it can only be bought in advance.

  7. 07

    Evolve

    Software earns its keep after launch. We monitor the system, keep dependencies current, and steer a roadmap based on how it is actually used — long-term product evolution, not fire-and-forget delivery.

    You receive
    A living roadmap — what comes next, why, and what it should achieve.
    Stage gate
    This stage doesn’t close. It is reviewed at agreed intervals — or handed over cleanly to your in-house team.

    If this stage is skipped: Unmaintained software decays quietly: dependencies age, risks accumulate, and every future change costs more than it should.

Working agreements

Six agreements, on every engagement.

These are the working defaults, not negotiable extras. They exist because software projects fail on control and communication far more often than they fail on code.
  1. 01

    Written specifications before build

    You approve what will exist before it costs anything to exist.

  2. 02

    Staged, reviewable releases

    Working software at intervals you can inspect — never a black box.

  3. 03

    You own the codebase and the accounts

    Repositories, hosting, domains and data sit in your name from day one.

  4. 04

    Senior review on every release

    Nothing ships without senior technical accountability behind it.

  5. 05

    No surprise scope

    Changes are priced and agreed in writing before the work happens.

  6. 06

    Honest recommendations

    Including “don’t build this” when that is the truthful advice.

Who’s in the room

Senior people, start to finish.

  1. 01

    Senior-led delivery

    The engineers who scope your work are the engineers accountable for delivering it.

  2. 02

    Direct access

    You talk to the people building your system — no account-manager relay in between.

  3. 03

    No sales-to-delivery handover

    The team you meet at discovery is the team in the room at launch.

Common questions

How we work, answered.

It depends on the scope, and we won’t pretend otherwise. For most engagements discovery is short and time-boxed — its length and cost are agreed with you before it starts, and it ends with written notes and a clear recommendation either way.

Start the lifecycle

Bring us the problem. We’ll bring the discipline.

Every engagement starts at Discover — a conversation about the problem, not a pitch about technology.