Who it is for
Owners and operations leads whose real process lives in spreadsheets, email threads and people’s heads.
Home / Capabilities / Systems Development
Capability 01
Systems built around how your business actually runs
For businesses that have outgrown off-the-shelf tools. When your team runs on workarounds, we build the one system that replaces them, from where the data lives to the screen your staff uses every day.
Who this is for, and what you get
The problem
Each tool holds part of the truth. Staff copy the same details between them, and mistakes show up when a customer is already waiting.
What you get
One working system shaped to your process, with a staff console, your source code and written instructions for running it.
What we build
What this covers
Operational platforms
One place for orders, bookings, members, content or equipment, shaped to how you work instead of a vendor’s template.
Admin consoles
The control room your staff runs the business from: who can do what, what is happening now, and what needs attention.
Real-time services
Live data, voice and video, plus a saved to-do list for background work, so nothing is lost if a server restarts.
Hardware integration
Software that controls physical things. For RoboPark we built a motion layer that lets animatronic robots run approved, named actions only.
Consolidation
Separate systems and disconnected tools merged into one platform, without losing what already works.
Third-party integration
Payment providers, customer records, messaging apps and other outside services connected through one tidy entry point.
Sample architecture
How it fits together
The diagram, step by step
Follow one customer order through the system
Picture a sample bike repair shop with three locations. A customer books a service and pays online. Here is what each box in the diagram does with that order. Use the buttons above the diagram to watch other requests travel the same path.
-
People start the work
- What happens
- A customer places an order, or a staff member changes one.
- Who does it
- Your customers and staff, each signed in with their own permissions.
- Why it matters
- A mechanic can see the repair queue without being able to change prices.
-
Two screens, one system
- What happens
- Staff use the admin console. Customers use a website or app. They are different views of the same information.
- Who does it
- The admin console and the customer app.
- Why it matters
- Without this, staff retype website orders into another tool, and that is where errors creep in.
-
One set of rules checks it
- What happens
- The API (the single doorway every screen goes through) checks who is asking and whether the request is allowed.
- Who does it
- The service layer, automatically, on every request.
- Why it matters
- A rule such as “no discounts over the limit” is written once and applies on every screen.
-
Slow work joins a saved queue
- What happens
- Tasks that take time, such as resizing a photo of the bike, go onto a to-do list stored safely. These are the “durable jobs”.
- Who does it
- A background worker program.
- Why it matters
- If the worker restarts, the job waits and carries on. Try the restart switch above to see it.
-
The record is saved
- What happens
- Order details go into the database (Postgres). Photos and documents go into file storage.
- Who does it
- The database, which applies its own access rules row by row.
- Why it matters
- One true record of each order, instead of three versions in three tools.
-
Payment happens off-site
- What happens
- The customer pays on a checkout page run by the payment provider.
- Who does it
- The payment provider. Our system only receives the result.
- Why it matters
- Card details do not sit on your system, so there is far less to protect.
-
Devices get their orders
- What happens
- If the business uses equipment, the same queue sends it commands, one at a time.
- Who does it
- The job worker, through the system’s approved commands only.
- Why it matters
- Machines and sensors follow the same rules as staff. Not every business needs this step.
Consolidation
One system of record
Separate systems and disconnected tools merged into one platform, without losing what already works.
- Spreadsheets
- Email threads
- Vendor app
- Shared drive
- Paper forms
- Old database
Separate tools One platform
How to read this demo
What moving the slider shows
Drag the slider from “Separate tools” to “One platform”. The tiles are typical places a business keeps its information. They are examples, not a real client’s setup.
-
Separate tools
- What happens
- Information is scattered: a spreadsheet here, a shared drive there, an old database nobody wants to touch.
- Who does it
- Your staff, who carry details between tools by hand.
- Why it matters
- Without a change, two tools can disagree and nobody knows which one is right.
-
Moving across
- What happens
- We map what each tool holds, connect what should stay, and migrate the rest into the new system.
- Who does it
- Our team, working with the people who use each tool today.
- Why it matters
- What already works is kept, instead of being thrown out with the old tools.
-
One platform
- What happens
- All of it now sits in one system of record: the single place your team trusts for the answer.
- Who does it
- Your staff, through the admin console.
- Why it matters
- Staff stop asking which file is the latest one.
Process
How the work runs, step by step
- 01
Map the operation
We walk through the real workflow with the people who do it and find where the work breaks down.
- Who does it
- Our team, with your staff.
- What you get
- The system fits the job as it is really done, not as a manual describes it.
- 02
Design the system
We plan how data is stored, how the parts connect, who can do what, and what happens when something fails. You agree it before the build starts.
- Who does it
- Our team, with you signing off.
- What you get
- Big decisions get settled on paper, where they are cheap to change.
- 03
Build in working slices
You see the real system early, on real data where possible, instead of a reveal at the end.
- Who does it
- Our team, with your staff trying each slice.
- What you get
- Wrong turns show up early, while they are small.
- 04
Prove it under load
We run functional tests and real-world trials against the conditions it will actually face.
- Who does it
- Our team, then your staff.
- What you get
- Problems are found by us, not by your customers.
The stack
Tools we run in production
We pick for your system. These are what we work with most in this area.
You do not need to know these names. In plain terms: programming languages for the logic, Postgres and Supabase to store your records, WebSockets and WebRTC for live data, voice and video, and Docker and Fly.io to package the system and keep it running online.
- TypeScript
- Node.js
- Python
- FastAPI
- Next.js
- Postgres
- Supabase
- Prisma
- WebSockets
- WebRTC
- Docker
- Fly.io
Deliverables
What you get
- Working system deployed to your environment
- Source code and repository access
- Written guide to how your data and system are organised
- Admin console with staff roles
- Automated tests for the critical paths
- Handover session and an operations guide
Related work
Where we have built this
Live entertainment and visitor attractions
EDROM RoboPark
Giant robot characters that hear, see and answer guests in four languages, with safe controls for movement and one screen to run the park.
Food service and entertainment
The Fried Hangover
Three disconnected codebases merged into one live platform for a Phoenix vegan food truck: online orders, a music and goods shop, loyalty, reviews and one safe checkout.
Trading education and simulation
Vector Games
A trading school and practice desk on simulated prices: lessons, a journal and games that reward process, with trader data walled off. Education, not financial advice.
FAQ
Common questions
When does a business need a custom system instead of a ready-made app?
When your team is keeping the real process in spreadsheets and workarounds, when several tools hold conflicting data, or when the thing you sell depends on behaviour no vendor offers. If an off-the-shelf tool fits, we will tell you to use it.
Who owns the code?
Ownership terms are set out in the engagement before work starts. Our default for custom builds is that you receive the source code and repository access for the system built for you.
Can you work with our existing systems?
Yes. Most engagements connect to something already running. We can integrate with it, migrate from it, or consolidate several systems into one.
Do you build software that controls hardware?
Yes. Our RoboPark work includes a software layer built to run animatronic robots through approved, named actions, with stop behaviour that sits below the AI, on a Raspberry Pi and relay board.
Talk to us about systems development
Answer a few questions and send them to us. We will tell you what we would build, and what you do not need.