Client guide
Last updated: 5 August 2026
This guide sets out what you receive and own, how the licence works, what happens if support ends, what the ongoing costs are, and the configuration included as standard. It is the detail behind the packages described on the pricing page, and it applies to every engagement unless your agreement says otherwise.
You receive the source code for the application-specific parts of your system, together with its data model, database migrations and deployment materials. That code is yours. Your team, or another supplier, may maintain and extend it.
The underlying Custom APIs framework remains our proprietary software. It is supplied as a versioned library under a perpetual licence for one API system. The library itself cannot be modified, or used to build a separate API system, without an additional licence.
| Component | Owned by | Delivered as | You may modify |
|---|---|---|---|
| Application-specific service code | You | Source code | Yes |
| Custom operations and integrations | You | Source code | Yes |
| Data model, database schema and migrations | You | Complete source files | Yes |
| Deployment configuration and documentation | You | Complete files | Yes |
| Custom APIs framework library | Custom APIs | Versioned package or artifact | No |
| Framework generators and internal development tooling | Custom APIs | Not included unless agreed | No |
Changes you write remain within the licence when they form part of the same licensed system, but they are not automatically covered by support. Changes can be reviewed and incorporated into a new supported baseline by agreement.
Owning your application code does not carry a right to distribute it to others to run. That code depends on the licensed library and cannot run without it, so supplying it — or anything derived from it — to another organisation means that organisation needs its own licence. You cannot build a generic system on the framework and roll it out to other companies under your licence alone.
The licence permits use of the Custom APIs framework in one API system, identified at delivery by name and business purpose.
Within that system you may scale it, configure it, and add, change or remove routes and code — it remains the same licensed system as it evolves. The licence covers every environment that system requires, any number of instances and regions, and any number of tenants.
Any additional API built on the framework requires its own licence, including one serving a different function of the same business — a separate reporting, administration or partner API, for example. This applies regardless of whether it serves the same product, business or customer.
| Usage | Covered by the licence? |
|---|---|
| Development, staging, sandbox, production and disaster-recovery environments for the licensed system | Yes |
| Multiple instances, availability zones or regions used for that system | Yes |
| Any number of tenants using the licensed multi-tenant system | Yes |
| Adding, changing or removing routes and code within that system | Yes, although your changes are not automatically supported |
| A separate API for another product or business area | No — an additional licence is required |
| A separate API serving another function of the same business, such as reporting or administration | No — an additional licence is required |
| Forking the system to operate it independently | No — an additional licence is required |
| Supplying your application code to another organisation to run, or rolling the system out to other companies as a product | No — each organisation running it requires its own licence |
The route manifest produced at handover records what was delivered. It is evidence of the system as built, not a limit on how it may change.
Your system continues to run in your AWS account under its perpetual licence. The exact framework package used by the system is retained with your deployment, together with the application source and the materials needed to rebuild and redeploy it without access to us.
Your team or another supplier can continue maintaining the application-specific code. Framework patches, compatibility updates and upgrades stop unless support or another continuity arrangement is in place.
Every engagement is delivered with:
The hosting figures on the pricing page cover AWS infrastructure only. Four separate categories make up the cost of running and evolving the system.
| Cost | What it covers | How it is charged |
|---|---|---|
| AWS infrastructure | Compute, database, networking, logs, identity and storage | Paid directly by you to AWS |
| Framework support | Delivered-system defects, security patches, compatibility updates and framework upgrades | Included for the stated initial period, then optional annual renewal |
| Managed operations | Monitoring, deployments, backup oversight, incidents, capacity and cost management | Separately scoped according to responsibility, scale, resilience and response coverage |
| Custom development | New models, operations, integrations, workflows and other functionality | Quoted separately before work begins |
Your system runs in your own AWS account, billed by AWS directly to you, at cost. This is the entry configuration — the minimum a production deployment runs on. Each component scales independently, along known application and database scaling paths.
| Component | Entry spec | ~Monthly |
|---|---|---|
| Load balancer | 1 ALB | $17–25 |
| Application server | Elastic Beanstalk, 1 small instance (auto-scaling) | $12–15 |
| PostgreSQL database | Small, single-AZ, 20 GB | $15–30 |
| User sign-in (Cognito) | Standard | $0–15 |
| Logs, metrics, DNS, storage | — | $5–15 |
| Production total | ~$50–100/mo | |
| Development environment | Smaller instances | +$25–40/mo |
| Both environments, typical | ~$100–180/mo |
During discovery we size the initial deployment to your expected load; scaling up then follows known application and database scaling paths. From here the application tier auto-scales across as many Beanstalk instances as your traffic needs, read load moves onto PostgreSQL read replicas, and the primary database steps up through larger instance classes. Once the system is business-critical we recommend a Multi-AZ database for zone-failure resilience. Figures indicative, reviewed quarterly, billed by AWS directly to your account.
Standardised does not mean inflexible. Everything below is included as standard in both the Handover and Core packages, specified during discovery and fixed at sign-off. Changes after sign-off are quoted as change requests.
* Reviewed during discovery — this choice affects system performance and is agreed jointly.
† Core Package only. The Handover Package does not include event publishing or integration connectors; external keys and endpoint redirects are available in both.