Skip to content
rbsolutions.works

How we build

These are the positions that shape every system on this site. They are opinions, held for reasons, and they are what you are actually hiring.

01

Deterministic where mistakes cost money

A language model is excellent at understanding what someone wants and unaccountable for the number it produces. So we draw the boundary deliberately: the model interprets, and ordinary code decides.

The blunt version of that promise: an AI assistant built this way cannot hallucinate a freight quote, because the model never touches the quote. It routes the request; a pricing function answers it.

The same instinct shows up away from AI. Print layout dimensioned in millimetres rather than pixels. Status derived from a scan that actually happened rather than a field somebody edits. When something has to be right, it should not depend on anything being clever.

02

Access control belongs in the database

Roles enforced in the interface are a suggestion. Anything that can reach the API can ignore them.

So permissions live in Postgres row-level security, which means they hold whether the request arrives from the web app, a mobile app, or a script somebody writes in two years. In one system, the same tests that assert accounting can open the reports also assert that housekeeping cannot.

03

The test suite is the release gate

Every release runs unit tests, database-level tests and browser-driven journey tests, with a coverage report that fails the build when it slips and a drift check that catches a schema change nobody wrote a test for.

This is the least glamorous thing on this page and the one that matters most over a five-year horizon. It is the difference between a system you can keep changing and one everybody becomes afraid to touch.

04

Schemas are the product, and they have to move

Operational software accretes rules — new stages, new exceptions, new pricing. A schema that cannot evolve safely quietly becomes the reason the business cannot change.

So migrations are reversible and shipped continuously. One platform here is more than eighty migrations deep and still in daily production use.

05

Built for the market it serves

Payment rails, identity checks and devices are local questions, not defaults. A card-first checkout in a market that pays by e-wallet is a foreign product wearing local branding.

One system here deliberately has no online gateway at all, because its guests pay by transfer and upload a receipt — so the software accepts what actually happens instead of charging fees on a flow that was going to occur over a messaging app regardless.

06

On the edge, at near-zero idle cost

Everything runs on Cloudflare's global network. For a business selling across borders that is a revenue question rather than an infrastructure preference: the page is fast in the market you are selling to.

It also means a small product does not carry a server bill while it is finding its customers.

working together

Most engagements start with one operational problem that is costing real money — paperwork re-keyed between offices, a booking flow leaking to aggregators, invoices assembled by hand. We build that, put it in production, and expand from there.

Start a conversation →