Hand 01
Vertical slices & prototypes
A playable build that answers one design question before the pitch.
Riverstone Holdings · App & Game Studio
The work we take on, and where it lands
A working overview of the project types and platforms that fit our studio — mobile apps, games, co-development, ports, and original IP — with the engagements we decline stated plainly.
The work we take on
A studio that names the fit before the pitch
Riverstone Holdings does not publish a trophy shelf. What we can do is set out honestly what kinds of projects we build, which platforms they run on, and which engagements we take versus turn down. If you read this page and can picture your project on it, the next step is a brief.
If you cannot, that is useful information too. We would rather be clear about the shape of our work than describe a range we do not have. That said, this page is not a gate — it is a working document. It carries the project categories we build most often, the platforms each one ships to, and where the studio draws the line. Where a brief does not fit us, we say so inside the first reply, usually alongside the kind of team that would fit it better.
Mobile apps for iOS and Android
Most of our app work ships to both stores
That covers consumer products with accounts and subscriptions, internal tools used by teams in the field, and companion apps attached to a service that already exists.
Some of these are native builds, particularly where device features are doing real work: camera, location, background sync, offline storage. Others run on Flutter or React Native so one codebase can serve both stores without doubling the maintenance bill later. That choice is made once, at scoping, and it is written down — not left to whichever engineer is free that week.
The engagement is usually end-to-end: scoping, design, build, store submission, launch week. Some clients only need part of that, and we say so if the fit is wrong.
- 01
- Native when the device is doing real work
- iOS · Android
- 02
- Flutter / React Native for one-codebase ships
- both stores
- 03
- End-to-end across scoping, build, launch
- full cycle
Games on mobile and PC
Three hands, one senior team
On the games side we work in Unity and Unreal Engine, mostly on mobile titles and mid-scope PC games. That includes vertical slices for pitching, full productions, and support work inside a larger team that needs extra hands for a stretch.
Hand 02
Full productions, mid-scope
Small senior team owns one slice of a game and ships it.
Hand 03
Support inside a larger team
Extra hands for a stretch, plugging in at the client's level.
The scale is honest: we are not set up for a hundred-person AAA production. What we do well is a small, senior team that owns a specific slice of a game and ships it. A vertical slice, a prototype that answers one design question, a mobile companion title, a port to a new platform.
When a brief genuinely needs a larger studio, we say so early. Merseyside has a cluster of studios built for that scale, and pointing you to one of them costs us nothing except a project we were never right for.
Co-development & porting
Joining a project that is already running
A good chunk of our work joins a project that is already running. That could be three more engineers for a quarter, a technical artist for a specific art push, or a producer who can push a milestone over the line.
Co-development engagements run in blocks of three to six months, with a review at the end of each. We plug in at the level the client needs and stay out of the way of their leads. Contracts usually include a clause that the client keeps the repository and accounts, which is not standard everywhere but should be.
Clients in this mode tend to be studios mid-production or product owners inside larger companies who need to hit a date without growing headcount permanently.
Porting is a distinct service, and we price it as one
Moving a finished Android game to iOS, a PC title to console, or an older app onto current OS versions is not a small job and pretending otherwise is how projects drift.
We start with an audit rather than a scope. What runs, what does not, which dependencies are dead, which features depend on platforms the target does not have. Then we quote the work in blocks.
Legacy modernisation sits in the same category: apps that were built years ago and now fail on new OS releases or store review. Often the cheapest useful thing is to fix what exists rather than rebuild it.
Original IP support
Some projects start without a client
Riverstone Holdings supports original IP work at the prototype and vertical-slice stage: mechanics that need a second pair of hands, an idea that needs to be playable before it can be pitched, a demo that shows systems rather than cutscenes.
This is slower work and the timelines are honest about it. A prototype that answers one design question in six weeks is more useful than a demo that looks finished and tells you nothing about the game.
Studio work, late afternoon. The prototype bench, drawn for the wall of a UK studio that supports original IP at the playable stage.
What we do not take on
The shape of our work, stated plainly
Being clear about this saves everyone time. Our model only works when the client wants to be in the room during the build.
-
Global live-ops teams at scale
We build the game; we are not set up to run a worldwide live-service operation from day one.
-
The cheapest possible builds
We are not the studio that ships an app for a phone and tells you it is done.
-
A hundred staff on day one
When a brief genuinely needs a larger studio, we point at one early. That costs us nothing except a project we were never right for.
-
Hand over the concept and hear nothing until launch
Our model only works when the client wants to be in the room during the build.
Platforms we build for
Where each kind of work lands
- iOS & Android
- Most of the app work sits here — native, or built on Flutter or React Native where one codebase is the right call.
- Web-backed services
- The API layer sits behind many of those apps. We handle it when needed, inside the client's accounts from day one.
- Mobile & PC games
- Unity for most projects, Unreal when rendering or console-first production drives the brief.
- Console
- Arriving later in a project once the core systems are running. We have shipped console ports and worked alongside publishers on submission requirements, including accessibility guidelines and the platform's own submission checklist — read at project start, not at the end.
If your project does not fit
Some briefs read well and still are not a fit. Maybe the timing is wrong, maybe the scope is larger than we can serve properly, maybe the client wants a model we do not run.
In those cases we say so in the first reply, usually with a suggestion of what kind of team would be better. That answer is worth having, even when it is not the one you wanted.
If you are not sure, send the brief anyway. A short reply either way is quicker than a discovery meeting.
What we send back
A view on fit, the shape of a first engagement, and — where we are wrong for it — a pointer to a team that is right.
Contact
12 Clerkenwell Road, London EC1M 5PQ · Mon–Fri, 9:00–18:00
Book a 30-minute callStart a conversation
The window is lit. Come build something.
If you can picture your project on this page, the next step is a brief. If you cannot, that is useful information too — a short reply either way is quicker than a discovery meeting.