Software for business
Relom Interactive builds the parts of a product that have to answer immediately and keep answering as the room fills up: live and multiplayer backends, interfaces several people share, and front-ends where a delay is something a person can feel. We also make our own games, which is why those words come first.
What we build
These are capabilities, not a portfolio. They describe the kind of system we are set up to take on and the questions we expect to be asked about it.
Shared state that many clients read and write at the same moment: sessions, rooms, presence, matchmaking, an authoritative server and clients kept in step with it. Reconnects, stale clients and bad networks belong in the specification, not in the bug tracker.
Interfaces several people use at once without standing on each other: live dashboards, editors, boards and queues, event streams that fan out to everyone watching, and an explicit rule for who wins when two people act in the same instant.
Front-ends where the interaction is the product rather than a page of form fields: canvases, editors, simulations, continuous input. Rendering and input handling that keep their frame budget on a mid-range phone, not only on the machine they were built on.
Traffic that is flat and then is not: a launch, a broadcast, a tournament, a deadline. Capacity planned against a stated peak, load tested before the date it matters, and degradation that is designed on purpose instead of discovered live.
Accounts, sessions, lobbies, leaderboards, inventories, telemetry and live events. Online gaming services is one of the activities on our licence, and it is the same work we do for our own titles.
A second reading of a design before it is built, or of a system that is buckling: where state lives, where the hot path runs, what breaks first as load climbs, and what to change in the order that actually helps.
Tools we reach for TypeScript end to end. Node.js, Express and PostgreSQL on the server; Next.js and React on the web; React Native on mobile. A short list we know well rather than a long one we do not.
How we work
We are a new studio, so this is written as promises rather than as history. Every line below is something you can check while the work is happening.
First contact is [email protected] and it reaches the people who would do the work. We answer within two working days. There is no form on this site and no queue in front of us.
What has to happen, how fast it has to answer, how many people are on it at peak, and what already exists. If that cannot be written in a page, it is not understood yet — and we will say so rather than quote around the gap.
Each stage has something you can run at the end of it, a date, and a definition of done agreed before it starts. What is out of scope is written next to what is in. If a stage grows, it is re-sized in the open instead of quietly absorbed.
Not a later phase. Hot paths are tested against the peak the brief states, and the system is run with a dependency deliberately removed to see what it actually does when that happens on a Friday.
Code, infrastructure definitions and documentation live in your repositories and your cloud accounts from the start. No runtime of ours sits in the middle of your product, and nothing about the handover requires our permission.
How it runs, how it is deployed, what it depends on and what to watch — kept current during the build rather than assembled in the last week. Before a project ends we say plainly whether we are available for ongoing work and on what terms.
Why a games studio
This is the argument the rest of the page rests on, so it gets the room.
A multiplayer game is business software with the excuses taken away.
The state changes many times a second. It is shared by people in different places on different networks, on hardware nobody chose for them. It has to be correct, and it has to be correct now — a hundred milliseconds late is not a slow page, it is a lost round, and a player feels it long before they could explain it.
Nobody has to be asked to complain, either. An audience playing together notices a regression within minutes and says so in public. There is no quarterly review in which a latency problem is eventually discovered. That is an unforgiving place to learn, and it teaches exactly the things business software needs: where state should live, what happens on reconnect, how a system behaves when the queue is longer than the workers, and which part you sacrifice first when something has to give.
It teaches a less technical habit as well. A game is judged on how it feels, so a games studio argues about response time the way other teams argue about wording. Speed stops being an optimisation ticket somewhere near the end and becomes part of the design from the beginning. That is the whole reason this page says real-time before it says anything else — and it is the honest answer to why a studio that makes its own games is a reasonable place to bring high-load work.
An authoritative server, clients that predict and then correct, and a written answer for what happens when two people act in the same instant.
Disconnects, retries and half-finished actions get specified up front, because in a game they are not edge cases — they happen in every session.
Response time gets a number while the thing is still being designed, and that number is defended during the build the way a game defends its frame budget.
Straight about this
What a client should take from that, written down rather than left to be noticed.
Relom Interactive was founded in 2026. There is no back catalogue on this site because there is not one yet, and a wall of borrowed logos would tell you something worse about us than an empty wall does.
What you can verify is here: a real company, a real trade licence, named activities, one mailbox a person reads. What you can hold us to is further up this page — the problem in writing, stages you can run, your repositories, your accounts. Those commitments are spelled out this plainly precisely because we are new. They are what we have instead of a reference list, which is also why we are careful about them.
If a reference list is what you need in order to sign, we would rather you waited for us than regretted us. If it is not, ask us the hardest technical question you have about your own system. That answer is a better sample of how we work than a case study would be.
Next step
Tell us what the system has to do, how fast it has to answer and how many people are on it at peak. We answer within two working days.
One address, read by the people who would do the work. No form, no routing, no newsletter.