Relpin apps are code-first internal tools. A generated app is a real TypeScript or Python project with files you can inspect, edit, and ship through a governed release path.
What code-first means
Code-first means the source project remains the authority for behavior. Studio can help author the app, OpenCode can edit the project, and templates can create a starting point, but the app still resolves to files, routes, SDK calls, and release artifacts.
This avoids the usual split between a fast builder and a fragile production handoff. The same project that previews is the project that gets released.
What Relpin governs
Relpin governs the parts that make internal tools risky in production:
- access to tenant data
- session and permission checks
- preview and publish execution
- release promotion
- audit history
- runtime environment scope
The app remains editable code. The platform controls the boundaries around it.
What this is not
Relpin is not a generic AI chat product and not a browser-only low-code canvas. The browser can be a rich authoring surface, but it is not the runtime authority for compile, preview, or publish.
Typical app shape
A typical Relpin app contains:
- UI routes and components
- server-side route handlers
- SDK imports for auth, data, and runtime context
- template-owned package dependencies
- publish metadata
That shape can evolve, but the invariant stays the same: production behavior should be traceable to code and a pinned release.