SaaS platforms
Multi-account products where one organisation runs several businesses, each with its own data, permissions, branding and currency.
- Tenant isolation
- Roles and permissions
- Billing and plans
- Audit trails
02What we do
From product idea to production system.
We design and build software products, and we run them. That is the whole job: the interface somebody uses at 23:00, the data model underneath it, and the deployment that has to survive the weekend.
02What we build
From product idea to production system.
We are not a front-end shop that hands off an API contract. The data model, the interface, the deployment and the thing that pages somebody at midnight are all our problem.
Applications people work in
Web and mobile applications for the people doing the job, not for the demo. Built for a busy shift, a bad connection and a cheap tablet.
- Angular and TypeScript
- Capacitor for Android
- Desktop with Electron
- Design systems
Offline-capable systems
Devices that keep trading with no connection and reconcile without duplicating anything when the line comes back.
- Local-first storage
- Ordered write queues
- Idempotent replay
- Conflict rules
Realtime systems
Sockets where they earn their place: a seat going grey as somebody else takes it, a till and a stock room agreeing within the second.
- WebSocket events
- Live availability
- Presence and status
- Push notifications
Architecture and backend
The part nobody sees and everybody feels. Data modelled once, migrations that are reversible, and reporting that refuses to invent a total.
- Node.js and TypeScript
- MySQL and PostgreSQL
- Migrations
- Reporting models
APIs and integrations
Public APIs other people can build on, and the unglamorous work of making two systems that were never designed to meet agree on a record.
- Documented public APIs
- Scoped API keys
- Payment providers
- Embeddable widgets
The toolkit
Chosen for the job, not for the CV.
A short list, used properly. We would rather go deep on a stack we can operate than collect frameworks we have to relearn every project.
Product
- Discovery
- Product design
- Interface design
- Design systems
- Prototyping
Engineering
- Angular
- TypeScript
- Node.js
- Fastify and Express
- MySQL and PostgreSQL
- WebSocket
- Capacitor
- Electron
Operations
- Docker
- CI and deployment
- Monitoring
- Backups and migrations
- Support
How an engagement runs
Four steps, and no theatre.
Most of the risk in a build is decided before anybody writes code. This is where we spend the effort.
- 01
We work out what it actually is
Before anything is estimated we get to the shape of the thing: who uses it, what it has to survive, and which parts are genuinely hard. Most projects get smaller at this stage, not larger.
- 02
We design it as a system
The data model and the interface are decided together, because a screen that needs three tables to agree is a data problem wearing a design costume.
- 03
We build it in production shape
Containerised, migrated, monitored and deployed from the first week. There is no separate hardening phase, because there is no prototype to throw away.
- 04
We hand it over, or we keep running it
The codebase comes with its rules written down and a build that enforces them. Take it in-house, or leave it with us and keep shipping.
What tends to fit
A product or platform, not a brochure with a form on it Something with real complexity: data, devices, money or scale A team that wants the thing to still be maintainable in three years
How we build
Built for production.
Not a manifesto. These are the six rules our own codebases are audited against, and the reason a product we shipped years ago is still one somebody can change.
- 01
One record, not four copies
Most integration pain is the same thing existing twice. We would rather model it once and let every surface read from it than reconcile two versions of the truth on a Monday morning.
- 02
Assume the connection fails
A door and a till have to work at the worst moment of the night. Offline is designed in from the data model up, with ordered queues and idempotent replay, not bolted on as a retry.
- 03
Simple on the surface, serious underneath
Complexity belongs in the architecture, not in the interface. If somebody needs training to check a guest in, we built it wrong.
- 04
Numbers you can defend
A report that cannot show its working is a liability. Figures trace back to the records that produced them, and a total we cannot justify does not get rendered.
- 05
Built to be changed
Our products are years old and still moving. Conventions are written down, the rules are enforced, and the codebase stays something a new pair of hands can read.
- 06
We operate what we ship
The same people who wrote it run it in production. That is the shortest possible feedback loop between a bad decision and the person who has to live with it.
Selected client work
Building something of your own?
We occasionally work with companies that need a product, platform or system built properly. Same engineering standards we use on our own products, same people writing the code.
Start a project
Venue and ticketing site
Centrestage @ Baywest
The public site for a comedy, theatre and events venue in Gqeberha. Show listings, a three-step ticket checkout with customer accounts, venue tours and corporate enquiries, wired straight into EventSync so bookings land where the venue already works.
- Angular
- Node.js
- MySQL
- WebSocket
- Docker
Creative studio site
RC-Creations
A bilingual German and English site for a content and social advertising studio. Services, a portfolio, a blog and enquiry handling, with the language choice carried across every page and all content managed from a private admin area.
- Angular
- Node.js
- MySQL
- Docker
Build with us
Have something worth building?
Send us the shape of the problem. We will tell you what we would build, roughly what it takes, and whether we are the right people for it.