What is FartherShore
Build programmable businesses — define, enforce, meter, and bill a software product as code.
Build programmable businesses — define, enforce, meter, and bill a software product as code.
FartherShore is a platform for building programmable businesses, starting with software. You describe a sellable product — its surfaces, plans, pricing, usage meters, and access rules — as a single TypeScript class, and FartherShore runs the business around it: a hosted customer frontend, subscriptions and checkout, per-customer API keys, usage metering, and an edge gateway that enforces every plan in front of the API you already run.
The whole product is code. There is one authored file —
product/product.config.ts — containing one decorated @Product class. You
build it locally, push it, and FartherShore compiles it to a deterministic
Manifest IR, validates it against the live platform contract, and applies it
to the edge. No dashboards-as-source-of-truth, no YAML, no hand-wired billing.
Everything FartherShore does for a product falls into four verbs, all expressed in the same class:
@Feature, @Meter, @Plan, …).@farthershore/backend.This is the canonical example used throughout these docs — CronCloud, a managed cron-jobs product. One class defines the meters, the gateway routes, the capability they require, and two plans that grant it:
import {
Product,
Requests,
Meter,
Resource,
Capability,
Feature,
Plan,
capabilityGrant,
} from "@farthershore/product";
@Product({
name: "croncloud",
origin: "https://api.example.com",
displayName: "CronCloud",
description: "Managed cron jobs",
})
export default class CronCloud {
@Requests()
requests!: unknown;
@Meter("compute", { display: "Compute", unit: "ms" })
compute!: unknown;
@Resource("cron_jobs", { display: "Cron jobs", countSource: "action_inferred" })
cronJobs!: unknown;
@Capability("managed-cron", {
title: "Managed Cron Jobs",
includesFeatures: ["cron-jobs"],
})
managedCron!: unknown;
@Feature("cron-jobs", {
description: "Cron job CRUD",
plans: ["starter", "pro"],
routes: {
"GET /v1/cron-jobs": {},
"POST /v1/cron-jobs": {},
"DELETE /v1/cron-jobs/{id}": {},
},
})
cronJobsFeature!: unknown;
@Plan("starter", {
name: "Starter",
price: { amount: 2900, currency: "usd", interval: "month" },
grants: [capabilityGrant("managed-cron", { limits: { cron_jobs: 10 } })],
limits: { requests: { rate: 600, interval: "minute", enforcement: "enforce" } },
})
starter!: unknown;
@Plan("pro", {
name: "Pro",
price: { amount: 19900, currency: "usd", interval: "month" },
grants: [capabilityGrant("managed-cron", { limits: { cron_jobs: 100 } })],
limits: { requests: { rate: 6000, interval: "minute", enforcement: "enforce" } },
})
pro!: unknown;
}
From that one file you get: two priced plans in Stripe, a gateway that only
admits cron-jobs callers whose plan grants managed-cron, per-minute rate
limits, a compute usage meter, and a hosted frontend — without writing any of
that infrastructure yourself.
A business defined as code is reviewable, diff-able, and reproducible. The same
@Product class compiles to byte-identical IR every time (the build runs twice
and rejects drift), so a pricing change is a pull request, a route addition is a
commit, and going live is one command. Humans edit it in an editor; agents
operate it through the CLI — both drive the exact same
compile and apply path.
FartherShore manages the contract (plans, routes, meters, pricing) as code in your product repo. Operational actions on live state — connecting Stripe, migrating subscribers, minting tokens — happen through the CLI or dashboard, not the manifest.
@Product class, the Manifest IR, and edge enforcement.