rntme · v0.1 · 2026-04-20
early access · github Apply →
rntme · early access · 2026

Your AI can build an app. rntme helps it build one you can keep alive.

Vibe-coded apps ship fast, then turn into brittle, insecure codebases that get harder to change with every prompt.

rntme turns a validated service blueprint into a working API and UI on a standard runtime, so every new service starts from guardrails instead of chaos.

Request early access → See the blueprint demo
  • Validated blueprints
  • API + UI from one spec
  • No service-specific backend code
  • Built for workflow-heavy apps

Vibe coding breaks when the app becomes a business system.

The first AI-built tool feels magical. The second one comes with a new schema, new conventions, a strange auth flow, and a diff nobody wants to review.

The problem is not that your agent stopped being fast. The problem is that every new service becomes a one-off backend your team now has to secure, debug, and maintain.

The agent didn’t slow down. Your architecture did.

What teams do today.

Five common shapes. All of them ship the first app. None of them stay coherent across the next four.

Prompt + code Cursor + Supabase + discipline
Works on service #1. Compounds entropy by service #5.
AI-native app builder Lovable / Bolt / Firebase Studio
Optimized for first-run wow. rntme is optimized for service #10 looking like service #1.
Backend-as-a-service Supabase / Firebase / PocketBase
A menu of primitives. rntme is a standard runtime across many services.
Internal tool builder Retool / Appsmith / ToolJet
UI over data. rntme is state, workflow, and UI from one blueprint.
Spec-first, no runtime OpenAPI / ERD / design docs
Better planning, but no runtime that enforces the result.

rntme gives your agent a safer target than an arbitrary codebase.

A service is described as a validated blueprint. The blueprint defines the domain, state transitions, API surface, UI, and seed data. rntme validates it in layers, then boots a working service on a standard runtime.

You stop reviewing sprawling implementation diffs. You review intent. 

{
  "service": "ticketing",
  "aggregates": {
    "Ticket": {
      "fields": {
        "title":       "string",
        "description": "string",
        "assignee":    "UserId?"
      },
      "states": ["Open", "Assigned", "Resolved", "Closed"],
      "commands": {
        "open":   { "from": "*",        "to": "Open"     },
        "assign": {
          "from":   "Open",
          "to":     "Assigned",
          "params": { "assignee": "UserId" }
        },
        "resolve":{ "from": "Assigned", "to": "Resolved" },
        "close":  { "from": "Resolved", "to": "Closed"   }
      }
    }
  },
  "ui": { "screens": ["List", "Detail", "Assign"] }
}
Fig. 01One input. Three effects. Keep reading →
  1. 01

    HTTP endpoints

    POST /tickets · GET /tickets/{id} · GET /tickets · PATCH /tickets/{id}/assign — emitted with OpenAPI 3.1.

  2. 02

    Declarative UI

    List view, detail view, and command forms — all from the same blueprint, none hand-coded.

  3. 03

    State machine

    Open → Assigned → Resolved · Closed — invariants enforced by the runtime, not by you.

From blueprint to running service.

  1. 01

    Describe the service

    One JSON file: domain, data, state transitions, HTTP/UI bindings, seed. Written by hand or by an agent.

  2. 02

    Validate before boot

    Parse → structural → references → consistency. An agent cannot silently produce a broken service. Errors come with stable codes.

  3. 03

    Compile & migrate

    The runtime produces the schema, the migration plan, and the event log your service needs. No manual DBA work.

  4. 04

    Boot a working service

    Same event log, same projection consumer, same HTTP surface, same UI surface — for every service. Zero service-specific code.

  5. 05

    Reuse for the next one

    Copy the blueprint. Change the domain. Ship. The next workflow app isn't a new snowflake backend.

Who rntme is for.

  1. AI-native product teams

    You already use coding agents. You want the next service to be safer than the last one.

  2. Agencies and studios

    You build similar internal and business apps repeatedly. You want higher margin and less reinvention.

  3. Platform-minded teams

    You need a bounded standard for AI-assisted service creation.

What rntme is not.

rntme is not a generic prompt-to-app builder. It is not a BaaS replacement for every product. It is not the right tool for games, consumer social apps, or highly custom greenfield backends.

It is for workflow-heavy business services that need structure, repeatability, and safer change. That focus is the feature.

We work with your team directly.

If you already shipped one AI-built workflow app and you know the second one will turn into maintenance debt, work with us. Paid engagement. We stay on through your first rntme service.

  1. 01

    Team

    Size, what you've shipped, your current stack.

  2. 02

    The second service

    What you'd build on rntme next — domain, scope, why this one.

  3. 03

    Timeline

    When you'd start; when it needs to be live.

  4. 04

    Contact

    Name, role, work email.

Apply on Tally → Four questions · about 3 min

Honest answers.

Is this lock-in?
No. The blueprint is plain JSON, the runtime is open source, and the point is to make service intent portable and reviewable. Your data is in a standard format you can read with any tool.
Can I use this for every app?
No. rntme is intentionally opinionated. It fits workflow-heavy business services. That focus is the feature.
Why not just keep using Cursor plus Supabase?
For the first quick app, you probably should. rntme becomes valuable when you need the second and third service to stay understandable a month later.
What if my logic doesn't fit the runtime?
If it doesn't, rntme is wrong for that service — not for every service your team builds. We'll tell you honestly during intake.
Is this production-ready today?
We're working with early-access teams to answer exactly that. The runtime core is stable; the control plane is in beta; we'll tell you honestly which of your services fit today and which don't.