Production Process — Nordic Bridge Solutions
We build the game, then hand you the keys. Below is how a project actually moves through the studio: the artifacts at each stage, the decisions that matter, and the points where small teams most often lose months.
Written for partners evaluating a co-development studio — scope first, estimates as ranges, one artefact at every stage.
Scoping
Handover
Who this is for
A studio that answers a scoping question with a specific artefact has done the work before. A studio that answers it with generalities about quality and passion has not — or is not showing you. That gap is what this page tries to close before any contract is signed.
We're Nordic Bridge Solutions, a game and PC application studio in Lochristi, Belgium. We work on our own titles and as a co-development block inside other pipelines, so the process below describes both starting points.
Stage one — scoping
A written scope doesn't prevent every disagreement, but it makes them cheap to resolve. If it's in the document, it's in the estimate. If it isn't, it's a change with a cost attached — and the conversation is about whether to make that change, rather than about who said what six weeks ago.
Verbal agreements drift. One person remembers the assessment module was included; the other remembers it was discussed as a future phase. Neither is lying. The scoping document is the record that ends that conversation before it starts.
A written brief and a rough schedule. The brief covers what's being built, what's explicitly out of scope, which platforms are targeted, and what counts as done. The schedule is a range, not a promise dated to the day, because early estimates are honest only in ranges.
Your own description first, in whatever form it exists. A rough paragraph is more useful than a polished deck, because it shows what you actually care about. We'll reshape it into a brief after we've read it.
Scoping ends when both sides have read the same document. Not when it's been sent. Read.
Why written scope matters
The single highest-value hour in a project is the one that produces a scope both sides have read. It's also the one most often skipped — usually because everyone is keen to start building. That's understandable, and it's still the wrong first move.
A written scope gives you something to point at when the picture in two people's heads diverges. It doesn't need to be a legal document. It needs to name the platforms, the deliverables, the exclusions, and the definition of done, in plain language both sides can check against.
For game projects we also name the runtime targets and the platforms we're shipping on in this scope, since those decisions harden quickly. For desktop or XR tools, we name the OS versions, the input devices, and the data sources we're integrating with. If those points are uncertain, they go in as open questions with a date attached.
Stage two — prototype
The prototype answers one question, and the question is agreed before we start. For a game, it's usually whether the core loop holds up. For a tool, it might be whether the data model supports the workflows you described.
The deliverable is something runnable — not a mockup, not a slide with arrows. We deliberately cut corners on visual polish and error handling, because the point is to learn something. Code written to learn is usually the wrong code to ship, and we say that out loud so nobody is surprised.
Stage three — production
Production is content and systems built against the agreed scope, delivered as milestone builds with a changelog. A milestone build is a working version of the project — not a partial branch that only compiles on one machine.
The cadence depends on the project length. A three-month build might have three milestones. A year-long project might have monthly ones. What matters is that each one is reviewable and that feedback arrives before the next one starts.
Change requests during production are normal and priced individually. We don't treat them as failures of planning, but we do keep them visible so the schedule effect is clear to both sides.
What arrives at each milestone
A version you can install and run on the target platform, with a written note of what changed since the last one.
What was added, what was changed, what was removed, and what is known to be rough in this build.
A block of time for your feedback before the next milestone starts, so decisions aren't made twice.
Any change requests raised since the previous build, priced individually and named explicitly.
When projects slip
Projects slip. The question is whether the slip is discovered early or at the deadline. Our rule: any milestone at risk gets flagged at the previous milestone, not the week it's due.
This is also why we don't take on more projects than the team can run at once. Overcommitment is the most common cause of slipped milestones in small studios.
Three honest options
Extend
Move the schedule out by the time the flag names, keeping the agreed scope intact.
Cut
Drop the least load-bearing items from the scope, with the decision written down.
Add
Add capacity for the remaining window, priced as an explicit change rather than absorbed.
We present the options with their costs and let you choose. What we don't do is quietly absorb a slip and deliver something thinner than agreed without saying so.
Stage four — handover
Handover means source code, build instructions, asset sources where applicable, and a walkthrough session with whoever will maintain the project. The session is recorded, so it can be rewatched.
If you have an in-house developer, we make sure they can build and run the project before we close the engagement. If you don't, we quote a support arrangement as a separate option — and you're free to decline it.
Reviewing the work
When you're evaluating studios, look at the artefacts rather than the pitch. A studio that answers with specifics has done the work before; one that answers with generalities about quality and passion has not — or is not showing you.
The most common beginner mistake when commissioning software is treating the estimate as the deliverable. The number matters, but the scope attached to it matters more — and an estimate without a written scope is not an estimate at all.
A milestone changelog
Ask to see one from a previous project. It shows whether milestones were real, reviewable deliveries or a stack of unfinished work.
A scoping document
Ask what theirs looks like in practice. Length matters less than whether it names exclusions and a definition of done.
A slippage story
Ask what happens when a milestone slips. The answer tells you whether they flag early or discover it at the deadline.
A handover pack
Ask what's included at the end — code, builds, asset sources, a walkthrough — and what's quoted separately.
Working with an existing pipeline
When we join a project mid-production or work as a co-development block, the process adapts rather than restarts. We adopt your repository conventions, your review process, and your ticketing system. Your team keeps working the way it wants to.
What doesn't change is the artefact rule. Every stage still ends with something reviewable, and the interface between our work and yours is written down before the first commit — so integration doesn't turn into guesswork halfway through a milestone.
Questions partners ask
If a question you have isn't here, the enquiry form on our contact page is the honest way to ask it — the answer might be no.
For a straightforward project, a week or two of back-and-forth. For something with unclear requirements, it can take longer — and that time is usually worth spending. A rushed scope is what produces expensive change requests later.
Yes. A prototype is real work with a real deliverable. It's priced as its own stage so you can stop after it without further commitment — or take it to another studio if that's the right call for you.
Change requests are normal and priced individually. If a change invalidates earlier work, we say so and re-scope, rather than absorbing it silently and delivering something thinner than agreed.
Yes, and it's a common arrangement. We adopt your conventions and tooling, and the boundary between our work and yours gets written down before the first commit — the same rule as a standalone engagement.
If this reads like your project
You don't need a polished brief to start. Tell us what you're building, who it's for, and what's making you uncertain — a rough paragraph is more useful to us than a deck. We'll come back with a scope sketch, a range for the schedule, and any questions that would change either.
Email — [email protected]
Phone — +32 9 375 73 83
Studio — Raveschoot 22, 9080 Lochristi, Belgium
Hours — Monday–Friday, 09:00–18:00 CET
