AXPLUSB TECH / SERVICES

    Build an internal product, not a proof of concept that stalls

    The same engineering platform that produced Bahulam, CoDash, and OneAdmin, pointed at your estate — with the engineers who built them. We scope, build, integrate, evaluate, deploy, and hand over an internal AI product, organised around agreed acceptance criteria rather than a list of technology skills.

    What we arrive with

    Not a blank page. The platform behind our own products is the starting point for yours — which is why an engagement begins at your workflow rather than at infrastructure.

    • Agent engineering

      The agent layer of your internal product, built against your workflow instead of a generic template.

    • Domain modelling

      The domain logic your workflow depends on and that nobody ever wrote down, modelled explicitly.

    • Evaluation and validation

      Acceptance criteria agreed before we build, and an evaluation set that tells you whether they were met.

    • Review and authority

      A system your people stay accountable for, with the failure paths exercised rather than hidden.

    • Delivery and operation

      Deployment automation, telemetry, runbooks, and a handover your operators accept.

    The four stages

    Each stage ends in a decision, and each decision can be no. The ranges are planning ranges for a bounded engagement, conditional on access, data, dependencies, and agreed scope — not guaranteed schedules.

    1

    Opportunity and feasibility

    1–2 weeks

    You supply

    • A sponsor and the users who do the work today
    • The workflow as it currently runs, and its baseline measures
    • Access constraints, stated early

    We deliver

    • Opportunity brief and process map
    • Baseline measures and a data and access assessment
    • Architecture options with their tradeoffs
    • A prioritised scope

    The decision this stage exists to answerIs there a valuable, feasible internal product here?

    2

    Validated pilot

    3–6 weeks

    You supply

    • Representative data
    • Reviewer time from the people who will judge the output
    • An approved environment

    We deliver

    • A working vertical slice
    • An evaluation set and the results against it
    • Quality, cost, and latency reported together
    • Integration evidence and the explicit failure paths

    The decision this stage exists to answerDoes the slice meet the acceptance criteria we agreed before building it?

    3

    Production delivery

    Estimated after the pilot, not before

    You supply

    • An environment owner
    • Identity and network approvals
    • The team that will operate it

    We deliver

    • The integrated product and its deployment automation
    • Telemetry and permissions
    • An acceptance report, runbooks, and training

    The decision this stage exists to answerCan the customer operate this within the boundaries we agreed?

    4

    Operate and expand

    Recurring scope

    You supply

    • A service owner
    • Change priorities
    • An incident process

    We deliver

    • Monitoring reviews and evaluation regression checks
    • Improvements against the agreed priorities
    • Knowledge transfer

    The decision this stage exists to answerMaintain, extend, or transition ownership.

    Where engagements usually start

    These are entry points we know how to scope, with the measures we would hold the work to. They are not claims that every workflow is packaged or deployed today.

    Internal knowledge and decision assistant

    Source-grounded answers with references, access boundaries, and an escalation path when the answer is not supported.

    Forward Deployment delivery, using Bahulam capabilities where they fit

    How it is measured

    • Task acceptance rate
    • Unsupported-answer rate
    • Retrieval coverage
    • Review time per answer

    Engineering workflow assistant

    A reviewed patch with tests, linked issue and PR evidence, and automation bounded to the agreed scope.

    Bahulam with scoped Forward Deployment integration

    How it is measured

    • Accepted tasks
    • Regression rate
    • Reviewer time
    • Cost per accepted task

    BI modernisation programme

    An inventory, retire / merge / migrate decisions, and validated native artifacts.

    CoDash with Forward Deployment rollout

    How it is measured

    • Validated assets
    • Exceptions raised and repaired
    • Reconciliation results
    • Effort against the baseline

    Administration review workflow

    A scoped inspection and request-preparation flow, and an authority design that names who decides what.

    OneAdmin with Forward Deployment integration

    How it is measured

    • Evidence completeness
    • Correct routing to the accountable administrator
    • Live execution metrics only once execution is implemented

    How engagements are packaged

    • Fixed-scope discovery
    • Milestone-based pilot and delivery
    • Scoped Forward Deployment capacity, or a support retainer

    Commercial models under validation. The terms of any engagement are set in the engagement documents, not on this page.

    What this page does not promise

    • Product subscriptions, usage, infrastructure, and third-party model costs are separately visible — they are not folded into a delivery fee.
    • Reusable company IP and customer-owned artifacts are defined in the engagement documents before work starts.
    • Planning ranges are conditional on access, data, dependencies, and agreed scope. They are not guaranteed schedules.
    • This page describes how we package delivery. It does not publish staffing capacity, standard pricing, or a delivery history.
    Scope an internal productHow an embedded engineer works