AI can write an application in hours. That changes who can create software and how much of it companies will build. It does not make the application ready to run a business.
Real software still needs identity, permissions, durable data, background work, exception handling, recorded outcomes, and somebody willing to trust it in production. The bottleneck is moving from writing code to operating code.
We built silicon explorer to study that gap. It is a browser workspace for inspecting a real hardware design: its hierarchy, signal flow, source, synthesis output, verification artifacts, analysis jobs, and the conversations attached to them. The application is useful on its own. More importantly, it forces the generated code, managed infrastructure, and operating controls around it to behave as one dependable system.
That is the role we are building floo to play: AI builds the software; floo makes it dependable.
the prototype is not the operation
The first version of a design explorer is straightforward to imagine. Load some hardware artifacts, render a graph, and put source code next to it. A coding agent can help produce that application remarkably quickly.
The operational workflow is harder. A real team needs to know who made a comment. Comments must survive a restart. Analysis must continue after the browser request ends. Failed work must have an inspectable state. Sensitive actions must be protected. Required work needs a clear outcome.
This is the prototype-to-production gap in miniature. The visible application is only one component. The operation also includes services, jobs, data, identity, controls, and failure handling.
why this app
Silicon explorer starts with an SDR digital downsampler and loads committed RTL, hierarchy data, synthesis output, verification reports, and golden simulation artifacts. It turns those inputs into a shared workspace for inspecting the design and acting on what the team finds.
The domain creates useful pressure. Source inspection and graph navigation are application features. Anchored review comments introduce identity, permissions, and durable state. Analysis introduces queues, workers, retries, and recorded outcomes.
That combination makes the explorer more than a visual demo. It is a contained, low-risk workflow where we can earn trust through reliable delivery before the same platform carries more consequential operations.
deterministic systems around fast-generated code
AI makes software creation fast, but it does not remove the need for deterministic behavior. Important work still needs rules that execute the same way every time, durable records of what happened, and clear outcomes when something fails.
In silicon explorer, that surrounding system looks like this:
- the gateway establishes user identity before the app handles a protected request;
- the backend, not the browser, owns recorded users and comments;
- Postgres preserves collaboration and job state;
- Redis carries analysis work beyond the original request;
- workers run defined checks and record their findings.
The small Express backend serves the frontend and owns that API surface. Its architecture follows the same path described in floo's Express guide. The point is not merely that the app deploys. It is that the business rules and required actions around the app keep happening after deployment.
identity is part of the process
Silicon explorer runs behind floo account access. The gateway handles sign-in and sends identity to the app with X-Floo-User-* headers. The backend exposes /api/me, then uses that server-owned identity when it records users and comments. The app auth guide describes the trust boundary in detail.
The app does not need to invent a login page, password reset flow, session store, or a second source of truth for permissions. More importantly, identity is carried into the work itself. A review comment is attributable because authentication is not an accessory around the workflow; it is one of its inputs.
durable collaboration
A comment becomes operational data as soon as another person depends on it. Silicon explorer lets a user attach one to a block, source range, schematic cell, net, port, or region.
In floo, the app receives managed Postgres credentials through the service environment. It records authenticated users and stores comments in Postgres when DATABASE_URL is present. Local development retains a memory fallback so the same API path can be exercised without managed credentials. Floo's managed services guide explains how those bindings reach the application.
That is a small example of the larger pattern: the prototype shows a comment; the production system preserves who said what, where they said it, and what the rest of the team should do next.
background analysis
Analysis runs introduce work that cannot be tied to a browser request. A user queues a job. Postgres records durable state. Redis carries the queue when REDIS_URL is available. A server-side worker processes lint, manifest, hierarchy, and synthesis checks, then records results for the UI to poll.
This is where an app starts to resemble an operation. Work has a lifecycle. Its result can be inspected. A failure does not have to disappear into a request timeout or depend on somebody manually starting the process again.
The current explorer deliberately keeps that lifecycle simple. As the workflow becomes more consequential, the same boundary is where retries, approvals, exception queues, and richer audit trails belong.
what broke, and what changed
The first useful version of analysis was easy to make request-shaped: click a button, run checks, return a result. That stopped being an honest model as soon as the work needed to outlive the browser request or another person needed to understand what happened later.
We changed the application shape around that failure mode. Starting analysis now creates an explicit job with durable state, queue-backed execution, defined findings, and a result the interface can revisit. The worker, database, and UI agree on whether work is queued, running, completed, or failed.
The surprising lesson was that running the checks was the easy part. The production requirement was making the lifecycle trustworthy. A business process needs more than an action that usually finishes; it needs a durable record of whether the required action happened and what should happen next.
why non-hardware teams should care
Replace a hardware analysis job with document extraction, customer onboarding, compliance review, data reconciliation, or generation of a client deliverable. The operating requirements barely change. The process still needs authenticated actors, persistent records, jobs that survive a request, deterministic validation, exception paths, and outcomes somebody can verify.
These are exactly the contained workflows where companies can start using AI-built software without betting the business on day one. Prove one useful process, make its behavior dependable, then expand into more workflows and more critical infrastructure.
what silicon explorer taught us
Traditional platforms are optimized to ship an application. Silicon explorer reinforced that floo has to carry the operation around it.
That means treating account access, server-owned identity, managed Postgres, managed Redis, background jobs, recorded outcomes, and push-driven releases as parts of one product path—not a collection of services the customer must assemble and own. It also means testing failure and ambiguity, not just whether the happy path reaches a live URL.
The cost of creating custom software is collapsing. Companies will build far more of it, often through operators, consultants, internal AI teams, forward-deployed engineers, and coding agents rather than conventional product teams alone. Those builders need speed, but the companies depending on their work need guardrails and production quality.
Silicon explorer is one small proof of that future. AI can make the application possible. Floo's job is to make the process reliable enough that a team can use it to run real work.