A lamp-lit workshop shelf of boxed desktop releases and a wooden prototype, one carmine tag marking the newest

We build it, then we hand you the source.

Representative builds from the Ridgefield workshop — described honestly, with the scope decisions that made each one difficult.

Selected work Discuss a similar project

What these builds have in common

The projects described here are representative of the bespoke software and PC game work we take on — a scheduling tool for an operations team, a bench-side inspection application, a stock integration between two systems, and three game builds at different stages. We would rather explain a build honestly than present a wall of screenshots with no context, so the descriptions below focus on scope, role and what made each project difficult.

Each one started with a written scope, ran in sprints with a tracker the client could read, and ended with source code and build instructions. None of them required a long-term contract to release the code. They also all involved removing something — a screen, a field, a platform target, a feature that seemed central at the start. Where a project went well, that removal happened early; where it went slowly, it happened later than it should have.

Work types on this page

BSP Business software 2 builds
INT Integrations 1 build
GAM PC game work 3 builds
STY Concept studies 1 study

Frameworks in use across these builds

.NET Windows C# Construct 3 Unity Godot Unreal Engine 5

Picking the stack after the scope

Engine and framework choices on these projects were made after the scope, not before it. Where a team needed something shipping fast, we used the framework that would let them iterate on content without writing code; where a project had to survive years of maintenance inside an existing IT estate, we chose the .NET stack because the client's own team could read it.

The shelf below names the frameworks behind the six projects. It is deliberately short — we do not list every tool we have touched, only the ones we have shipped behind.

How the choice is made

Written scope, staff skills, maintenance horizon and platform target decide the framework. All four are agreed before any code is written.

Frameworks in use

Business software, in production

Two desktop applications and one integration. All three replaced a manual or shared-document process that had outgrown its original shape.

A signed installation disc on a brass-edged plate beside a running desktop workstation at night

Scheduling and job-tracking desktop application

The brief came from an operations team running a shared spreadsheet across three sites. Jobs were scheduled in one tab, parts lists in another, and nobody trusted the numbers after Friday. The replacement is a .NET Windows application with a central database, per-site permissions and a printed job sheet that matches the workshop's existing paperwork.

The difficult part was not the interface. It was agreeing what a "job" meant across three sites that used the same word for slightly different things. The scope document spent more time on that than on the screen design, and the project was better for it.

TypeBusiness software Stack.NET, C# UsersThree sites

A tablet-sized Windows machine and barcode scanner on a workshop bench beneath a lamp

Bench-side stock and inspection tool

This one replaced a paper process. Inspections were recorded on a form, filed, and typed up later, usually with errors. The desktop application runs on a tablet-sized Windows machine at the bench, reads from a barcode scanner, and writes records directly to the same database the accounts team already uses.

The design constraint was speed of entry. An inspection has to be logged in under a minute by someone holding a tool in the other hand. Every field that could be derived from the barcode was removed from the form for that reason.

TypeDesktop utility Stack.NET, C#, barcode InputOne-handed entry

Integration

Scheduled CSV exchange with validation

Two systems synchronised by a person exporting a CSV each morning. Replaced by a scheduled service that performs the same exchange with validation, logging and a failure alert — a bad record stops and reports rather than quietly entering the system. There is no user interface worth showing.

Game work, at three stages

A finished 2D puzzle game, a grey-box simulation prototype, and a concept study that changed the client's platform decision before any art was made.

Shipped — Construct 3

2D puzzle game, playable Windows version

A small team had a puzzle design, a prototype in a spreadsheet and no build path. We produced a playable Windows version in Construct 3, using its event system to keep production fast, with a level format the designer could edit without touching code.

The engine choice was deliberate. Construct 3 is aimed at 2D games and favours speed of production, which suited a project where the designer needed to iterate on levels daily rather than wait for engineering.

Prototype — Unity

Single-player management simulation prototype

A designer wanted to test whether a management simulation loop held for more than an hour. We built a grey-box Unity prototype: systems in C#, placeholder art, one scenario, and instrumentation so the playtest data could be read without a spreadsheet.

The prototype answered its question in a few weeks, which is the point of a prototype. The answer was that the loop held but the economy needed rework, and that finding was cheaper before the art pipeline started.

Study — no build Scope answered, project reframed

Co-op horror concept study

A two-person team came with a concept close in spirit to the emergent co-op model popularised by Lethal Company, which Zeekerss released into Early Access in 2023. Their question was scope: could two people build it?

We worked through the systems, the networking cost and the content requirement, and the honest answer was that the networking and testing load made it a three-person project on their timeline. They changed the design to single-player with a smaller system count. That is a successful engagement.

Questions we would rather answer early

If anything below matters to your decision, it is worth raising before we quote rather than after.

Are these real client projects?

They describe the types of work we take on and the decisions that shape them, written to show how we approach scope rather than to publish client material. We can talk through relevant experience directly when you get in touch, including the parts that went less well.

Can you show code or a live demo?

For client work, not without their permission. What we can do is walk through the architecture of a comparable build, explain why the stack was chosen, and describe what we would do differently now. That conversation is usually more useful than a screenshot.

Do you take on very small projects?

Sometimes. A short integration job or a focused utility can be worth doing when the scope is genuinely clear. We will say if the work is too small to justify our involvement, and we will say it before quoting rather than after.

Can you work with a designer or a team we already have?

Yes. Several of the projects above involved a client-side designer or product owner who kept the creative and business decisions while we handled engineering and production. That split works when someone owns the interfaces between the two sides.

Next step

Have a build that looks like one of these?

Send a paragraph about the problem and we will reply with what we would scope, what we would leave out, and where the risk sits. No long-term contract required to release the code we write for you.

Talk to us about scope How we work See our service lines

Ridgefield Services Limited — 29 Mill Place, Woodley, Reading, England. Studio hours Monday to Friday, 9:00 AM to 6:00 PM.