Skip to content

Capabilities

Six capabilities, each with its evidence.

What we build in each, how we approach it, and what we have actually delivered. Every capability carries its evidence tier and links to the work behind it — and robotics says plainly that it is Lab.

Evidence: Proven
Shipped, with a case study or project
Evidence: Core
Repeated work
Evidence: Capable
We can engineer it; no delivery yet
Evidence: Lab
Research or prototype only

Software engineering

Software that becomes infrastructure for your business.

Web platforms, mobile apps and the backends behind them — built to be depended on, not demoed. We design the data model before the screens and the failure modes before the features.

What we build

  • Web platforms
  • Mobile applications (React Native)
  • Backend systems (NestJS, Django)
  • APIs and integrations (REST, GraphQL, gRPC)
  • Real-time platforms
  • Multi-tenant SaaS (Postgres row-level security)

How we approach it

  • The data model is designed before the screens.
  • The failure modes are named before the features.

Evidence

Software engineering: a layered stackFour layers — interface, API, services and data. A request flows down from the interface to the data, and the response flows back up.InterfaceAPIServicesDatarequestresponse
Four layers — interface, API, services and data. A request flows down from the interface to the data, and the response flows back up.

AI & automation

Turn intelligence into action.

Models are the easy part. The work is deciding when a model should run at all, what it costs when it does, and what happens when it is wrong.

What we build

  • AI agents with a human hand-off
  • LLM applications
  • Retrieval and search
  • Intelligent workflows
  • AI services built to plug into a larger product
  • Document intelligenceEvidence: Capable

How we approach it

  • Classify before paying for inference: a model runs only when the request needs one.
  • Know what a call costs before it ships, and route to the smallest model that does the job.
  • Plan for the model being wrong: guardrails, a log of every decision, and a hand-off to a person.

Evidence

Evidence: Proven

Shipped: WarmChats, and the restaurant search. Its figures are below, each labelled.

AI & automation: a router in front of the modelA request reaches a router, which sends it down one of three lanes — keyword search, the model, or the cache — and the result becomes an action.RequestRouterKeywordModelCacheActionclassified before any paid inference
A request reaches a router, which sends it down one of three lanes — keyword search, the model, or the cache — and the result becomes an action.

ERP & enterprise systems

One system for complex operations.

When HR, finance, inventory and sales live in separate tools, every report is a reconciliation. We design them as modular platforms, where each department is a module over one shared model of the business.

Modules, drawn connected

  • HR
  • Finance
  • Inventory
  • Procurement
  • Operations
  • Sales
  • Reporting
  • Workflows
  • Multi-branch

How we approach it

  • One shared model of the business under every module, so a report is a query, not a reconciliation.
  • Each department is a module with its own boundary.
  • Branches are part of the model from the first schema.

Evidence

Evidence: ProvenHR and payrollEvidence: CapableFull ERP

Proven for HR and payroll: Balanzify's microservices. Full ERP is Capable — designed in our point-of-sale back-office plans, not yet delivered.

Linked work

ERP: modules around one data coreHR, finance, inventory, procurement, operations, sales, reporting, workflows and multi-branch sit on a ring, each connected to one shared data core.HRFinanceInventoryProcurementOperationsSalesReportingWorkflowsMulti-branchShareddata core
HR, finance, inventory, procurement, operations, sales, reporting, workflows and multi-branch sit on a ring, each connected to one shared data core.

POS & commerce

Commerce systems built around real operations.

A point of sale isn't a billing screen. It's the front end of stock, staff, kitchen, payments and reporting — and it has to keep selling when the internet drops.

What we build

Restaurants today, with retail and pharmacy in development — ordering, billing, receipts and offline sync built; inventory, multi-branch and reporting in our back-office plans.

  • Restaurant point of sale
  • Ordering
  • Billing
  • Receipts
  • Offline sync
  • Retail and pharmacy point of saleEvidence: Capable
  • InventoryEvidence: Capable
  • Multi-branchEvidence: Capable
  • ReportingEvidence: Capable

How we approach it

  • Offline first: the till keeps selling when the network drops, and syncs when it returns.
  • The hardware at the counter is part of the system, receipt printers included.
  • A sale is the start of the work, not the end of it: the back office reads from it.

Evidence

Evidence: Core

We've built point-of-sale systems for restaurants, including offline sync and receipt-printer integration, and we're building a multi-tenant platform for retail and other verticals.

POS & commerce: the till at the centreThe till sits at the centre, connected to stock, kitchen, receipts and reports. An offline queue holds sales while the network is down and syncs them when it returns.StockKitchenReportsReceiptsTillsyncs on reconnectOffline queue
The till sits at the centre, connected to stock, kitchen, receipts and reports. An offline queue holds sales while the network is down and syncs them when it returns.

Robotics & intelligent systems

Bringing intelligence beyond the screen.

The same engineering that runs a business can run a machine: sensors in, decisions made, actions out. The software side is where we'd start — computer vision, control interfaces, telemetry, and the systems that connect machines to the rest of the business.

We engineer software for machines; we don't manufacture hardware. We haven't delivered robotics work yet, and nothing here is a shipped system — ask us and we'll tell you exactly what exists today.

What we'd build

  • Robotics software
  • Computer vision
  • Machine intelligence
  • Connected and sensor-driven systems
  • Software-to-machine integration

How we’d approach it

  • We'd start with the software side: vision, control interfaces and telemetry.
  • A machine's events would reach the systems that act on them.
  • Before anything is scoped, we tell you exactly what exists today.

Evidence

Evidence: Lab

No robotics, drone or computer-vision system has been delivered yet.

Robotics: from sensor to machineA sensor feeds a vision model, which informs a decision, which a controller turns into an action on the machine. A concept, not a shipped system.SensorVisionDecisionControllerMachinefeedbackconcept: not a shipped system
Concept — not a shipped systemA sensor feeds a vision model, which informs a decision, which a controller turns into an action on the machine. A concept, not a shipped system.

Cloud, data & infrastructure

The systems behind the systems.

Every product above runs on something. We design databases, APIs, containers, CI/CD and observability so the system can be released on a Tuesday afternoon without anyone holding their breath.

What we build

  • Cloud deployment (Vercel)
  • Databases (PostgreSQL, Redis)
  • Containers (Docker, Docker Swarm)
  • CI/CD (GitHub Actions)
  • Observability (metrics and structured logging)
  • Security-conscious architecture (row-level security, JWT)

How we approach it

  • Every change takes the same path: commit, build, test, deploy, observe.
  • Tenancy and access are enforced in the database, not only in the application.
  • Metrics and structured logs ship with the first release, not after the first incident.

Evidence

Evidence: Core

It runs under the work above: Go Style Business deploys on Docker Swarm, and the restaurant search runs on PostgreSQL with row-level security and Redis.

Cloud, data & infrastructure: the release pipelineA change moves from commit to build, test, deploy and observe; what observation finds feeds the next commit.CommitBuildTestDeployObservewhat it finds feeds the next commit
A change moves from commit to build, test, deploy and observe; what observation finds feeds the next commit.

Have a complex problem?

Let's turn it into an engineered system.

Schedule a CallTell Us About Your Project