A Reading studio that writes software and games
A UK software and game development studio in Woodley, Reading — narrow on purpose.
What the studio is
We are an engineering-led studio. That means the first question we ask about a project is what it has to do, not what it should look like, and the answer usually determines the stack rather than the other way round. Business applications go to .NET and C#. Games go to Unity, Unreal Engine 5, Godot Engine or Construct 3, depending on the target and the budget.
Being narrow has a cost. We turn down work that does not fit, including projects that would pay well but sit outside desktop software and PC games. It also means the answer to "can you do this?" is usually a straight one — and when it is no, we will tell you which studio is a better match.
Accepted work, at a glance
- —
- Bespoke desktop applications and internal tools
- —
- Windows PC games for small teams
- —
- Workflows that have outgrown a spreadsheet
- —
- A demo that needs to become shippable
- ×
- Mobile-first products with a desktop afterthought
Where we are
Woodley sits just outside Reading, in the Thames Valley. The location is practical rather than symbolic: it puts us within reach of a lot of UK businesses that run real operations, and within reach of studios in Reading, London and the wider south of England.
We work with clients across the UK and further afield. Meetings happen in person locally and by call otherwise. Delivery does not depend much on geography, but a first conversation about a workflow often benefits from being in the room where the work happens.
How we work
Written scope first, then agile sprints with issue tracking the client can read, then demonstrable milestones. For business software that means staging builds you can install and click through. For games it means playable builds, even when the art is placeholder.
Handover is part of the engagement, not an optional extra. Source code, build instructions and a record of the decisions that would otherwise be rediscovered the hard way. Clients can take the code and maintain it themselves, and some do. That is a legitimate outcome.
The framework condition strip
What the shelf holds
The tools we keep sharp. Applied per project — never as a badge collection.
-
.NET
Line-of-business desktop software
-
C#
Primary language across the studio
-
Unity
2D and 3D PC game builds
-
Unreal Engine 5
Higher-fidelity game targets
-
Construct 3
Small 2D casual games, tight scope
-
Godot Engine
Open-source game targets
Where the game work sits
Games and business software sit in the same studio because they share a language. C# is the primary language for most Unity development and it is widely used in .NET desktop software, so the two halves understand each other's constraints rather than treating each other as a different company.
That overlap shows up in how we scope games. We plan production the way we plan an application: what has to exist for the first milestone, what can be placeholder, and what the handover looks like. It is a less romantic framing than a design pitch, and it tends to produce finished builds.
-
What has to exist for the first milestone
The smallest playable state that proves the loop works — no art polish until it is real.
-
What can be placeholder
Named systems, art and audio that can hold a slot without holding up the build.
-
What the handover looks like
Source code, build instructions and a written record of the decisions behind them.
The principles behind the work
Three stated plainly, plus a note about writing that applies to scope documents as much as to this page.
First
Build the smallest thing that solves the problem.
If a simpler tool already does the job, we will say so before we quote you work.
Second
Prefer maintainable code in a widely used framework over clever code that only its author understands.
A future developer — possibly yours, possibly us — should be able to open the file and find their way.
Third
Say no early, because a project that should not have started is expensive to discover in month four.
We would rather recommend someone else than start something we cannot land.
A fourth, on writing
The copy on this site is written to be read, not to fill space.
That applies to scope documents and handover notes too, and it is why some of our pages tell you what we do not do.
Working with us
Some clients arrive with a design document and need a build team. Some have a process that has outgrown a spreadsheet and no idea what the software should be called. Some have a demo and need it turned into something shippable. All three are ordinary work.
If you are comparing suppliers, ask what each would cut from your project. It is a fairer comparison than a price list, and it tells you whether the team understands your constraints.
Where a first conversation usually starts
- 01 A workflow you can describe in plain terms, even if you have no spec.
- 02 A target platform — most often Windows desktop, sometimes a console-adjacent PC build.
- 03 A rough sense of timing — even 'before next spring' is useful to hear.
- 04 Who will answer questions during the build.
Write to [email protected] or call +44 118 462 4556. We answer Monday to Friday, 9:00 AM – 6:00 PM.
Ridgefield Services Limited
29 Mill Place, Woodley, Reading, England · [email protected]
Questions we are asked
The four that come up most often before a first conversation, answered the way we answer them on the phone.
How big is the studio?
Small enough that the person who scopes your project is involved in building it. That shapes what we accept: a handful of projects at a time, chosen for fit rather than volume. It also means we will tell you early if your timeline needs more capacity than we have.
Do you use subcontractors?
Occasionally, for specialist work such as audio or a specific art pipeline, and only with the client's knowledge. The default is that the people who scoped the project build it.
Do you work outside the UK?
Yes, remotely. Most of our clients are UK-based, which suits the time zone and the way we run meetings. Remote engagements work when there is a named person who can answer questions during the build, wherever they are.
What kinds of projects do you turn down?
Mobile-first apps where the desktop piece is incidental, large-scale enterprise platform work that needs a bigger delivery organisation, and games with a scope that the available team cannot finish. We would rather recommend someone else than start something we cannot land.