Host — the build layer

Your AI builds it. Waymaker runs it.

Built something with Claude Code, Cursor or Codex? The code took an afternoon. The database, the scheduler, the auth provider and the AI keys are what take the rest of the week. Deploy it somewhere those already exist.

See pricing

This is the whole thing

An Ambassador (a serverless function) that takes a webhook, classifies it with AI, and writes the result to your business database:

import type { AmbassadorHandler } from '@waymaker/ambassador-sdk'

const handler: AmbassadorHandler = async (request, ctx) => {
  const lead = await request.json()

  // Classify it. No provider key, no SDK to install.
  const { data } = await ctx.ai.edge.structured({
    prompt: `Categorise this enquiry: ${lead.message}`,
    schema: {
      type: 'object',
      properties: {
        intent: { type: 'string' },
        urgency: { type: 'string' },
      },
    },
  })

  // Write to the same table your team opens in Commander.
  await ctx.tables.insert('leads', { ...lead, ...data })

  return Response.json({ ok: true })
}

export default handler

No database to provision. No AI provider key. No connection pooling. The same handler runs on a schedule by declaring one, rather than by becoming a different piece of code.

The code was never the bottleneck

AI coding tools changed the economics of writing software and left the economics of running it untouched. On a generic platform, shipping that function means provisioning a database, configuring pooling, wiring environment variables, adding an auth provider, setting up a cron service, signing up for an LLM API and managing key rotation.

Every one of those is a solved problem somewhere, and none of them is the thing you set out to build. The stitching is now the expensive part, and it is expensive precisely because AI made the other part cheap.

What arrives injected

ctx.tables — your business database

Query, insert, update and delete against the same Tables your team uses in Commander. No connection string, no pooling, no second copy of the data.

ctx.ai and ctx.ai.edge — AI without provider keys

Full-strength generation, and fast structured output at the edge. Billed through your plan, so there is no separate account and nothing to rotate.

ctx.commander — the business record

Read goals, projects and team from the system the company already runs on, so a function can act on real context rather than an argument you passed it.

HTTP, schedule, manual — one handler, three triggers

The same function answers a webhook, runs on a schedule, or is invoked by hand. The trigger is configuration rather than a different piece of code.

The difference is not speed

Plenty of platforms host code well, and several host it faster than we do. What they cannot do is hand your function the company it works for. A function on a generic host knows the request it received and nothing else — so every useful behaviour starts by fetching and re-deriving state that already exists somewhere. Here the function starts with the business already in scope: the same tables your team opens, the same identity, the same AI budget.

When this is the wrong place to deploy

  • Long-running processes. Ambassadors are request- and schedule-scoped. Anything that must stay resident belongs on a container platform — Fly.io, Railway or Render.
  • A static site with no business data. A marketing page does not need a database injected into it. Any static host will serve you better and cheaper.
  • You want an editor. We are not an IDE. Build with Claude Code, Cursor or Codex — this is where what you build runs.
  • Nothing of yours is on the platform yet. Host works standalone, but the argument on this page is about your function reaching your business data. If that data lives elsewhere, most of the advantage is theoretical.

Frequently asked questions

Where should you deploy something you built with Claude Code?
Somewhere it can reach your business data without you rebuilding that data first. AI coding tools produce working code in minutes; what remains is a database, a scheduler, authentication and provider keys. A platform that supplies those already removes most of the work that is actually left.
Can you host AI-generated code on WaymakerOS?
Yes. Ambassadors (serverless functions) run code you wrote anywhere — Claude Code, Cursor, Codex or by hand. Each one receives a context object with your business database, an AI client and your organisation identity already injected, so the function starts with access rather than configuration.
Do you need to provision a database for an Ambassador?
No. Tables (the business database) is the same store your team already uses in Commander (the productivity suite), reached through ctx.tables inside the function. There is no connection string, no pooling configuration, and no separate copy of the data to keep in sync.
Do you need your own AI provider API key?
No. Ambassadors get ctx.ai for full-strength generation and ctx.ai.edge for fast structured output, billed through your plan rather than a separate provider account. That removes key management and rotation, which is usually the least interesting part of shipping an AI feature.
What is WaymakerOS not good for?
Long-running processes and anything that must stay resident. Ambassadors are request- and schedule-scoped, so a persistent worker or a container that holds state between invocations belongs on Fly.io, Railway or Render. A static marketing site with no business data behind it does not need any of this.

From $19 per user per month, with every tier including all 20 Commander tools. More on the build layer in our build and host guide, and on pricing.