Skip to main content

How DeX Works

DeX usage breaks down into a small number of steps. Everything past step 2 is carried by the platform and the partners assigned to the project.

1. Get access to the sandbox​

A new client or partner gets access to the DeX sandbox — a working environment to see the platform and try it against a real or representative problem, without any production risk. Inside the sandbox, a partner can:

  • Define requirements — capture customer needs and business goals
  • Build proof of concepts rapidly
  • Generate documentation — AI-driven BRD, SRS, and specs, automatically
  • Validate workflows — review and approve business processes
  • Review AI outputs — inspect generated code, tests, and plans
  • Go production-ready — export an implementation-ready project

Every partner gets DeX sandbox access; implementation partners get the additional build access needed to take a project from sandbox to production (see Partner Operations).

2. Define the problem and the proposed solution​

This is the only step that requires a human to think hard and write clearly. In plain English:

  • What problem is the customer trying to solve?
  • What's the proposed approach to solving it?

This becomes the spec. The clearer the spec, the better the output — there's no separate "translation" step the customer needs to do; if you know the business well enough to describe it, DeX can take it from there.

3. DeX and the assigned partners take it from there​

From the spec, DeX (with the relevant partner roles involved) produces:

  • Business and functional requirements (BRD, SRS, FSD)
  • A development plan and task breakdown
  • Working code, built and reviewed
  • QA validation
  • Deployment — dev → staging → production
  • Ongoing monitoring and support

Who's involved at each stage​

Stage Primarily driven by
Sandbox access & demo Referral Partner
Problem & solution definition, BRD/SRS/FSD Collaborative Partner
Build, QA, deployment Implementation Partner

One person or company can fill more than one of these roles on the same project — see Partner Types Overview.

The consistent message​

Whenever DeX is described — in documentation, on the website, in a pitch deck, in the first slide of any presentation — it should always answer the same three questions, in this order:

  1. What is DeX — a single agentic platform for the full SDLC.
  2. Why DeX — because agentic delivery is inevitable, and a partner network scales faster than direct sales alone.
  3. How you use DeX — sandbox access, plain-English problem definition, and the rest is delivered by the platform and its partners.