Platform
A full-stack console for serious AI software delivery
Logs, database, network and errors — visible beside the chat, so you debug the app with evidence and put the findings straight into your next prompt.
The full-stack console is the diagnostic surface inside the Ciao Builder: logs, database state, network requests and errors, visible beside the conversation. Unlike AI builders that leave you guessing when something breaks, the console shows what actually happened across the stack — so the next prompt carries evidence, not speculation, and fixes land on the real cause.
Published 2026-07-03 · Last updated 2026-07-03
Debugging an app you did not hand-write
When an app you built with AI misbehaves, the worst position to be in is guessing. Is the bug in the UI, the query, the API call, or the data itself? Without visibility, a one-line fix becomes an afternoon of speculative prompting — trying rewordings against a black box and hoping one of them lands.
The full-stack console gives you the visibility engineers expect, inside the Builder: server and browser logs, database tables and rows, network requests and responses, and errors with their context — all beside the conversation. You see what actually happened, then put the evidence into the next prompt.
This is not a niche power-user surface. The whole promise of building software from plain language collapses the first time something breaks and the platform cannot show you why. Visibility is what keeps the promise honest.
How the console works
Everything happens beside the conversation — the point is to keep evidence and action in the same place.
1. Open it beside the chat
No separate tools, no context switch. The console sits next to the conversation and the live preview.
2. Read the logs
Server and browser output from the running app, so "it did not work" becomes a specific line at a specific time.
3. Inspect the database
Look at the actual Supabase tables and rows behind the app. Confirm whether the record was written, and with what values.
4. Watch the network
Requests, responses, status codes and timings — especially valuable when integrations and external APIs are in play.
5. See errors in context
Failures appear with the surrounding activity that produced them, not as bare messages stripped of their story.
6. Turn evidence into the fix
Reference what you found in the next prompt. For live production issues, Doctor — the read-only AI SRE — probes the app, DNS and CDN, diagnoses root cause and drafts the fix.
Why it matters
Prompting with evidence beats prompting with vibes. "The POST to /api/orders returns 400 and the row never appears in the orders table" produces a correct fix in one round; "the order thing is broken" produces a rewrite of something that was never the problem. The console is what makes the first kind of prompt possible for everyone, not just engineers.
This is a large part of what separates AI-assisted engineering from hopeful chatting: the system shows its state, the human reasons about it, and the fix is grounded in what the stack actually did. Over time that produces a quieter codebase — fewer speculative rewrites, smaller diffs, and a team that trusts the app because it can always see inside it.
It also changes who can support an application. An agency or an operations team can answer "what happened to that order?" with data rather than escalation, because the question is inspectable in the same place the app lives.
Who uses the full-stack console
The console serves everyone who has ever had to answer the question "what actually happened?"
- Technical founders — Diagnose their own apps in minutes instead of escalating every hiccup or re-prompting blind.
- Agencies — Support client apps professionally — reproduce the issue, read the evidence, ship the reviewed fix.
- Developers — Verify AI-written backend behavior — queries, writes, API calls — before trusting it with production data.
- Operations teams — Confirm that data flows between the app and existing systems are doing what the integration promised.
Security and governance notes
Visibility is powerful, so it ships with controls:
- ✓ Workspace access, including the console, follows role-based access control.
- ✓ Fixes driven from console evidence still pass Guardrails review and QA gates before publish.
- ✓ Security confirms vulnerabilities against the live app before flagging them — findings, not noise.
- ✓ Doctor operates read-only: it probes, diagnoses and drafts fixes, but changes ship through the governed loop.
- ✓ Prompts, merges and deploys around every fix land in the append-only audit trail.
What the console shows
Four surfaces cover most investigations end to end:
| Surface | What you see | What it answers |
|---|---|---|
| Logs | Server and browser output from the running app | What executed, and what it reported |
| Database | Supabase tables, rows and values | Did the data actually change, and how |
| Network | Requests, responses, status codes, timings | What the app and external systems said to each other |
| Errors | Failures with surrounding context | Where it broke, and what led up to it |
Frequently asked questions
Do I need external tools to debug an app built on Ciao?
For day-to-day work, no — logs, database, network and errors are inspectable from inside the Builder. Because the app is standard React, TypeScript and Supabase you own, your engineers can also attach whatever external tooling they prefer.
Can I look at the actual database?
Yes. The console shows the Supabase tables and rows behind your app, so you can confirm what a flow actually wrote. It is often the fastest way to tell a UI bug from a data bug.
How does the console relate to Doctor?
The console is you looking at the stack; Doctor is a read-only AI SRE that looks for you — probing the live app, DNS and CDN, diagnosing root cause and drafting the fix. They work best together: Doctor for production incidents, the console for build-time investigation.
Who on the team can see the console?
Access follows role-based access control on the workspace, so you decide who can inspect logs and data. Enterprise plans add SSO via SAML and OIDC and optional MFA on top.
Does using the console bypass governance when I ship a fix?
No. The console informs the fix; the fix still merges under Guardrails with recorded human review, passes QA smoke gates before publish, and is recorded in the append-only audit trail.