PC · Mobile · Steam

Game development
built around the core loop.

Turn a game concept into something people can play, test and improve. We work on PC and mobile games, gameplay systems and interactive experiences, with a delivery path shaped around the core loop.

Discuss your game ↗

From scope to delivery

What we can build
together.

A small, playable vertical slice helps identify design and technical risks early. We then scope content production, supported hardware, testing and distribution requirements. Multiplayer, original art and audio are planned explicitly because they substantially affect production time and budget.

Prototypes & gameplay

Validate movement, mechanics and the core loop with a playable build before expanding production scope.

Game systems

Progression, UI, save systems, platform features and backend services selected for your game design.

Release engineering

Performance profiling, build pipelines and Steam or mobile-store integration and submission preparation.

Who this is for

People with a game idea and a finite budget.

We work with small teams and individuals, not large publishers. Typical situations:

A designer or founder with a concept who needs an engineering team to find out whether the core loop is fun before paying for content.
A small studio short on engineering capacity that needs specific systems built: save and progression, UI, store integration, a leaderboard backend or a port.
A brand or business that wants a compact promotional or educational game that runs in the browser and on phones.
A team with a finished prototype that needs help turning it into a build that passes store review, performs on low-end devices and can be updated.

What we know from shipping our own

BBR designed, built and released Grow.io, an arcade game for Android on Google Play. It is written in JavaScript on HTML5 canvas and wrapped with Capacitor, with AI-controlled opponents, skins, AdMob advertising, in-app purchases and a multi-language interface. The case study describes the engineering decisions. We mention it here because it means our knowledge of the release process, store policies and monetisation plumbing comes from having done it.

The process

Find the fun first.
Then pay for content.

The expensive parts of a game are levels, art and audio. It makes no sense to buy them before the core loop has been shown to work.

How we work in detail ↗

Concept and scope

A short design brief: core loop, player goals, session length, platform, monetisation model and reference games. We identify the riskiest assumption and what a prototype must prove.

Playable prototype

Placeholder art and real mechanics. The only question is whether the moment-to-moment play works. You play it on a real device, and so do a few people who have never seen it.

Vertical slice

One small section of the game at release quality: final-style art, UI, audio, progression and performance on target hardware. This is the basis for a reliable estimate of full production.

Production

Content, remaining systems, monetisation, analytics and localisation, built in increments with a playable build at every milestone.

Release and updates

Device testing, store assets and policy requirements, submission, and a plan for post-launch fixes and content. Source, project files and store access are handed over to you.

Technology approach

Choose the lightest technology that fits the game.

Engine choice should follow from the design. A heavier engine than the game needs means larger downloads, slower iteration and more that can break on cheap phones.

Kind of game	Typical approach	Why
2D arcade, puzzle, casual and idle games for mobile and web	HTML5 canvas with JavaScript or TypeScript, packaged with Capacitor	Small builds, fast iteration, one codebase for browser and stores. This is the stack behind Grow.io
3D games, physics-heavy games, PC and Steam releases	Unity	Mature tooling, a large asset ecosystem and broad platform support
Leaderboards, accounts, cloud saves, live configuration	Node.js and PostgreSQL, or a managed backend	The same dependable stack we use for apps, sized for the game’s traffic
Ads and purchases	AdMob, Google Play Billing, App Store in-app purchase, Steamworks	Platform-native monetisation that meets store rules
Opponents and bots	Scripted and state-based AI tuned for difficulty and fairness	Makes a game feel populated without the cost of servers

Performance is handled as a feature from the prototype onwards: frame-time budgets, object pooling, texture sizes and testing on modest Android hardware, where most performance problems first appear. If your game is closer to an app with playful elements than to a game, mobile app development with a standard app stack may fit better. Our comparison of native and cross-platform approaches explains the trade-offs.

Pricing factors and common mistakes

Why game budgets vary so widely.

A prototype can take a few weeks. A content-rich game can take a year or more. The differences come from:

Content volume. Hand-built levels, characters and items scale the budget almost linearly. Procedural or systemic designs are cheaper per hour of play.
Art and audio. Original 2D art, 3D models, animation and music are each separate production lines. Licensed packs cut the cost sharply and make the game look less distinctive.
Multiplayer. Real-time online play is the largest single multiplier on scope, and it adds running costs after launch.
Platforms. Each store has its own build, review rules, input methods and testing matrix.
Monetisation depth. A single rewarded ad is simple. An economy with currencies, offers and live events is a product in itself.
Live operations. Remote configuration, events and content updates require a backend and someone to run it. See what ongoing upkeep typically involves in our maintenance cost guide.

We quote a fixed price for the prototype and the vertical slice. Full production is priced once the slice exists, because only then does anyone have the information to estimate it responsibly.

Common mistakes

Commissioning art before the mechanics are proven. Attractive assets for a loop that is not fun are wasted money.
Beginning with multiplayer. Prove the game against bots first. If that version is not fun, servers will not rescue it.
Testing only on a flagship phone. Much of your audience has a three-year-old mid-range device.
Adding monetisation at the end. Ads and purchases affect pacing and progression. Attached late, they feel intrusive and earn less.
Ignoring store policy until submission. Age ratings, data safety forms, consent for ads and rules for children’s content all take time and can block a launch.

Fit

Games we are suited to,
and games we are not.

We are a small studio. That fits compact, well-scoped games and rules out productions that need a large content team.

Good fit

We are likely a strong match if

You want a playable prototype or vertical slice before committing to full production
The game is a 2D or modest 3D title for mobile, web or PC
You need engineering for specific systems, store integration or a release
You are happy to work remotely in English with builds you can play at each milestone
You want to own the source, project files and store listings

Not a fit

We will probably point you elsewhere if

The project is a large 3D production that needs dozens of artists and designers
You need console development that requires platform-holder developer programmes and hardware
The game is a real-money gambling product
You are looking for a publisher, user-acquisition funding or revenue-share-only development
The design is a clone of an existing game with the assets swapped

Questions

Frequently asked
questions.

Can you help release a game on Steam?

We can scope Steamworks integration, build preparation and technical release support. The publisher account, commercial terms and final platform approval remain with you and the platform.

Which engine or technology do you use?

It depends on the game. For lightweight 2D games aimed at mobile and the browser we build with HTML5 canvas and JavaScript and package the result for the stores with Capacitor. That is how our own game Grow.io is made. For 3D games, physics-heavy games and PC releases, Unity is the usual choice. We recommend one after seeing the design and explain the reasoning.

Do you provide art, animation and audio?

Art and audio are scoped explicitly, because they frequently cost more than the code. There are three routes: you supply the assets, we build around licensed asset packs, or original art and audio production is planned as its own line in the scope with an agreed style and asset list. We tell you which route your budget realistically supports.

Can you add ads and in-app purchases?

Yes. Grow.io uses AdMob for advertising and store billing for in-app purchases, so we have worked through consent prompts, ad placement that does not interrupt play, purchase restoration and store review requirements. Monetisation should be designed together with the progression system and not attached at the end.

Can you build online multiplayer?

It can be scoped, and it changes the project substantially. Real-time multiplayer needs authoritative servers, latency handling, matchmaking, cheat resistance and ongoing hosting costs. Many games that feel multiplayer do not need it: Grow.io uses AI-controlled opponents to give an arena full of rivals without any network dependency. We will discuss honestly which approach your design needs.

Your next move

Have a game in mind?
Describe the core loop.

Tell us what the player does minute to minute, the target platform and any reference games. We reply with questions and a suggested scope for a first playable build.