The company thesis, and the evidence behind it
AxplusB Tech is one engineering platform with two ways of monetising it: three products we built on it, and a delivery business that applies it inside enterprises. The hypothesis is that the platform compounds — that each product and each engagement makes the next one cheaper and faster to build. That is a claim to be tested, and this page publishes the evidence that exists rather than the evidence we would like to have.
What is not on this page
No revenue figures, customer counts, retention data, market sizing, forecasts, or fundraising ask. None of those is established by a source we can cite publicly, and placing an illustrative number here would make it harder, not easier, to evaluate the company. Product subscription and usage revenue, services revenue, and pipeline are tracked and reported separately so that one is never mistaken for another.
One platform, two routes to market
How the company is put together
One engineering platform underneath. Three products and one delivery business built on it. Applied research feeds the platform, and permitted, general learning from delivery feeds back.
Bahulam
AI work platform
CoDash
BI analysis, migration, and reporting
OneAdmin
Enterprise administration
Your internal product
Built with our engineers
The AxplusB engineering platform
- Agent engineering
- Domain modelling
- Evaluation and validation
- Review and authority
- Delivery and operation
Applied research and evaluation
Feeds the platform. Receives permitted, general learning back from delivery.
- Shared: the engineering platform — agent engineering, domain modelling, evaluation, and review patterns — plus the team that applies it.
- Independent: each product is bought, deployed, and operated on its own terms.
- Not claimed: Platform here means shared engineering capability, patterns, and know-how — evidenced by three products built with them. It is not a claim that Bahulam, CoDash, and OneAdmin share authentication, a common runtime, or interoperable product state. Each is deployed and operated on its own terms, and any integration between them is scoped in an engagement rather than assumed.
The products prove the platform works and carry it into a market. The delivery business applies it inside enterprises and generates validated product requirements in return. Neither route stands alone as the whole thesis.
- BahulamEngineering leaders, builders, and teams adopting AI workflows
- CoDashHeads of BI, analytics modernisation, and data platform teams
- OneAdminBI and EPM administrators, IT operations, and governance leaders
Public here, private under access control
Public evidence should be directly readable. Sensitive material is shared by the company owner through a controlled process — not placed in public static assets and protected by a `noindex` tag.
| Topic | Public treatment | Private material |
|---|---|---|
| Company and ownership | The registered entity, the product relationships, and who is accountable for each product. | Incorporation and ownership records, IP assignments, cap table, and contracts as appropriate. |
| Market and focus | The customer problems we work on and the buyer segments we start from. | Sourced market sizing with its assumptions, pipeline evidence, and customer interviews. |
| Product traction | Only permissioned, dated facts. Today there are none to publish. | Paying and active customers, pilot status, retention and cohort data, concentration, and usage definitions. |
| Revenue composition | That there are two categories — product subscription and usage, and services — and that they are measured separately. No totals. | Product recurring revenue, project revenue, recognised versus contracted amounts, and services backlog. |
| Economics | What we measure and how delivery work is intended to become repeatable product capability. | Model and infrastructure cost of goods, gross margin by stream, support load, and delivery effort against reuse. |
| Defensibility | Domain assets, evaluation practice, and the components that serve more than one delivered task. | IP and dependency inventory, licensing, comparative evidence, and switching and retention evidence. |
| Roadmap and funding | Dated milestones and the capability expansion they unlock. | Resource plan and use of funds, hiring assumptions, dependencies, and downside cases. |
Claims we intend to earn
We are not describing these as differentiators yet. Each one names the proof that would have to exist first. An internal implementation is not automatically novel research, and a transient benchmark advantage is not a moat.
- Research translated into useful workflows
- A research or engineering note linked to a shipped behaviour and its measured result.
- Domain depth
- Real parsers, semantic models, migration exceptions, operation scopes, and validation a customer recognises.
- Reviewable agent work
- Demonstrated artifacts, the checks that ran, approvals where the product supports them, and recorded outcomes.
- Reusable platform capability
- Evidence that a component or pattern served more than one delivered task, with the measured maintenance or delivery benefit.
- Enterprise delivery expertise
- Named accountable team members, approved delivery references, runbooks, and handover evidence.