One pass through the whole platform: upload requirements, generate a specification, break it into work, prototype it, build it, and open the result.
This guide runs a project through every stage the platform offers, from a requirements document to an application you can open.It is deliberately end to end. Each stage produces something the next one uses, and seeing that chain once is more useful than reading about any single part of it.
Before you start: you need an account and something to build from, such as a requirements document, a solicitation, or an existing codebase. Anything the platform can read is enough to begin.
1
Create a project
Select Create Project on the dashboard. Give it a title, choose Web Application, and create it.
Creating a web project. Only the title is required.
By default, the project opens into the CAB, which is where every project starts.
2
Upload your chosen content and generate your Common Application Blueprint.
Upload documents or a source archive, leave all ten sections selected, and select Generate Blueprint.
The CAB workspace. Upload on the left, the generated blueprint on the right.
Generation may take a while depending on the volume of content you upload. The CAB process assesses everything you uploaded and writes a full specification. The preview populates when it finishes.What you should see: a document covering the project’s identity, its user stories, its data model, screens, roles, workflows, rules, reporting, integrations, and a list of questions your source material left unanswered.Read the Suggested Questions section first. It is the platform telling you where your requirements are thin, and it is usually the most valuable output of this step.See Step-by-Step Workflow for what happens during generation.
3
Refine your CAB
Select Edit CAB to change anything the platform misread, or ask the BlueGenAI CAB Agent to make a change for you.Either way the change goes to a review screen where you accept or discard each one before it is written. Saving creates a version you can return to.
Everything downstream is generated from this document! Spending the time to clarify requirements and update your CAB will result in the best possible build, testing, and support clear traceability.
Select Generate Tickets in the blueprint toolbar, then open the Tickets tab.
Tickets generated from the specification. Each traces back to the requirement that produced it.
Each Ticket carries the user story it came from, including its acceptance criteria, and a reference back to the blueprint element that produced it.Open the Epics view. Tickets are grouped into Epics, and each Epic is a wave in the build order; Wave 1 holds the foundations everything else depends on.What you should see: a numbered list of Tickets, and an Epics view where each Epic carries a wave number and a progress count.See Tickets and Epics.
5
Build it
Switch to Build. This starts a fresh conversation, so attach the prototype files you saved and reference the Tickets you want built.Type @ followed by at least two characters to reference a Ticket. Keep the number small, and stay within one Epic; the waves are ordered for a reason.
The agent classifies your request, asks questions if it is ambiguous, then writes the application, runs it, and fixes what breaks before replying.What you should see: a summary of what changed and a URL for your running application.See Using Tickets to Build and Build Mode.
6
Test as you Go
With App testing enabled, the agent opens your application in a browser after building and works through it, checking the acceptance criteria that came from your original requirements.Open the URL from the agent’s reply, or from URLs in the panel rail.See App Testing.
7
Review and Refine your build
Periodically assess your application as you build it! Make refinements as you go.Access your build via the URL provided on the Application URLs panel using credentials provided by the Builder. You may specify the builder create accounts for you as needed.When you are satisfied your application meets your requirements - present it to stakeholders and be sure to take credit for the massive time and cost savings!
You took source material, turned it into a reviewed specification, broke that into ordered work, reviewed and revised it before building it, built it, and had it tested against the acceptance criteria written in the original requirement.That SDLC chain is the secret formula to our platform’s success. Every Ticket traces to a requirement, every Epic sets a build order, and the tests exercise criteria that were written down before any code existed.
Run it again on something real. The second project is where the workflow starts paying off, because you already know what each stage hands to the next.
Start with better requirements
What a CAB is, and why the platform generates it rather than asking you to write it.
