Northwood Retail Northwood Retail Earley, Reading
An open PC case on a workbench at night, side panel swung back with a graphics card leaning against it.

Development process · PC-first games and desktop tools

From a playable prototype to a release build

Bench to page, page to chapter, one seam.

● Working rule: test early, let what you learn change the plan

Why this page exists

How we take a project from an idea to something you can run

This page describes how Northwood Retail takes a project from an idea to something people can actually run. It is not a formal methodology with a name. It is a working process that has held up across games and applications, and it is built around one rule: test the thing early, and let what you learn change the plan.

Here is what that looks like in practice, stage by stage — from the first ugly prototype, through internal and external playtesting, into the scope decisions and the release that follows it. If you are a player who wants to know whether a project is still alive, or a PC user wondering why one of our desktop tools exists, this page is where both answers live.

A shallow parts tray of small fasteners beside a soldering iron resting in its cradle.

How we build — in four stages

One rule, four stages, no restart

The 1px ember rule below runs edge-to-edge across all four stages. It does not break between them — that is the whole point.

Start with a mechanic you can test in a week

Every project begins with a mechanic, not a setting. A mechanic can be built, played, and judged in a short span, which means a bad direction gets caught before it consumes months. The prototype is deliberately ugly, and that is fine.

We are testing whether the core action is interesting without tutorials, art, or a story to carry it. If it is not fun at this stage, no amount of later polish will fix it. So the decision to continue happens early, on evidence rather than enthusiasm.

The prototype has to survive without explanation

A prototype that needs a paragraph of context already told us something. We play these builds with people who have not seen the project, and if they cannot find the fun without being told where it is, that is a design problem, not a player problem.

This is why early builds skip tutorials entirely. The ones that survive tend to be obvious within a minute, and that clarity carries into everything built afterward.

Playtesting, internal and external

We test in two passes. Internal sessions catch obvious problems quickly, usually within days of a change. External sessions with people outside the studio catch the things we have stopped noticing, because we know how the project is supposed to work.

External feedback tends to be blunt and useful: where players get stuck, what they misunderstood, what they skipped. We take notes, change things, and test again. Not every piece of feedback gets acted on, but every piece gets read.

Growth beyond the prototype

Once a mechanic holds up, the project grows in a controlled way. Systems get built out, art gets a pass, and scope is sized honestly against what a small team can finish. This is where most of the risk lives: it is tempting to add features, and every addition needs to justify itself against the core loop.

We work against a scope we can actually complete. That means saying no to good ideas that do not fit.

The ordering of priorities

PC-first design decisions

PC-first means keyboard and mouse come first, and the interface is designed for a desktop screen, not shrunk down from something bigger. It is not a marketing stance — it is an ordering of priorities.

Controller support gets added later where it genuinely fits, rather than driving the initial layout. Get the PC experience right first, and the rest becomes an addition rather than a workaround.

Readable text

Type is set for the desktop screen at common resolutions — 1080p, 1440p, and a 4K display where a player sits further back. Measure, size, and contrast are chosen against those, not against a handheld screen.

Control scheme

Keybinds a PC player expects: rebinding as standard, sensible defaults, an interface you can drive with mouse as well as keys. No layout that quietly assumed a gamepad first and a keyboard second.

Performance targets

Targets are set against mid-range desktop hardware rather than the top end. A machine several years old should still run the thing. Optimisation is part of the build, not a phase squeezed in at the end.

Controller later

Pad support is added where it earns its place — after the keyboard-and-mouse experience is already right, and never as a thin wrapper that maps the pad onto a layout designed for something else.

Cutting the work

What happens when a prototype fails

Some prototypes don't survive, and we stop them. This is a normal outcome, not a failure of process.

The alternative — pushing a project forward because time has already been spent on it — is how studios end up releasing something nobody enjoys. Cutting a project early frees the time for the next test.

We don't list abandoned work on the site as though it is still active, because that would mislead anyone tracking the studio. What you see listed is what survived this stage. If a project appears on the Games page or the PC Applications page, it got through prototyping, playtesting, and a scope review.

The same standard applies to status. A project marked as in development is in development. A project marked as released runs today on the hardware we tested it against.

A soldering iron resting in its heat-scarred cradle, cable coiling off to the right.

Two routes, one standard

Games, tools, and the rules we hold to

The application line runs the same route with a shorter runway and the same standard at the end of it.

Building the desktop side

A tool earns its release

A tool starts as an internal fix, gets used on real work, and earns a release if it stays useful. Narrow scope, honest requirements, no unfinished features shipped as if complete.

Windows compatibility gets tested on ordinary hardware, because a utility that only works on a high-end machine is not a utility. Once a tool holds up under daily use, it graduates to the PC Applications page with a clear description of what it does.

See the desktop tools

Release and after

Release is not the end of the process

A shipped project still gets fixes, compatibility updates, and small improvements where they matter. We treat the post-release period as part of the work rather than an afterthought, and we say when something has changed.

We don't promise a fixed update cadence, because a small studio can't keep one honestly. What we do commit to is keeping released work functional and being straightforward about what each update contains.

Read the studio's notes

What we won't do

Practices we avoid on principle

  • We don't publish release dates until a build is close enough to support one.
  • We don't list abandoned projects as active.
  • We don't claim awards, review scores, or user numbers we can't substantiate.
  • We don't describe a project as finished when it isn't.

Trust is easier to keep than to rebuild, and a small studio lives and dies by whether people believe what it says. This page exists so you can hold us to that standard.

Straight answers

What the process actually looks like, in questions

Four things people ask most often about how a project moves from a prototype to a release. If your question is not here, the studio is reachable — see the closure shelf below.

How long does prototyping take?

Long enough to build the mechanic and play it with people who have not seen it. Weeks, not months, and the decision to continue happens at the end of that window.

Do you take external feedback during development?

Yes. External playtests run alongside internal sessions, and the pattern across them guides changes more than any single comment does.

Why PC first?

Because the control scheme and interface are designed for keyboard and mouse first, and controller support is added later only where it fits.

Do you publish release dates early?

No. A date goes public once a build is close enough to support it.

Everything else about the studio — the bench, the projects, the way questions get answered — lives on the pages linked in the closure shelf below.

The closure shelf

That is how a project gets from the bench to your machine

If you want to see what survived the process, the Games page and the PC Applications page are the current list. If you have a question the pages above did not answer, contact the studio directly — the address below is the same one the pages link to.

Next step

Contact the studio

Monday to Friday, 9:00 AM – 6:00 PM

Where we are

3 Victoria Place
Earley, Reading
England

A note on this page

Nothing here describes a method we invented. It describes a way of working we can hold to, written down so the claim is one you can check against the Games, PC Applications, and Studio Notes pages.

Northwood Retail · Earley, Reading, England · © 2026