One Method, Eight Interfaces: How Remy Apps Run Everywhere at Once
Define a backend method once and Remy projects it onto web, REST API, Discord, Telegram, MCP, cron, webhook, and email—no integration code. Here's how, and why it matters.
What “one method, eight interfaces” means
Most full-stack apps are built interface-first. You write a web frontend, then bolt on an API, then add a Discord bot as a separate project with its own auth and database calls. Each interface is a new integration surface, a new place for bugs to hide.
Remy inverts that. You describe what the app does, Remy compiles that into backend methods (the app’s contract), and the platform projects each method onto every interface automatically. One method becomes a web button, a REST endpoint, a Discord slash command, a Telegram action, an MCP tool, a cron job, a webhook receiver, and an email handler. Same logic, same auth, same database: eight surfaces, zero integration code.
This is one of the clearest payoffs of what a product agent is: you define the contract once, and the platform makes it accessible however users want to reach it.
TL;DR
- In Remy, a backend method is the contract—it defines the inputs, the logic, and the output, once.
- The platform projects that method onto eight interfaces (web, REST API, Discord, Telegram, MCP, cron, webhook, and email) without per-interface code.
- There’s also a ninth interface, a conversational Agent: an in-app LLM that calls these methods as tools, rather than projecting one method onto a surface.
- You don’t write the methods or the integrations by hand: you describe the app, Remy drafts the spec, and the methods and their interfaces are compiled from it.
- Adding a surface isn’t a new project—“also expose it on Discord” is a line in the plan, not a bot framework to wire up.
- Auth, validation, and errors are handled the same way on every surface, so a rule like “only admins can approve” holds whether the call comes from the web or an API.
- This is what full-stack means for a product agent: not “frontend plus backend,” but “one contract, every surface.”
- The exact code and manifest behind this live in the architecture deep-dive; this page is the what and the why.
A concrete example
Say your app has one method: submitVendorRequest. It takes a vendor name, some details, and an urgency level; it saves the request and notifies the procurement team. In Remy, you describe that in plain language and it’s compiled into a single backend method.
From that one method, the platform gives you—automatically:
- Web — a form in the app calls the method; the platform handles serialization and auth.
- REST API — the same method is a POST endpoint; the method signature is the API contract, so there’s no separate gateway or schema to maintain.
- Discord — it shows up as a slash command; no bot boilerplate or command registration.
- Telegram — the same, on Telegram; the platform presents the form and runs the method.
- MCP — connect the app to Claude (or any MCP client) and the method is a callable tool, its schema derived from the method signature.
- Cron — schedule the method to run nightly with a line in the plan; no separate worker.
- Webhook — route an incoming event (say, from Stripe) to the method; the platform verifies the signature and transforms the payload.
- Email — let people trigger it by emailing an address; the platform parses the message into the method’s inputs.
One method. Eight surfaces. Same logic, same database, same auth, same error handling. You define the contract once; the platform projects it everywhere. (The actual TypeScript and the manifest entries that declare each surface are in the architecture deep-dive.)
There’s also a ninth interface that works differently: a conversational Agent, an in-app LLM with its own personality and system prompt that orchestrates these methods as tools instead of projecting a single method onto a surface.
Why this matters: the interface-agnostic app
Built interface-first, every new surface duplicates logic, reintroduces auth bugs, and adds maintenance. Built method-first, the interfaces are projections of one contract—so they can’t drift from each other, because they’re the same method underneath.
That’s what “full-stack” actually means in a product-agent architecture: a set of methods reachable from a website, an API, a bot, a cron job, an email, and an AI agent’s tool palette, rather than a website with an API bolted on. Adding a surface isn’t a new project. You add a line to the plan.
It also changes auth from a per-interface chore into a single guarantee. If a method requires the admin role, that rule holds for a web user, a Discord user, and an API caller alike—the platform validates before the method runs, on every surface. Same for validation and errors: one method, one set of rules, consistently enforced everywhere.
How Remy generates this
You don’t write the method signatures or the interface wiring by hand. You describe the app—“employees submit vendor requests from the web, from Slack, or by email; each needs a vendor name, details, and urgency; notify procurement and log it”—and Remy drafts the spec, then compiles it into:
- a
submitVendorRequestmethod with typed inputs, - a database table with the right schema,
- a web form, a Discord command, an email handler, an MCP tool, and a REST endpoint,
- all wired to the same method.
You review the plan in plain language and approve it. “Make it accessible from Discord” isn’t an engineering project—it’s something the agent declares for you. That’s the architectural payoff of spec-driven development: the abstraction layer is high enough that surfaces are a property of the plan, not separate builds.
What you can build with it
- Internal tools with multiple entry points — approve requests from the web, from Slack, or by replying to an email; same method, three surfaces.
- AI agents with tool access — an assistant (via MCP) that queries your data, creates tasks, and updates records by calling methods your app already exposes—no custom API clients.
- Webhook-driven automation — route Stripe or form events to methods; the methods are the handlers, no separate service.
- Scheduled jobs with shared logic — a nightly report that calls the same method a user can trigger from a button; one code path, two triggers.
- Conversational interfaces — a Discord or Telegram bot where users check status or submit feedback by invoking methods; the bot is a projection of the app, not a separate codebase.
How this compares to other tools
The difference is how much work each surface takes, not whether other tools can reach them. Low-code platforms and coding agents make every interface a separate piece to configure or hand-write: a web app here, a webhook workflow there, a bot project of its own. Each surface is its own integration, with its own auth and its own chance to drift.
In Remy, the surfaces come from one contract. You describe the app once; the method is compiled once; the platform projects it onto every interface from the same plan. Adding the next surface is a line in the spec, not another project.
FAQ
Can I turn off interfaces I don’t need? Yes. The plan declares which surfaces are active. Don’t want a Discord bot? Don’t include Discord. The method still exists; it’s just not exposed there.
What if I need different behavior per interface? You can branch on the calling interface inside the method—say, a shorter reply for Discord and a longer one for email—but most of the time you don’t need to. The logic is the same; the platform handles how each surface sends and receives.
How does auth work across surfaces?
The same role rules apply everywhere. If a method needs the admin role, a web user, a Discord user, and an API caller all need it. The platform validates the caller before the method runs.
What happens when a method errors? The platform catches it and returns a consistent error on every surface—a JSON error to the API, a message in the bot, a tool error to the MCP client. Same error, surfaced appropriately.
Can I add a surface that isn’t on the list? If the platform supports it, yes—the architecture is extensible, and new interfaces can be added without changing existing methods.
Can I take the code elsewhere? The generated TypeScript is yours and the database is portable. The interface projections, auth, and deployment are the platform layer. The application logic travels with you; the convenience layer is what the platform provides.
The bottom line
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
The one-method-eight-interfaces model is one of the clearest examples of what a product agent actually is. You describe what the app does. Remy compiles the contract—the methods. The platform projects that contract onto every surface a user might reach for. You never write integration code, configure an API gateway, or parse a webhook by hand.
Remy is a product agent that compiles a plain-language plan into a full-stack app—backend, database, frontend, auth, and deployment—in a single step, reachable everywhere from one contract. Start building with Remy →
For the code and manifest behind this, read the architecture deep-dive; for the format you describe apps in, What is spec-driven development?.
