A custom game proposal is a description of a system, and the number at the bottom is attached to the scope of that system. Two studios quoting for what looks like the same slot can be quoting for two different systems, because the markets the game will be sold into decide which components, which reports and which evidence the build has to carry.
That is why the price is the wrong thing to compare first, and why the game is the wrong unit. This article sets out the unit that is actually comparable — one certified system per market — and the five lines that turn a pile of proposals into a grid where the difference in price has a name.
No one publishes a price, and that is not the obstacle
No independent studio in this market publishes a package price for a commissioned game, and this publication does not either. A number quoted without a scope basis is not information; it is a starting position in a negotiation that the buyer cannot evaluate.
The absence of a price list is therefore not the problem. The problem is that proposals are written in different units. One describes deliverables, one describes phases, one describes a team, and one describes a monthly retainer with a launch estimate attached. Put them side by side and the only field with the same meaning in all four is the total.
The fix is mechanical: choose one unit, force every proposal into it, and price the difference.
What Spain actually certifies
The Spanish homologation dossier is the clearest published statement of what the unit of certification is, because it is an inventory document rather than a review of a game.
Anexo III of the DGOJ resolution sets a nine-section structure for the definitive functionality certification report: identification of the certification, description of the object of certification, an executive summary, compliance against each technical requirement, specific analyses, integration tests, the place and equipment and dates of the work, any test environment other than the operator’s production environment, and the digital support accompanying the report.
The second section is the one that changes a commercial conversation. The object of certification must identify the software elements used in the system with the manufacturer, product name and version of each, list the components qualified as critical together with their fingerprints, name the data centres, and list the certified access channels. For a singular licence it must also name the certified websites and trade names, the operator’s role, the certified game offer with its variants, and the access technologies.
No paragraph in that list says “the game”. It says the system, with the game inside it as a versioned element. A Spanish customer is not buying a slot; it is buying a slot that appears in an approved inventory with a fingerprint, alongside a capturer and a store belonging to the operator’s internal control system that the studio does not own.
The sequencing compounds it. Homologation runs in two stages: a documentary prior control with a preliminary report, then, after the licence is granted, definitive certification reports on the technical system actually in use, filed within four months of the notification of the grant — a deadline the resolution calls not extendable. A proposal that prices a build but not the production of that second-stage evidence is pricing a system that cannot be homologated.
The component inventory guide works through the full Anexo III structure, including the RNG analysis fields.
Where you sit in the chain changes the scope
Italy makes the same point from the other direction, and it is the single most useful question to ask a supplier.
ADM requires the technical conformity verification to apply to the concessionaire system in its entirety, not to single elements considered separately. But where a concessionaire uses a game system already certified and made available by a service-provider concessionaire, the verification body checks only the integration of that game system with the rest of the system.
Two commercial products fall out of that one carve-out. A supplier that becomes a service-provider concessionaire certifies a game system once and sells it into operators that then verify only an integration — the cheapest route for the buyer and the slowest and most capital-intensive for the supplier. A supplier that places its title inside one operator’s system is a passenger on that operator’s certification date.
So the first question about any proposal is not what is included. It is which side of that line the studio is on, because it decides whether the game arrives already certified or arrives as one more thing the operator has to have verified.
The Italian route also fixes the source discipline. The source delivered for inspection has to carry, for each file, module or function, its component, a short description and a change history, with the certified version identified uniquely by version. Critical files are identified by digest, and the verification body has to be able to demonstrate that the binaries it examined are the result of compiling the source that was handed over. The Italian timetable guide covers the deadline structure and the production verification that happens at the first production start of each game type.
The change rule is part of the price
Every proposal includes aftercare. Very few state the classification rule that decides what aftercare costs, and that rule differs enough between markets to change a total.
Great Britain states the principle and then gives examples on both sides. A major update is any software change that may affect the fairness of a game, and fairness is defined as any change to the random number generator, to scaling and mapping, or to game rules including how the rules are processed by the software. The published example that catches studios is a rebuild of the symbol arrays to cut CPU load: no rule changed, and the implementation of the rules did, so it needs external retesting. Against that sit the minor items — sound formats, a hat colour, background graphics replaced because a licence expired, a dialog that renders badly in one browser.
Spain runs a lighter continuous obligation with a harder edge: a documented change-management procedure, a quarterly report describing changes made and keeping the system description current, and prior authorisation for substantial modifications affecting critical components, with the regulator able to require withdrawal until homologation is obtained. Italy sets a twelve-month authorisation cycle and requires conformity certification of an emergency change within two weeks.
Put those three together and “certification support” stops being a line item. It is a standing capability: someone who can classify a change, produce the artefact the classification demands, and do it again next quarter. The change-control analysis sorts the surfaces, and post-approval scope covers the platform-review version of the same question.
Five lines that make proposals comparable
Force every proposal into these five lines, and the totals start to mean the same thing.
Build identities. The math version, the front version, the RTP set offered, and the RNG provenance. Spain’s RNG analysis asks for the manufacturer, product name and version, the digital fingerprint of the binary, whether it is hardware or software, whether it is random or pseudo-random and on what physical phenomenon, whether the instance is shared and with which games, the algorithm and libraries relied on, any reseeding procedure, the bit length of the space, and the statistical tests performed. A proposal that cannot name these has not scoped the build; it has scoped a demo. The RTP variant analysis explains why each return setting is its own certified object.
The market and locale matrix. One row per market, one column per locale, and a certificate in every cell. A localised game is a certified build rather than a translation, so a proposal offering four languages across three markets is offering up to twelve certified objects or a documented decision to ship fewer.
The certification artefacts, and who owns each. Who writes the technical report, who files it, who is the applicant of record, whether the studio is an already-homologated provider in that market, and who pays the test house. Spain’s requirement to identify the manufacturer and version of every software element means this ownership has to be assigned to a person, not to a department.
The integration surface. The RGS, the wallet, the aggregator and any central-system reporting. The interface is where a studio’s estimate is least reliable, and the integration tests an aggregator runs are the acceptance evidence for that line.
The change and support basis. The classification rule, the notice windows, the re-test cost by level, and the definition of a defect against a change request. This is the line most often left as a rate card with no classification behind it.
What “not included” is hiding
Exclusions are where proposals diverge most, and five of them move real money: certification and test-house fees; the localisation of the certified build; the component inventory and its maintenance after handover; integration with a second aggregator or a second wallet; and the first post-launch change batch.
A useful discipline is to require each exclusion to be priced as a stated unit — per market, per locale, per report, per change level — rather than left as “on request”. An exclusion with a unit is a comparison. An exclusion without one is a placeholder for the negotiation that happens after the launch campaign has been booked.
What cannot be compared
Two things in a proposal are not comparable and should not be scored: dates and approvals.
No studio controls a platform review queue or a regulator’s timetable, and any proposal that promises a launch date is describing a best case. A studio can commit to the evidence plan — which artefact is produced by whom, by when, and what happens if a submission is rejected — and that is the part worth comparing. The multi-jurisdiction release plan sets out the sequence that a realistic date has to be derived from.
The same restraint applies to outcomes. A proposal can state a hypothesis about what an exclusive or branded title is meant to do for the operator, and the instrumentation that would test it, without claiming a measured effect it does not have. If a game is meant to be judged on registration-to-first-deposit behaviour, the proposal can name the event, the attribution window and the baseline it will be read against. What it cannot do is convert that into a promised uplift, because nobody has run the controlled test yet. Say it can be tested; do not say it increases anything.
The grid, in practice
Build one table. Rows are the five lines, then the exclusions, then the evidence plan. Columns are the proposals received. Each cell holds a named artefact or an explicit “absent”. The final column holds the unit price for anything the proposal excluded.
A proposal that survives that treatment is comparable, and the difference between totals becomes a list of things one supplier included and another did not. That is a conversation about scope, which is the only conversation a buyer can win.
If you are assembling that grid and want the build identities, the market matrix and the evidence plan settled before a number is quoted, request a project quote. The commissioning guide covers how the brief is assembled, and the studio checks cover the licence, ownership and handover questions that decide what is left when the project ends.
Questions buyers ask
Why do custom game studios not publish package prices?
Because the price is a function of the scope, and the scope is set by the markets and locales the build has to be certified for, not by the game’s feature list. A published package price would have to assume a market set, and any accurate assumption would be wrong for most buyers. A scope-basis quote is the more useful document: it lets a buyer see which unit drives the total and remove one.
What does “certified system” mean if I am buying a game?
It means the object the regulator approves is larger than the game. In Spain the certification report must identify every software element with its manufacturer, product name and version, and list critical components with fingerprints, so the game arrives inside an approved inventory. In Italy the verification applies to the concessionaire system as a whole, and where a pre-certified game system is used the verification body checks only its integration. Either way, the unit you are buying is a system that includes your platform.
Should certification support be a separate line in the proposal?
Yes, and split further than most studios offer it. The useful split is by artefact — technical report, component inventory, RNG analysis, integration test evidence, the filing itself — with each artefact assigned to an owner and a market. A single “certification support” line hides the part that varies most between suppliers, which is who writes the report and who is accountable when the regulator asks a question.
How do I compare proposals that cover different market lists?
Normalise to the intersection first, then price the additions. Take the common market and locale set, compare like with like inside it, and treat every market a supplier offered outside the intersection as an optional addition with its own artefact list. The same rule applies to locales: a locale is a certified build, so an extra language is an extra certification object rather than a translation row.
Can a proposal commit to a launch date?
It can commit to the parts it controls, which is the delivery of a build and its evidence, and to a stated dependency list for the parts it does not. Platform review and regulatory certification sit outside a studio’s control, and a date that assumes a review queue is a forecast rather than a commitment. Ask for the dependency list and the evidence plan, and build the date from those rather than from the headline.
