#GMMWorks
Plan it. Build it. Support it. Governed at every step.
A governed AI-driven lifecycle for enterprise software, from planning to delivery to production support. Built for banks, insurers and regulated teams who have to show how every change was approved.
The LLM is swappable.The governance is not optional.
Status as of 3 Oct 2026 · v1.1 live on AWS
Design partners & pipeline
- ✓Yethi
- ✓ITC NZ
- →Groupla.online
- ◦PropEnabler.ai
- ◦Octopus Estates
- ◦SolveEasy
Yethi testing in real industry · ITC NZ design partnership signed · Groupla.online onboarding now · PropEnabler.ai, Octopus Estates and SolveEasy in pipeline
AI writes code fast. Enterprises can't ship it.
Coding assistants made one developer quicker. They did not make a delivery organisation safer. A bank, an insurer or a regulated SaaS team still has to answer the same questions before anything reaches production.
- Who approved this? AI output arrives without a decision trail an auditor can follow.
- Does it meet our standards? House rules, security policy and licences are checked by hand, if at all.
- Does it still work together? Work built in parallel passes its own tests and breaks at integration.
- What happens after release? Customer complaints never find their way back to the backlog that caused them.
One governed lifecycle. Three platforms. One board.
A requirement enters GMMPlan and becomes a Jira backlog. GMMCode, our delivery product, builds each story through its gates. GMMDesk handles the users afterwards, and a confirmed defect becomes an approved Jira bug that flows back to the board.
#GMMPlan
Brief, research, architecture, PRD, then epics, stories and estimates, published to Jira. Every story carries its planned integration test.
#GMMCode
A pod of AI specialists builds each story, test-first, through named governance gates, and you approve the decisions that are yours. How GMMCode works
#GMMDesk
Governed L1/L2/L3 support with ServiceNow and Azure DevOps. Production feedback returns to the board as approved Jira bugs.
Governance that respects the spec, and a team that reads it.
Checks judge only what applies
Small governance language models review each artefact against the standards that apply to it. A finding outside the story's scope is not a silent rejection: it becomes a recorded follow-up, filed in Jira and listed to you when the work closes.
Every role decides from full context
The analyst, architect, developer, tester and reviewer each see the customer's own words, the spec, the agreed scope, the ticket history and the conversation so far, so a decision is made on what was actually asked.
It fixes the app, not the test
When tests fail, the developer agent diagnoses the failure from the evidence (logs, test output, the diff) and fixes the application, rather than weakening the test until it passes.
People approve, with the evidence in hand
Change authorisation, plans and UI mockups wait for a person. Each decision page shows the evidence bundle: gate verdicts, test and integration results, SBOM and the follow-ups raised.
Every story passes the same named gates, in order.
This is the gate order for a build. Each gate is decided by a role that did not do the work, and every verdict lands in the evidence bundle.
Design
Architecture and acceptance criteria agreed before code.
Implementation
Built test-first; a red integrated build blocks this gate.
QA, review, security
Three independent checks of the same change.
Scope adherence
Did it build what was asked, and only that?
Release readiness
Deployable, observable, reversible.
Change authorisation
A person approves, with the evidence bundle.
Built for the risk committee, not just the developer.
A pilot starts from your Jira backlog. GMMPlan turns one requirement into stories, GMMCode builds them on your board, and you approve each gate.
- Data residency. For Indian customers the platform can run in the AWS India region.
- Provenance and an audit trail per change. Every verdict records the model, prompt hash, registry version and tool versions, and every change carries its decision trail.
- Human approvals and segregation of duties. Approval policies per decision type, segregation of duties enforced at decision time, quorum groups and escalation.
- Production never bypasses. Dev and test environments can auto-decide approvals, and each such decision is labelled "bypassed".
#GMMWorks builds itself by its own rules.
The platform's own backlog lives in Jira and on its own board. Every change follows the loop it sells: design note, failing test, fix, full suite, checksummed deploy, live check, then the Jira ticket closes.
Status as of 3 Oct 2026. Headline counts are live from the GMMCOD, GMMUI and GMMDSK Jira projects. Integration testing is the newest work and the furthest from done. Progress by area
Built in Bengaluru by people who ran enterprise delivery.
CodeEasy Innovation Labs builds #GMMWorks for enterprises that must show how every change was planned, built, approved and supported.
Run one requirement through #GMMWorks.
Engineering and delivery leaders who run their work in Jira and have to show how a change was approved: banks, insurers, regulated SaaS, and the IT service providers who deliver for them.