Most software projects still ask customers to make their most important product decisions at the moment when they have the least useful information. Requirements are discussed in meetings, turned into tickets or diagrams, translated into code, deployed somewhere, and only then does the customer finally get the most valuable artifact in the entire process: something they can actually use.
By that point, changing a workflow may touch database migrations, authentication, integrations, infrastructure, deployment configuration, training material, and production data. The feedback is still valuable. It is simply arriving late.
At SCI-ENCE, we have been working toward a different software development lifecycle: requirements → interactive UAT → construction → deployment. The customer gets a functioning application early enough that “that is not how we work” is a cheap and welcome sentence instead of a change request.
The capability making that possible is being built into DiagramCraft: full-stack Application Preview. A conventional React/Vite/Lovable-shaped project can live inside the same diagram where requirements, architecture, decisions, source, feedback, and implementation plans already live. It can run there against a local Supabase-compatible environment. When approved, the same source can move through Git into its production build path.
The first time a customer truly understands the software should not be after we build it.
Traditional prototyping helps, but prototypes often create a second problem: the prototype and the real application become two different products that must be translated between.
Describe → build → reveal → revise
The business explains its process. The delivery team interprets it. A production implementation accumulates. UAT discovers where interpretation and reality diverged.
The expensive learning happens late.
Describe → experience → approve → build
Requirements become a runnable application early. The customer tests workflows against safe local data. The application itself becomes the shared language for refinement.
The important learning happens while change is still cheap.
A requirements workshop can now end with software instead of homework.
The practical change is not just technical. It changes what a client engagement feels like.
Less translation. Less sunk-cost resistance. Better decisions.
The value is not “we can run React in a diagram.” The value is that software decisions can be made with evidence before those decisions become expensive.
Requirements become observable
A requirement can be discussed, modeled, implemented in the preview and evaluated as one continuous artifact instead of hopping between documents, mockups and tickets.
Feedback gets cheaper
A major workflow correction before production data and integrations are attached is fundamentally less disruptive than the same correction after deployment.
UAT becomes collaborative design
User acceptance testing stops being a final gate and becomes an active part of discovering how the system should work.
Local and real services can mix
The application can start with disposable local services and selectively connect to real backends later. Development fidelity can increase without rewriting the front end.
The approved source survives
Because the preview runs a normal project structure, approval does not create a dead-end prototype that must be reconstructed by another team.
Risk becomes visible sooner
Dependency problems, migration assumptions, browser-runtime limits and backend contract gaps surface during design rather than hiding until the deployment sprint.
The interesting part is not the preview. It is everything the preview is attached to.
There are plenty of places to render a web application. The thing that makes this workflow different is that the runnable application is attached to the same persistent model that carries the surrounding reasoning.
A DiagramCraft workspace can hold requirements, architecture, customer questions, diagrams, source trees, runnable demos, implementation prompts, review findings, code artifacts, feedback and deployment relationships. Humans and multiple AI systems can enter and leave the work without depending on one enormous conversation history.
Design, spike, specify, review, revise, realize.
Application Preview is also a case study in the multi-agent workflow we want our customers to benefit from.
The sequence was not ceremonial. Each stage removed a different category of uncertainty.
We tested browser build technology before writing the production runtime. Rolldown failed under the available browser constraints; esbuild-wasm proved viable. We ran a Tailwind/Lovable compatibility spike. We proved pgLite could enforce PostgreSQL row-level security under an unprivileged role. We tested a local Supabase-shaped client and Worker function path. We changed preview-origin isolation during the investigation and cleaned up state between spikes.
Then we stopped and asked another model to review the plan against the actual DiagramCraft source. Claude found assumptions that looked reasonable in architecture prose but did not match the live implementation. The plan was revised before Lovable was asked to spend implementation credits.
Requirements, UAT, construction and deployment can become one continuous chain of evidence.
For SCI-ENCE customers, that continuity matters. A requirement can be traced to the screen that demonstrates it, the migration that supports it, the acceptance conversation that changed it, and the code that eventually ships it. The handoff between “consulting,” “design,” “development” and “deployment” becomes thinner because the artifacts are already connected.
This is particularly useful for small and midsize organizations where the people who know the business process are not professional product managers. Asking them to reason about a static specification is often unfair. Asking them to react to a working workflow is much easier.
How a full-stack app runs inside DiagramCraft without becoming a DiagramCraft-specific app
For engineering readers, the architectural constraint is more interesting than the UI: the application source must remain production-shaped.
Why pgLite instead of a fake JavaScript database?
Supabase applications are PostgreSQL applications. A simplistic object store can imitate CRUD calls while hiding exactly the behavior that becomes painful later: SQL migrations, constraints, functions, roles and row-level security.
pgLite gives the browser a real PostgreSQL execution environment. The local compatibility layer can then set an unprivileged role and transaction-local JWT claims so application RLS policies are exercised rather than bypassed.
How does Local / Remote / Hybrid work without changing application code?
The application continues to use the normal Supabase client surface. Preview settings choose where database, auth, storage, realtime and functions are routed. A project may use a local database while pointing one other surface at a remote Supabase environment.
The important design rule is that preview-time substitution belongs around the project, not scattered through the committed React source as `if (DiagramCraft)` branches.
What does “Vite compatible” mean in a browser runtime?
It does not mean embedding Node or running the entire Vite development server in a tab. Application Preview reads the conventional project tree, understands the important project conventions, and uses browser-compatible build infrastructure.
The current implementation resolves project dependencies from package.json, supports Vite and tsconfig aliases, bundles TypeScript and TSX through esbuild-wasm, handles public and binary assets, injects VITE-prefixed environment values, and explicitly rejects unsupported Node built-ins instead of pretending they work.
Why not WebContainers?
For our target economics, making the feature depend on a commercial browser-Node runtime would undermine the reason we are building it: reducing the marginal cost of iterative development and UAT. The architecture favors browser-native open components and adapters that we can control.
What about Supabase Storage, Realtime and Edge Functions?
They are part of the Phase 1 fidelity target rather than permanent “mock later” items. Local Storage uses browser persistence with a Supabase-shaped catalog/policy seam. Realtime covers database changes, Broadcast and Presence. Conventional `supabase/functions/<name>/index.ts` source is discovered and executed through a local preview function runtime.
The philosophy is not “clone Supabase perfectly before we ship.” It is “support the common application contract deeply, identify unsupported capability gaps honestly, and preserve a Remote/Hybrid escape hatch.”
How are preview origins handled?
DiagramCraft already supports multiple preview-origin strategies: a shared preview host, workspace isolation, diagram isolation, an explicitly dangerous same-host mode, and eventually element-scoped isolation. Enterprise deployments may use their own domains.
The Application Preview protocol therefore does not hard-code diagramcraft.com. It consumes the host/origin resolved by the DiagramCraft installation, validates message origins, and derives persistent namespaces from logical workspace/diagram/project/environment identity rather than hostnames.
The scarce resource is no longer typing code. It is maintaining trustworthy context.
Modern AI systems can produce code quickly. They can also produce incompatible code quickly, repeat an experiment another agent already performed, forget why an architectural decision was made, or confidently optimize for a requirement that changed three conversations ago.
We found that the most valuable role for DiagramCraft in a multi-agent workflow is not simply drawing architecture. It is becoming the shared durable state around the work. The diagram gives each agent a place to deposit results in a form that another agent can inspect without inheriting the first agent's entire hidden context.
That is why this feature was not designed in one heroic prompt. The work was broken into explicit artifacts: executable browser spikes, implementation specifications, reusable TypeScript, an independent review area, revised work bundles, and implementation notes written back after Lovable completed each pass.
And yes, this article is part of the same workflow.
The post you are reading was authored as a standalone JSX artifact inside the Application Preview design diagram while the final implementation work was still underway. The implementation notes beside it were backfilled from the actual Lovable turns. A marketing-site agent can now read this artifact directly from DiagramCraft, adapt it to the SCI-ENCE site, and publish it without reconstructing the engineering story from a pile of chat transcripts.
That is a small example of the larger idea: requirements, implementation, review, customer evidence and communication do not need to be separate islands.
Software that can be understood before it becomes expensive.
Our goal is not to eliminate production engineering. It is to make sure production engineering starts from something the customer has already experienced and shaped.
For a SCI-ENCE engagement, that means the path can increasingly look like this: we model the business together, turn the model into an application, put the application in front of the people who actually use the process, capture what we learn, and only then harden the approved source into its production environment.
The same DiagramCraft workspace can carry that journey from the first requirements conversation to the pull request.
That is a different kind of prototype. More importantly, it is a different kind of software development lifecycle.