Technology

The stack behind the systems we ship.

What we use, where it sits in the architecture, and what it is responsible for. Selection is per project — nothing here is a requirement for every engagement.

Runtime

How a request moves through the system.

Two paths run in most systems we build: the synchronous request a user waits on, and the asynchronous work that happens behind it.

Synchronous — user-facing request

Client Browser or Android application
Edge TLS, routing, static assets
API Auth, validation, routing
Service Business logic
Cache Frequent reads
Database Persistent state

Asynchronous — background work

Trigger Schedule, event or webhook
Job Runner Queued or scheduled task
Integration Third-party API exchange
Data Store Processed output
Reporting Analytics and exports

Architecture layers

Seven layers, each with a defined responsibility.

Keeping responsibilities separated is what makes a system possible to change later without rewriting it.

Mobile

Native Android clients, built to work with the same APIs the web application consumes.

Android Kotlin Android SDK

Frontend

Interfaces built on web standards, kept light so they load quickly on real networks and devices.

HTML CSS JavaScript Responsive layout

Backend

Application logic, background processing and the services that hold the rules of the business.

Node.js Python Microservices

APIs

The contract between clients and services — versioned, authenticated and documented for the teams consuming it.

REST APIs JSON Token authentication Webhooks

Infrastructure

Where the software runs. Containerised services on Linux, with a deployment path that can be repeated.

Docker Linux OpenLiteSpeed Cloud deployment Caching

Data

Storage and query layers, chosen for how the data is written and how it will be read back.

Firebase BigQuery Structured storage

Automation

Scheduled jobs, integrations and data pipelines that remove repeated manual steps from an operation.

API integrations Workflow automation Scheduled jobs Data pipelines

Product and platform names are listed to describe our working technology set. They are the trademarks of their respective owners and their inclusion does not indicate any partnership, endorsement or certification. See our disclaimer.

Operating choices

Constraints we apply to every build.

Dependencies stay justified

A library is added when it removes more risk than it adds.

Interfaces before implementation

API contracts are agreed before the services behind them are written.

Environments stay separated

Development, staging and production hold their own configuration.

Secrets stay out of the codebase

Credentials are supplied by the environment, never committed.

Deployments are repeatable

A release is a documented procedure, not a manual sequence.

Data movement is explicit

Every integration states what it sends and what it stores.

Have a software problem worth solving?

Share the requirement, the constraints and the systems it has to work with. We will tell you what it takes to build.