Infragility Web: Designing an Agent Dashboard Before the Agents Existed
Most dashboards fail in the seams between systems. The UI looks finished, but the data flow is fake, the states are brittle, and the real product has not met reality yet. That gap was what interested me. I wanted to prototype the front end of an agent driven SEO system before the underlying runtime was fully wired up, then see whether the architecture still held.
The project became a Next.js dashboard for talking to specialist agents, submitting optimization requests, tracking jobs, and inspecting metrics. A lot of what mattered was not the visuals. It was whether the system felt coherent even while parts of it were simulated.
Designing Around Incomplete Infrastructure
The hardest decision was building around a backend that was only partially there. The WebSocket layer existed. The bridge server contract existed. But project data, analytics, and some chat behavior were still mocked.
That pushed me toward separation early. Chat logic sat apart from project tracking. The API client abstracted transport. Components were reusable instead of page specific. That mattered because simulated data can hide bad boundaries. Hardcoded data forces you to be honest about whether your interfaces make sense.
- A WebSocket layer with fallback responses when live communication failed
- A project status system built from typed structures before real endpoints existed
- Form submission flows that modeled async behavior before production APIs were ready
One small detail I liked was dynamic pricing logic inside the optimization form. It was simple, but it made the request flow feel like a product, not just a demo.
What Looked Real But Was Not
Some of the most useful work in the project was fake on purpose. Metrics were hardcoded. Some submissions used setTimeout instead of real calls. Even the charts were intentionally simple div based visualizations instead of full charting components.
That was a tradeoff. I wanted to spend time validating interaction patterns before polishing data plumbing. I would still make that trade again, but I would push real integrations earlier next time. Simulated systems can make progress feel further along than it is.
The Interesting Part Was State
The project taught me more about state than about UI. Connection status, optimistic interactions, message history, form loading states, and project progress all overlap. That creates edge cases fast.
The useful insight was that a dashboard like this is mostly coordination. Tabs and cards are surface area. The real product is how many moving pieces stay consistent under weird conditions.
TypeScript helped here more than styling ever did. Defining message, project, and metric structures early prevented a lot of silent breakage.
What I Would Change
I would replace more mock data with live backend contracts sooner. I would use the charting stack already in the dependencies instead of simplified visual placeholders. Form validation was also too basic. I could feel where Zod schemas should have gone deeper.
I also underestimated how much missing backend behavior shapes frontend decisions. Some abstractions I made early were clean, but others were guesses.
Sometimes building the shell first teaches you where the machine should go.