SpinFlow.ai: building our own application frontend under real load

SpinFlow.ai exists because internal teams needed a single place to run AI-assisted workflows against structured business data without copying that data into a third-party tool. It combines document intake, model orchestration, and reporting into one authenticated application rather than a chain of disconnected scripts.

The problem was never generating text. Any API can do that. The problem was giving a user a live view of a long-running job, letting them intervene mid-run, and keeping that view correct if they refresh the page, lose connection, or open the same job in a second tab.

We built the frontend on TanStack Start with React 19. Routes are file-based and each one defines its own server-side loader, so the data a page needs is fetched on the server and streamed down already shaped for the view instead of being assembled client-side after a spinner.

The database is Postgres with row level security enforced at the database layer, not just in application code. A query issued from a compromised or buggy route still cannot return rows outside the caller's tenant, because the database itself checks the policy before returning anything. Application-layer checks are a second layer, not the only layer.

Styling uses Tailwind v4 with design tokens rather than a component library skinned after the fact. Tokens let us keep dense data views, dashboards, and the marketing-facing parts of the product visually consistent without duplicating spacing and color decisions in three places.

Model responses are streamed token by token to the browser over a persistent connection, rendered incrementally so the user sees progress instead of a blank screen followed by a wall of text. Streaming has to survive the user navigating away mid-response, and it has to cancel cleanly server-side when they do, or the job keeps burning tokens against nobody.

We run the streaming endpoints on an edge runtime specifically because cold starts on a traditional server would add visible lag to the first token. Edge functions start close to the user and close to where the request originates, which matters more for a chat-style interface than for a page that just needs to render once.

Reporting views in SpinFlow.ai can return tens of thousands of rows across a quarter of activity. Rendering that client-side as a single React list is a known way to freeze a browser tab. We paginate and virtualize on the server side, so the client only ever holds the rows currently visible plus a small buffer.

Latency budget matters more once you are streaming AI output and paginating large tables in the same interface. A slow database query on one panel should never block a fast one on another. We isolate loaders per route segment so one expensive query cannot stall the rest of the page.

It proves the stack we recommend holds up under a workload with real users, real cost, and real consequences for a bug, not just a portfolio piece. It proves row level security at the database layer is workable in production, not just a talking point. It proves server-rendered streaming interfaces can be built without a client-side state management library carrying the whole app.

It does not prove every client needs this exact stack. A five-page brochure site does not need row level security or streaming. What it proves is narrower and more useful: when an application actually needs authenticated state, live data, and role scoping, this is the architecture that holds.