Fusion
Book a session

Built-in lifecycle

The development lifecycle is built into the app.

On most deliveries the evidence lives outside the software: a wiki nobody opens after go-live, a spreadsheet of test results, a roadmap deck that stopped being true in month three. Fusion knows what it is made of, so it keeps that record itself. The roadmap, the workflow gates, the user guides and the test recordings are pages in the application your people already sign in to — and they are current, because the work is what updates them.

The application's own user menu open, listing feedback, user testing, roadmap, the delivery board and what's new alongside account security and sign out
Start here, because it shows where all of this lives. Feedback, user testing, the roadmap, the delivery board and the release notes sit in the same menu as account security and sign out. Nobody bought a second tool and wired it in. They are pages of the application, in the place a user would look for them.
The product roadmap showing 86 per cent complete, six of seven delivery artefacts done, grouped into Discovery and Design phases
Every artefact the delivery depends on, with its state: the problem statement, the personas, the domain model, the workflow value chain. Six of seven done, one in progress, and each one opens the document itself. The ones marked "Living doc" are rewritten as the software changes, not at the end of a phase. Stakeholders see progress without anybody preparing a report.
The roadmap value chain tab, showing twenty-one workflows each tracked across five gates: spec, build, system testing, user guide and user testing
Twenty-one workflows, each carrying the same five gates: spec, build, system testing, user guide, user testing. A workflow is not finished when the code runs. It is finished when somebody outside the team has read the guide and used it. The counts across the top are the honest state of the delivery, on a page anyone can open.
The user testing panel with the Invite User workflow selected, its five gates shown, a Before you record checklist and an enabled start recording button
A user opens this from their own menu and picks the workflow they are about to exercise. Only workflows whose user guide is finished can be recorded — the rest are listed but refuse to start. Then the app tells the tester how to run the session, and the recording lands against that workflow's user-testing gate. Feedback is not a survey sent afterwards. It is collected in the application, at the moment the person meets the thing.
The what's new page inside the application, showing release v0.35.0 with its changes grouped into added, changed, fixed and security
Every release writes itself up here, grouped into what was added, changed, fixed and secured — in the language of the business, not commit messages. "Brightwattle can now set up the facilitator training its delivery partners' staff attend." The security entries name the fix and the CVE. Your users read this page. So does your auditor.
The roadmap is a page in the app, not a slide Five gates on every workflow Evidence collected where the work happens

Built AI-native

Ask for a change. Everything it touches moves with it.

AI was not added to Fusion afterwards. The framework was built to be worked on by it, which means it knows what it is made of — which spec describes which workflow, which code implements it, which tests cover it, which guide explains it. Ask for a change and it already knows the full list of things that change with it.

Somebody asks for

“Add a risk rating to the intake workflow. Anything rated high should route to the compliance queue for sign-off.”

One sentence, from somebody who does the job — not a change request written by somebody who has to translate it first.

What moves with it

  1. 01

    The specs

    The workflow spec, the resource specs and the domain model are updated to describe the new field, the new rule and the new route.

  2. 02

    The code

    Fields, logic, screens and the database migration, written to the conventions the framework already holds.

  3. 03

    The tests

    Unit and system tests written for the new behaviour, then run. When one fails it fixes the code, never the test.

  4. 04

    The user guide

    Rewritten against the screens as they now are, and the walkthrough video recorded again.

  5. 05

    User acceptance

    The task script prepared, the sessions analysed, the findings triaged into issues and queued for retest.

  6. 06

    The plan

    Roadmap status, changelog entry and tech-debt ledger all brought back up to date.

  7. 07

    The release

    Deployed, and then verified in production.

4–8h

Request to production

A change of this size lands the same day. The person who asked for it watches it working before they go home, instead of waiting for it to appear in a release three months out.

80/20

AI effort · human effort

AI does the writing: the specs, the code, the tests, the guide. Your people spend their fifth of the effort on the two parts that need a person — deciding what ought to change, and judging whether what came back is right.

It knows what it is made of

The roadmap, the domain model, the specs, the code, the tests and the guides are a declared chain, not a folder of documents that happen to sit near each other. A checker walks that chain and reports anything that no longer agrees with its neighbour.

A named skill for every step

Not one general assistant guessing at your house style. Each step has its own skill, with its own inputs, its own outputs and its own definition of done — shipped and versioned with the framework, so the conventions arrive with the code.

You approve at every checkpoint

The orchestrator stops and waits: at the workflow spec, at the resource specs, at the test coverage. Nothing reaches production because a machine decided it had finished. The work is faster, and the judgement stays yours.

See the lifecycle run — on your workflow, not ours.

The fastest proof is a live one. Take the Challenge and watch the roadmap, the gates, the tests and the guides stay current while the software is built.

Take the Idea to Impact Challenge Book a session