Endava's DavaFlow puts OpenAI in every stage of software delivery

What DavaFlow actually changed

Endava's account, told through CTO Matthew Cloke, describes a specific sequence. AI-assisted coding sped up engineering output first. That exposed a new bottleneck: requirements gathering, business analysis, planning, and stakeholder coordination could no longer keep pace with how fast code was being produced.

The response was DavaFlow, a delivery methodology that runs OpenAI technology through the full lifecycle—meeting preparation, business planning, product discovery, engineering, and deployment. Cloke's claim is unusually absolute.

There isn’t a part of DavaFlow that doesn’t use OpenAI technology.Montana Labs

That framing matters because it treats AI as a change to the sequence of delivery work, not an add-on tool. Cloke describes being AI-native as reaching for AI first to solve a problem, not last.

The pricing app is the interesting data point

Most of the announcement lists familiar adoption categories: legal streamlining research, project managers using Codex for governance reports, leadership using agents to summarize projects and manage inboxes. Those are real but generic.

The concrete moment is the internal pricing discussion. Instead of working through spreadsheets, employees built a single-page pricing app that teams could interact with immediately. Cloke says it "changed the conversation completely."

The shift here is from static data in cells to a small interactive interface generated on the spot. When a spreadsheet becomes an app, the artifact stops being a file people read and becomes a surface people manipulate together. For non-technical commercial teams to produce a working frontend without dedicated engineering support is the more consequential capability buried in this story.

Who builds the frontend when engineering isn't the bottleneck

Endava frames this as adoption spreading beyond developers into legal, finance, and operations. The frontend angle is what makes that spread possible: lightweight, disposable interfaces that a commercial team can generate to replace a spreadsheet-heavy exercise.

This inverts a longstanding constraint. Internal tools normally wait in an engineering queue because building even a simple UI required someone who could write it. Endava's results list "enabled teams to build internal tools and applications without dedicated engineering support" as a distinct outcome, separate from faster engineering.

The open question the source doesn't answer: what happens to these apps after the meeting. A single-page pricing app that changes one conversation is useful; a hundred ungoverned single-page apps across an 11,000-person firm is a maintenance and correctness problem. The announcement celebrates creation but says nothing about the lifecycle of what gets created.

The implication: interactive interfaces become a disposable medium of thought

Endava's stated principle is to treat AI adoption as behavior change, not a software rollout, and to bring non-technical teams in early. The pricing-app anecdote shows what that behavior change looks like at the surface level: people reach for a small custom interface the way they used to reach for a spreadsheet.

For applied teams, the lesson is narrow and practical. When generating a usable frontend costs minutes, the interface stops being a deliverable and becomes a way to have a conversation—built to make one decision, then discarded. That lowers the bar for who gets to design software interactions, and raises a new governance question about which of these throwaway apps quietly become load-bearing.