Spectrum Innovation Solutions · About Lochristi, Belgium · Est. practice since 2016

Shelf of bound technical manuals above a studio desk at Spectrum Innovation Solutions, morning light raking across the spines — A small Belgian studio that ships on Windows

Leave the manual open on the workbench

Spectrum Innovation Solutions · About

An engineering-led studio, working on Windows

Spectrum Innovation Solutions is a PC game and application studio at Raveschoot 22 in Lochristi, Belgium. We build games and Windows software, mostly for teams who have a project with real technical risk and need someone to own it.

This page is about who we are, what we take on, and how we prefer to work. If you are weighing up whether we are the right partner for a specific build, that is the question this page is written to answer plainly, without the tone a marketing page would use.

Address: Raveschoot 22, 9080 Lochristi, Belgium
Domain: spectruminnovation.digital
Working hours: Monday to Friday, 9:00 – 18:00 (Central European Time)
Enquiries: [email protected]

What the studio is

An engineering-led studio rather than an art-led one

Production engineering, performance, build pipelines, platform integration.

That shapes the work we are good at: production engineering, performance, build pipelines, platform integration, and the parts of a project that only show up when a game has to run on hardware nobody controls.

We are comfortable being the technical partner inside a larger team, and comfortable being the whole team on a small project. If a build needs somebody who will take the renderer apart at 2am before a milestone, that is what we are for. If it needs a team to own a Windows pipeline end to end while the art and design come from elsewhere, that also fits how we prefer to work.

Scope

What we take on, and what we do not

A truthful list of what fits is more useful than a list of everything. Both columns below are part of the same answer.

What we take on

PC-first games and Windows applications, from vertical slices to shipped releases.
Projects on MonoGame and other .NET-based frameworks, where the team wants the code kept idiomatic.
Engine-integrated work where a team needs low-level rendering or asset-streaming help inside the engine they already use.
Contract production where a studio needs capacity for a defined stretch of a schedule, not an open-ended job.
Performance and platform work on titles already in flight, when the last month needs reinforcement.

What we do not

Pretend to be a full-service studio with an art department we do not have. If you need character art, we are not it.
Take a console-exclusive project and learn the platform on your budget. If we have not shipped on a platform before, we say so up front.
Run a project as a black box with a build handed over at the end. We would rather show you the repository.
Say yes to a schedule we cannot hold. A hard no earlier is worth more than a soft yes that quietly slips.
Staff a project with people you never meet. The people who scope the work are the people who do the work.

The engineering background

Our work sits in the Windows stack

That is the territory we know properly, and where a team gets the most value out of us. It is also the territory where a partner who has only read about it tends to fall apart in the last month.

Windows Tech Stack

Rendering

DirectX 12 for the rendering path — command buffers, resource barriers, and the parts that decide whether a frame lands on time.

D3D12
Asset streaming

DirectStorage for asset streaming, so the storage path stops being the reason a level takes too long to open.

Storage
Device handling

GameInput for controllers, keyboards, mice, and the awkward handovers when a device disappears mid-session.

Input
Code

C++ and .NET for the code itself, chosen per layer rather than per preference.

C++ · .NET
Profiling

PIX · ETW
Frameworks

Microsoft lists DirectX 12 as a core technology for games and immersive experiences on Windows, and lists MonoGame among current .NET game-development options. That is the surface we work against.

MonoGame

Why Windows specifically

A studio that claims to be strong everywhere is usually strong nowhere

Windows is a platform with a specific set of behaviours, tools and failure modes, and the difference between knowing it and knowing about it shows up in the last month of a project — the week when the deadline is real and the driver you dismissed in month two starts eating frames.

Building PC titles and Windows applications with the same toolchain also means the practices carry across: a build pipeline that works for a game works for a product. When the same team can move between the two without relearning the tooling, the studio's time goes into the problem rather than the setup.

