Ridgefield Services Limited Ridgefield Services Ltd
A lit metal catalog shelf in a dark Ridgefield Services workshop, stacked labelled boxes and a coil-bound manual under a single lamp

The stack behind our desktop apps and games

The engines, frameworks and languages we use day to day — .NET and C# for business software, Unity, Unreal Engine 5, Godot Engine and Construct 3 for games.

Six frameworks in active use Discuss your stack

Read the shelf before you book a call

Why this page exists

This page exists so a technical colleague can check whether we fit before anyone books a call. Below is what we work in day to day: .NET and C# for business software, Unity, Unreal Engine 5, Godot Engine and Construct 3 for games. We have included what each one is good at and the cases where we would not reach for it.

Where the choice is ours, we pick the smallest tool that carries the project to release and stays maintainable afterwards. That is the whole policy, and it is why this page lists trade-offs rather than a preference order.

In daily use

  • .N .NET Desktop, services
  • C# C# Software & games
  • Un Unity PC, 2D & 3D
  • UE Unreal Engine 5 High fidelity
  • Go Godot Engine Open source
  • C3 Construct 3 Browser 2D
  • Db Relational database Behind most apps

.NET

Business apps

C#

Shared language

Unity

PC & 2D/3D

Unreal Engine 5

High fidelity

Construct 3

2D visual

Godot Engine

Open source

Pull the drawer open

The frameworks and what each one carries

Every project we take on stops at the same question first: which of these fits, and what does it cost later? Below the drawer is what we actually run, side by side, rather than a preference order. We choose the smallest tool that carries the project to release and stays maintainable afterwards.

What each one is good at

Six tools, six honest trade-offs

We have kept this as the shop sheet, not as a brochure. Each line says what the tool does well, and where we would not reach for it.

A nightly development desk with a laptop screen glowing and a brass-edged disc resting near a coil of cable

.NET for business software

.NET is Microsoft's application framework, and it is the backbone of a great deal of practical business software. In the UK it is common in enterprise systems, which matters more than it sounds: a maintainable codebase in a widely used framework is easier to hand to your next developer than something bespoke and clever.

We use it for Windows desktop applications and integration-heavy internal tools. It handles the unexciting requirements well: database access, file handling, local device communication, scheduled work and reporting. Boring is a feature in this category.

Windows desktop · integration · reporting

An open PC tower showing a lit interior beside a controller on a dark bench under a workshop lamp

Unity for prototyping and platform reach

Unity is a cross-platform engine used widely for PC, mobile and indie development. It supports C# scripting, has a large asset ecosystem, and remains one of the two dominant engines for new PC game production. We choose it for faster prototyping and for 2D or 3D projects that need broad platform reach.

It is not the right answer when the game's appeal rests on rendering at the highest end. Unity can do a lot, but Unreal's high-fidelity pipeline is built specifically for that target, and pretending otherwise wastes your budget.

C# scripting · 2D & 3D · PC and beyond

Talent gap C# One language across desktop work and Unity games — fewer assumptions between projects. Shared
Hi-fi cost Unreal Engine 5 Nanite and Lumen for visually ambitious PC and console games, with C++ and Blueprint scripting. Visual target
Small scope Godot Engine Open-source 2D and 3D, with Windows export — light, script-friendly, and honest about its smaller ecosystem. Open licence
Speed path Construct 3 Browser-based visual event system for short-cycle 2D work: prototypes, casual games, simple desktop releases. 2D fast cycle

Integration and the working ledger

Databases, integration and where the time goes

Most business applications we build sit on top of a relational database, and most of them have to talk to something else: an accounts package, a CRM, a scheduling system, a supplier's file drop. Integration work is where we spend a lot of unglamorous time, and it is usually what makes the difference between a tool people use and a tool people work around.

Issue tracking runs alongside all of it. You get visibility of the backlog and the current sprint rather than a periodic summary written from memory.

Backlog

  • Supplier file drop schema review 2d
  • Reporting export formats 3d
  • Legacy printer driver check 5d
  • Scheduled job retry policy 4d

In build

  • Desktop client, offline mode 1d
  • Accounts package connector 2d
  • Unity input mapping pass 3d
  • Save-file migration stub 4d

In review

  • C# service boundary review 1d
  • Godot export matrix check 2d
  • Database index pass 3d
  • Construct 3 event sheet tidy 2d

Shipping

  • Reporting module, signed build 0d
  • Sprint board visibility page 1d
  • Unity casual title, 1.1 patch 3d
  • Integration test harness 4d

Choosing between them

Why not Electron, why not Unity for everything

The question we get most is why not Electron for a desktop app, or why not Unity for everything. Both have good answers. Electron is a reasonable choice when the app is mostly forms and the team already writes JavaScript, and we will say so even when it means recommending a stack we would not use ourselves.

Where the choice is ours, we pick the smallest tool that carries the project to release and stays maintainable afterwards.

See how we scope work Ask a technical question

Questions we get asked

Should a desktop app be built with .NET, Electron, or something native?

If the app needs local files, printers, scanners, network devices or offline operation, a .NET Windows desktop application is usually the cleaner fit, and the framework's presence in UK enterprise work makes future maintenance easier to staff. If the app is mostly forms and reports and users are already in a browser, a web delivery can cost less to run.

Do you use Unreal Engine 5 for every 3D game?

No. Unreal is the stronger choice when high-fidelity rendering is central to the game's appeal, because Nanite and Lumen deliver that target and the production budget has to match it. For most small 3D PC titles, Unity gets to a shippable build faster and at lower cost.

Is Godot Engine production-ready for a commercial Windows release?

For 2D and smaller 3D projects, yes, and its Windows export path is a normal part of the workflow. The realistic consideration is the ecosystem: fewer ready-made assets and plugins than Unity, so more work happens in-house. For some teams that trade is fine, and the open-source licence is a real benefit.

Can you work with our existing database and APIs?

Yes, and it is usually the starting point. We read the schema and the interfaces before quoting, because integration constraints shape the application more than the interface does. If the existing API is missing something the app needs, that becomes a documented item rather than an assumption.

Ridgefield Services Limited

One working ledger of everything we build and everything we support. If your stack looks close to ours, the next step is a scoping conversation with a real answer about what fits.

Studio
29 Mill Place, Woodley, Reading, England
Hours
Monday to Friday, 9:00 AM – 6:00 PM

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

Get in touch