Spectrum Innovation
Lochristi · BE
Leave the manual open on the workbench
This page describes what working with us actually looks like, in the order things happen. It is written for a team deciding whether to start a conversation, so it is specific about what you get, what we need, and where the process can slow down.
Spectrum Innovation Solutions is a Belgian PC game and application studio working on Windows, DirectX, DirectStorage and modern .NET. An engagement with us has the same shape whether you are starting a new title or rescuing something already in production — a short discovery, a decision week, a prototype aimed at the riskiest assumption, production in fixed-length sprints, scheduled profiling passes, then release preparation. The rest of this page follows that order exactly as it happens, so you can see what one of these looks like from the inside before you write to us.
A short structured pass over the project before any commitment. It ends with a written view of the approach and the risks, not a sales document.
We build the smallest thing that exercises the assumption most likely to hurt you — a streaming loop, an input path, a save migration, a rendering technique.
Performance passes at intervals through production so the frame budget stays a known quantity, rather than a shock in the final month.
We do not start production on a vague agreement. Before work begins, we set the scope boundary, the milestone structure and the decision rights — who on your side can approve a change, who on ours owns delivery. This is the part teams skip when they are in a hurry, and the part that prevents a painful argument in month five. It takes a week.
Optimization is not a phase at the end. We schedule profiling passes at intervals through production so the picture of performance is continuous rather than a shock in the final month. Each pass produces a measurement, a short list of the largest costs, and a recommendation on which of them are worth addressing now and which can wait. Working this way keeps the frame budget a known quantity rather than a hope.
On a Windows title that usually means a close look at GPU and CPU frame time under a recorded capture, the input-to-photon path, load and streaming behaviour, and the memory the build actually holds — measured on hardware that resembles the machines you expect at launch, not just the studio's own.
A note from the studio floor
A named decision-maker, access to the code and design material that exists, and a realistic view of the deadline. Everything else can be worked out between us.
The most common difficulty in an engagement is not technical; it is a team that cannot make a decision in the time the sprint needs, and the fix for that is agreeing up front who decides. If a milestone review lands and nobody in the room can approve a course change, the sprint stalls — the code is fine, the calendar is not. Naming the person now costs a sentence in the kickoff notes and saves weeks later.
We also want to hear where you think the risk sits, in your own words. A team that has already decided which part of the build worries them most is a team we can help quickly, because we spend less of the discovery pass finding the problem and more of it on the fix.
If the title continues, so can we. Post-launch work tends to be a mix of hotfixes, content updates, performance work driven by real player hardware, and the occasional next project. We prefer long partnerships, because the second project with a team starts from a much better place than the first. If that is the shape you want, say so early and we can plan the engagement accordingly.
The last weeks are logistics: storefront metadata, build variants, localisation handoff, crash reporting, a documented hotfix process. We work through a checklist with you. If the game is intended to run after launch with content updates or multiplayer, the backend and packaging decisions have to be settled well before this point, because launch week is not a time for architecture.
If yours is not here, ask it on the contact page and we will answer it in the reply.
It is a short piece of work with a defined output: a written summary of the approach and the main risks. We scope it with you before starting, so you know what you are buying and what you get at the end of it.
Yes, and it is common. We spend the first days reading the code and the build pipeline rather than writing anything, because the fastest way to be useful is to understand what is already there. From that point the work follows the same sprint structure.
Scope changes are normal. What matters is that the change is visible and priced: what it costs in time, and what it displaces. We put that in writing before it happens rather than after.
The entry point is a project brief through the contact page. Tell us what you are building, what stage it is at, your deadline and where you think the risk sits. We read those and reply with an honest view, which sometimes means recommending a different approach, a different technology, or a different studio.
Written replies, no auto-responders. Weekdays, 9:00 – 18:00.