GBCORP BLOG · IT SERVICES
Backend Development: The Part of the App Nobody Sees
The screens get the attention. The backend gets the blame. It stores the data, enforces the rules, talks to the other systems and keeps running at three in the morning. This is how GBCORP builds one.
Backend development is the work behind the screens: the database, the rules that decide who may do what, the functions that run when something happens, the APIs the apps and partners call, the scheduled jobs, the logs and the monitoring. GBCORP builds backends on a managed cloud project per client, one per business, in the business’s own name, with the same components its own products run on. The apps, the web and the consoles all talk to that one backend, which is why a change ships everywhere at once.
What a backend is made of
| Part | What it does | Source |
|---|---|---|
| Data | Managed database with a documented model; backups; exports | Managed |
| Rules | Who may read or write what, enforced at the database, not only in the app | Written per project |
| Functions | Code that runs on events: an order placed, a payment confirmed, a file uploaded | Written per project |
| APIs | Endpoints for the apps, the web, partners and integrations, with keys and limits | Written per project |
| Jobs | Scheduled work: reports, reminders, reconciliation, clean-up | Written per project |
| Operations | Logs, monitoring, alerts, cost reports | Managed |
Rules at the database, not in the app
An app can be modified by anyone who installs it. The backend cannot. So the rule that a customer sees only its own orders, or that a staff member cannot change a price, lives in the database rules and the functions, and the app merely respects it. GBCORP writes those rules per project and tests them with the same care as the screens, because they are the security of the product.
Managed where it can be, written where it must be
Sign-in, database, storage, hosting, queues and monitoring are managed services, which means no servers to patch and costs that scale with use. The business’s own logic, its data model, its rules, its functions and its integrations, is written for it and documented. The result runs for a small business at a few dollars a month and for a platform at scale without a rewrite.
APIs for apps and partners
The apps call the backend through documented endpoints. Partners and integrations call the same endpoints with their own keys, rate limits and permissions. Webhooks notify other systems when something happens. A business that later wants an integration with its accounting or logistics system already has the API; the integration is a release, not a rebuild.
Checklist for a backend that lasts
- A documented data model with the questions it must answer.
- Rules written and tested per role.
- Backups running and restore tested once.
- Monitoring with alerts to a person before the client notices.
- Costs reported monthly per component.
- Everything in a cloud project in the client’s name.
The numbers to expect
A backend for a configured app exists on day one. A custom backend is built inside the first release, in eight to twelve weeks at a fixed price with the app it serves. Running costs are the cloud project’s usage, reported monthly. Customised or more complex functionality is quoted separately before any work starts.
A worked example
A field-services company has an app built by a previous developer with the data on a server nobody wants to touch. The scoping week maps the data and the app’s calls. GBCORP builds a new backend in a cloud project in the company’s name: a documented model, rules per role, functions for job assignment and completion, an API the existing app calls, and a nightly job that produces the invoicing file. The data is migrated over a weekend. The old server is switched off a month later, and the company has a backend that any team can read.
Integrations and webhooks
Every integration is an endpoint or a webhook: the accounting system receives invoices when a job closes; the logistics provider receives a shipment when an order is packed; the payment gateway notifies the backend when a payment settles. Each has a key, a log and a retry. A failed call is visible in the console with the payload, so a support engineer fixes it from evidence rather than from a customer’s complaint.
Cost and scale
Managed components bill by use: a small business pays a few dollars a month; a platform pays in proportion to its traffic. GBCORP reports the cost per component monthly and designs the data model and the jobs to keep it flat: reads served from cache, images sized once, reports produced nightly rather than on every open. A backend that costs more as it grows was designed for the demo, not for the business.
Backups and the restore test
Backups run daily and before every migration, to a separate location, retained for the period the client sets. Once a quarter, a restore is performed into a test project and checked, because a backup that has never been restored is a hope. The report to the client says when it was last done.
Documentation a new team can read
The data model with each field’s meaning. The rules per role. Each function’s trigger and effect. Each endpoint with its parameters and an example. The jobs and their schedules. Runbooks for the alerts. Delivered with every release, in the client’s repository, so a new team continues rather than reverse-engineers.
Ownership of the backend
The cloud project, the data, the code and the documentation are the client’s. Keys and credentials are held in the client’s own secret store. No credentials are retained by GBCORP after a hand-over unless a support contract requires them.
Questions we hear first
Can you build a backend for an app someone else made?
Yes. The scoping week maps the app’s needs, and the backend is delivered with an API the existing app can call.
Which cloud do you use?
A managed cloud project in the client’s name, with data residency chosen per client; the components are conventional so any competent team can continue the work.
Who owns the backend?
The client: the project, the data, the code and the documentation.
What happens when traffic grows?
Managed components scale with use; the rules and functions were written for that from the start.
Where to start
The GBCORP software development hub sets out the method; the GBCORP Custom App Development product is the priced starting point. For the web side of the same backend, read custom web application development explained.
GBCORP operates across 17 countries on 4 continents through six pillars: AI & IT, Innovation, Sustainability, Infrastructure, Premium Business, and EV's & Solutions.
