Relational backend systems
One backend serving your applications, your integration partners, your internal workflows and your reporting — on a single permission model, with auditing and event publishing from the first request.
The common API surface is running in weeks; the effort then goes into the rules that make your system different. Fixed price, deployed to your own AWS account under a licence you keep.
We can operate it under a separately scoped agreement, or hand it to your team.
A live API with the keys published. No signup.
What we build
In most relational systems the majority of routes do the same handful of things. We start from a proven backend framework that already handles those patterns, then concentrate effort on the behaviour that is specific to your business.
Create, read, update, archive, search, check access, record an audit trail, publish an event, return a consistent response — most routes are variations on these. Rather than rebuild that infrastructure route by route, we describe your data model, operations, relationships and access rules to the framework and generate it. You get a working, consistent foundation early, without locking out the customisation that comes next.
Standardised does not mean inflexible. The framework handles the common lifecycle consistently while providing clear extension points for customer-specific behaviour — some included as standard configuration, some quoted as custom work (see pricing):
Access control should not depend on every developer remembering every check. Tenant isolation is derived from how your data relates, so it is applied the same way on every route rather than re-checked by hand. The same permission model then determines what a user or integration may read, change and receive:
Important operations should leave a reliable history. Because auditing is part of the framework lifecycle, it does not need to be reimplemented for every endpoint:
Events are part of the framework, not an afterthought. Your system publishes business events from day one, to topics that are permissioned resources under the same model as your API — so what a user or integration partner may see through the API is what they may see through your events. A delivery connector hands those events to your platform — your Kafka, Amazon SNS or EventBridge — from where onward access is governed by your platform and shared with partners.
Integrations can also map their own IDs onto your records — namespaced and tenant-scoped — so third-party systems stay in sync without custom plumbing.
API documentation is generated from the same executable definitions that run the API, substantially reducing the risk of drift from the real behaviour. It is permission-aware: each consumer sees documentation for exactly the routes they are allowed to call — which makes onboarding your frontend team and your partners’ integration engineers faster and less error-prone.
Your system always defines and enforces its own permissions. Sign-in can come from your existing identity provider, and permission assignment — who holds which permission, in which part of your organisation — can be delivered with the system or driven from a system you already run. Identity and permissions are a pluggable seam, so moving between those arrangements later is configuration rather than a rewrite.
Your API is a stateless REST service behind a load balancer, so the application tier scales horizontally: Elastic Beanstalk adds and removes instances against real traffic, and the same deployment runs on one instance or on fifty. Nothing is pinned to a particular server, so there is no instance to outgrow.
The database scales on both axes. Read traffic — searches, lookups, partner queries — spreads across PostgreSQL read replicas. Write traffic moves up through larger instance classes. During discovery, we assess the expected workload, tune the application and database, and size the deployment accordingly.
Before any of that, we tune the software. Response views keep payloads to the fields a caller actually needs. Page sizes and expensive total counts are capped per endpoint. Filters are allow-listed so queries stay indexable. The audit trail can run in high-throughput mode instead of in-transaction, or move off the primary database entirely. Whether a given load problem is best answered in software or by scaling depends on your circumstances, and we work that out with you.
We are particularly well suited to software built around connected business data, where entities relate to one another:
Organisation
└─ Location
└─ Department
└─ Employee
└─ Timesheet
└─ InvoiceThese relationships often determine who owns a record, which tenant it belongs to, who may view or change it, which records appear in a search, and which events an integration partner may receive. Rather than reducing the system to disconnected endpoints, we design the API around those relationships.
Why us
Traditional API projects rebuild the same foundations every time — routing, validation, search, pagination, permissions, tenant checks, auditing, event publishing, documentation and error handling. We start with those already integrated. That doesn’t remove the need for careful modelling or custom engineering; it concentrates the effort where it creates value: your business logic, unusual access rules, specialised operations and integrations.
Our approach fits best when your product is built on a relational database, most routes follow repeatable business-data patterns, and you need a usable API surface quickly — but still need real customisation, consistent tenant isolation, auditing and secure event publishing for customers or partners. It suits teams who already have frontend, mobile or product capability and want a secure and well-engineered backend.
Where the framework fits — and where it doesn’t →
There is risk either way. Building internally gives you complete control, but requires experienced people, architectural decisions and an ongoing commitment to maintain everything you create. Starting from our foundation reduces staffing, architecture and delivery risk, but introduces a dependency on an external specialist.
The right decision depends on the capability you already have, how quickly you need to move and which risks your business is best placed to own.
| Consideration | Build internally | Start from the Custom APIs foundation |
|---|---|---|
| Architecture | Your team has complete design freedom, but must work through tenancy, permissions, auditing, events, integrations and operational concerns itself. Important mistakes may only become visible after the system is in use. | The principal has designed a scalable system with a production-proven multi-tenant architecture. The remaining risk is whether the approach fits your particular system, which we assess before committing to the build. |
| People | You develop the capability internally, but may need to recruit experienced backend and platform engineers or divert them from work already on your roadmap. | You can begin with relevant experience already available, without first committing to long-term hiring. The trade-off is a dependency on a specialist supplier. |
| Delivery | Delivery can be fast if the right team is already available. Otherwise recruitment, architecture and foundational engineering delay the business-specific work. | The common API surface can be running early because the foundations already exist. Custom rules, integrations and workflows still affect the complete delivery time. |
| Cost | Existing salaries can make the work appear inexpensive, but the real cost includes opportunity cost, maintenance, operational ownership and possible rework. | There is a visible upfront cost, followed by separately identified costs for support, operations and further development. It is most likely to be economically attractive when the alternative is assembling or redirecting equivalent specialist capability. |
| Fit and flexibility | Your team can design without framework constraints, provided it has the time and experience required. | The foundation is deliberately opinionated and best suited to relational, multi-tenant business systems. Discovery establishes whether it fits; sometimes building internally or choosing another platform will be the better answer. |
| Control and dependency | You control the application source, but still depend on employees, open-source and commercial packages, cloud services and retained internal knowledge. | You control the AWS account, infrastructure, data and application-specific source. The underlying Custom APIs library remains proprietary, but the licensed version runs in your account and does not depend on a hosted service operated by us. |
| Continuity | Supplier failure is avoided, but staff turnover, key-person dependency and loss of internal knowledge remain risks. | Your perpetual licence allows the delivered system to continue running and be redeployed without support. Framework patches and upgrades remain dependent on Custom APIs. |
| Operations | Your team owns monitoring, deployments, backups, incidents, security maintenance and capacity planning. | Your team can operate the system, or managed operations can be separately scoped. Responsibilities, response coverage and price are agreed explicitly. |
| Scale and performance | The system can be tailored precisely to the expected workload, but your team must design, test and operate the scaling strategy. | The system starts with a modest AWS footprint and known application and database scaling levers. Performance requirements still need to be established and tested, and higher traffic or resilience requirements increase infrastructure and operating cost. |
We have chosen to build a specialist practice around this work, taking on a small number of engagements so we can understand each business properly and remain accountable for what we recommend and build. Your system succeeding is how our practice succeeds. We will tell you if our approach is not the right fit, work with you to get the important decisions right, and remain available to support, evolve or hand over the result as your needs change.
Our process
Two of the five steps are optional. Which ones depend on how settled your architecture is, and who operates the system once it is live.
A conversation about your system, what you are trying to build, and an indicative range.
If the architecture decisions are still open, start here: what to build, where the boundaries between services fall, what to build versus buy, and in what order. From AUD $5,000. Read more.
From AUD $7,500 for a standard system of up to 15 models, where we model your domain together and produce the specification the build is priced against. You keep the model and specification whether or not you proceed. If you do, the discovery fee forms part of the Core Package price rather than adding to it.
Your team operates the system, or we agree a managed-operations arrangement scoped to its scale, resilience requirements and response coverage.
Pricing
Start with strategy before you commit to a build, or go straight to one. Both build packages deliver the same framework — secure, multi-tenant, audited, documented — and differ in how far we take it: one hands your team a working system to run themselves, the other is designed, deployed and operated by us in your AWS account.
From AUD $5,000 (ex GST)
For teams about to build. What your platform actually needs — the services, the boundaries between them, build versus buy, and how tenancy and access work across all of it.
From AUD $9,999 (ex GST)
For teams with their own platform capability. We build the API; you host and run it.
From AUD $40k (ex GST)
For teams who want the backend designed, built and deployed into their AWS account, with managed operations available under a separate agreement.
Comparing the two build packages:
| Feature | Handover | Core |
|---|---|---|
| Models | up to 5 | up to 15 |
| Tenancy | one layer | full relational paths |
| Identity | adapter to your identity and authorization service | your IdP, or a full user and tenant API |
| Role & permission endpoints | your system | included |
| Event publishing | — | one connector |
| Deployment | artifact handed to you | deployed to your AWS account |
| Who operates it | your team | your team, or us under a separate managed-operations agreement |
| Support | 3 months | first year, then $6k/yr |
| Licence | perpetual, for one defined API system | perpetual |
Support, licensing, continuity and the four ongoing cost categories are set out in the client guide.
About
We are a specialist backend practice for relational systems. Our work is deliberately narrow: secure, multi-tenant APIs with permissions, auditing and event publishing on one permission model, designed around the relationships in your data.
Sam Tuckey — Founder & Principal Engineer
The practice is led by Sam Tuckey, an engineer and architect based in Adelaide. Over seven years at H&L Australia (Valsoft Group) he led the move from on-premise legacy systems to multi-tenant cloud SaaS, and architected the Kafka-based event distribution platform that carries orders for more than 1,500 hospitality venues — including integrations with me&u and Uber Eats, peaking at around 70 orders per second in the Christmas trade. He was appointed interim CTO of Easy Employer during its post-acquisition integration into the Valsoft group, and earlier designed StraightSell’s accounting integration framework, still in production today.
The framework behind this practice is the result of that work: the permissions, tenancy, auditing and event publishing that every one of those systems needed, built once and properly, instead of rebuilt route by route. Connect with Sam on LinkedIn →
You retain full control of your system, infrastructure and data. Your system is delivered under a software licence that is yours to keep, runs in your own AWS account, and continues to run whether or not you keep a support subscription — with clear handover terms if you ever take it fully in-house. We take on a small number of engagements and stay with them: modelling the domain, delivering the common surface quickly, engineering the parts that are genuinely yours, and operating the result.
Contact
Whether you need a new API, want to modernise an existing relational application, or need secure event publishing for integration partners, tell us about the problem.
It helps to know whether the system already has a relational database, roughly how many entities are involved, whether it is multi-tenant, who needs access, and which parts require custom business logic.
Articles
Where we set out the thinking behind the framework, and how it compares with the other ways of building a multi-tenant API.