You write the domain model. STRVCT does the rest while the app runs: it presents your objects in a user interface on desktop and phone, stores them locally, syncs them to the cloud, imports and exports them as JSON, and lets AI agents read and edit them. Nothing is generated ahead of time: views are created from the live objects as the user navigates, and they update when the objects change. Add a property, annotate it, and every part picks it up. There is no separate form, storage mapping, or tool schema to write.

Why this hasn't worked before. The idea is old; it's called Naked Objects. Its weakness was that generated interfaces looked like database forms, so real applications ended up hand-building their screens anyway.

What's different here. STRVCT starts from an observation: nearly every screen in an information app comes down to a few decisions about the data. What is visible? Does each item open beside its parent, as a column or tab, or sit inside it, as a section of a document? How are lists arranged? The framework handles the mechanics, including navigation and adapting to screen size. You state your choices as small hints on the model. So changing how something looks means changing a hint, not rewriting a screen.

Read the paper →