---
title: Code-first apps
description: How Relpin treats every internal tool as real code with deterministic releases.
section: Concepts
sidebarLabel: Code-first apps
order: 20
updated: "2026-06-11"
status: beta
llms: true
keywords:
  - code-first
  - project files
  - templates
  - releases
---

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.