That is the trade we choose. We could spread the studio across more platforms tomorrow and win a wider range of briefs. We would rather be the Belgian team a partner calls for a Windows-specific problem that has already cost them a sprint or two.

Lochristi and the Belgian context

A small country with an unusually dense games scene

Our address is in Lochristi, between Ghent and the coast, and the Belgian scene is our working context. Flanders has established production teams such as Nacon Studio Ghent, and Wallonia has its own spread of smaller studios like RRSTUDIO, visible in the Liège and regional directory listings.

Independent coverage from Spawnpoint reported more than 115 active studios in the country, citing BelgianGames. That density shapes hiring, partnerships and how work moves between teams here: a problem solved in Ghent this month is often a problem being hit in Liège next month, and the trade between studios is unusually fluid for a country this size.

Being local matters less than being useful, but it does change how we work. A partner can drive over for a build review. A codebase can be handed between two teams on the same rail line. That is a real advantage when a milestone is tight and a remote-only partner would be a lost day in coordination.

How we work with a partner

A partnership, not a handover

Most of our engagements are a partnership rather than a handover. We work inside your repository, your tracker and your communication tools, and we expect you to be able to see what we are doing at any point.

Inside the tent

Your repo, your tracker, your chat. We are visible in the tools you already use — not stitched on through a weekly dashboard.

Fast by design

A small team stays fast when the information sits in one place. Sending status reports around the room is the slowest way to keep a schedule.

Honest scope

If you want a black box that returns a build in six months, we are the wrong studio. That is not a stance; it is simply how we are set up.

Long partnerships

The second project is worth more than the first

The second project with a team is worth more than the first, because the context is already there. Your conventions, your tech quirks and your people are the ground we built the last release on, and none of that has to be relearned from scratch.

We prefer to build relationships that way: a first piece of work scoped tightly enough to be low risk, then a longer arrangement if it goes well. It is a slower way to win work and a better way to do it. Nothing asks a partner to bet on us before we have earned it.

Working hours and communication

Central European hours, mostly in writing

We work Central European hours and communicate mostly in writing, with scheduled calls when a decision needs a conversation. That suits partners across Europe and works reasonably well further afield, where a shared document is often better than a live meeting that lands at 3am for one side.

If a project needs someone available in another timezone's working day, we will tell you honestly whether that is something we can do rather than agree and then disappear. An honest no early is worth more to both sides than a promise we cannot hold.

Hours: Monday to Friday, 9:00 – 18:00 CET
Written first: Briefs, decisions and reviews land as documents; calls are for the decisions that need one.

Getting in touch

Send us a brief, or ask a question first

The contact page takes a project brief or a question about scope or availability. If you would rather read about how an engagement runs first, Our Process covers it from discovery through release preparation. Either way, you will get a considered reply rather than a calendar link.

Send a project brief See how we run an engagement

Typical partner questions

The things partners ask before they brief us

A short list, kept close to the answers we actually give on the first call. Open the one you need.

＋ What does the first piece of work usually look like?

A scoped engagement with a clear end, often a performance pass on an in-flight title or a build-pipeline cleanup. Something low risk, paid for by the outcome rather than the calendar, and short enough that you can judge us on the result rather than on a pitch deck.

＋ Can you work inside our existing codebase and tooling?

That is the usual arrangement. We come to your repository and your tracker and follow your conventions; you can review every commit and every change. Bring your own build discipline and we adapt to it instead of layering a second one on top.

＋ How do you decide when something is out of scope?

When it asks us to be something we are not. Console-exclusive work we have not shipped on before, art-led production we do not staff, or an open-ended scope where the deliverable has not been agreed. We tell you that in the first conversation rather than in month four.

＋ Is the studio available for long-term work, or only short contracts?

Both, and we prefer the longer arrangement when the first piece has gone well. Long engagements work better when the context has had time to settle, so the first scoped block is paid for the outcome, and the second is chosen with the data from the first.

A small Belgian studio that ships on Windows