Work2023
Interweave
Still in use for content management. Cloud-proxying private APIs was the wrong shape.
Challenge
Admin UIs for API-backed products kept collapsing into the same hosted-builder compromise: a tool that didn't quite fit the data model, plus a backlog of one-off screens to paper over the gaps. Teams wanted forms, tables, RBAC, and tokens that stayed in step as the APIs changed, without commissioning a new internal tool every quarter.
The brief we took was to generate those UIs from response shapes. If the API already described the data, the admin surface should be able to follow it. The part we got wrong was where that generation should run.
Approach
Interweave generated admin UIs from response shapes, including forms, tables, RBAC, and encrypted tokens, and tried to stay in step as the APIs changed. Next.js and React Server Components were the implementation surface. A small DSL described the screens so we weren't hand-writing every table.
To make demos easy we put a cloud proxy in front of private APIs. A prospect could paste an endpoint and see a UI, which also meant secrets and private data had a path through our servers. Convenient for a sales call, and the wrong shape for production.
Outcome
It worked well enough that we still use it to manage content on API-driven apps. The miss was architectural: local-first would have been the better shape, generating the UI where the data already lives instead of shipping secrets through our servers.
If the product is a window onto someone else's API, don't become the network path. That rule still shows up when we design and build admin and content surfaces. Stay on the customer's side of the wire unless there's a reason not to.