Bartek Borkowski, co-founder of PlayPatrol and Managing Partner of createIT, is now featured in the iGaming Club Members Directory. The listing describes PlayPatrol in one line: a platform that plays online casino games, slots and sportsbook flows like a real player, and finds the bugs before real customers do.
That line raises a fair question about iGaming testing in general.
Why would a development agency that has spent two decades building casinos, betting systems and slot games end up building a tool whose only job is to play them?
The short answer: because the people who build the stack know exactly where it breaks, and it is rarely where anyone is testing.
Why iGaming testing usually stops where the player starts
createIT started in 2004 as a software house in Warsaw and took on its first iGaming client in 2015. Since then the team has built and maintained online casinos, sportsbooks and slot games for licences in Curaçao, Malta, Spain and Germany.
From the build side, QA looks thorough. Every party tests what it owns:
- the provider tests the game build in its own environment,
- the aggregator tests the integration against its own sandbox,
- the operator tests its frontend, wallet and payment flows,
- and the release goes live with every component signed off.
So why do players still hit frozen reels, failed bet placements and missing games?
| Layer | Usually tested by | What the player sees when it breaks |
| Operator frontend and lobby | Operator | Game missing from the lobby, wrong thumbnail, dead title |
| Authentication and session | Operator | Logged out mid-session, launch loops back to login |
| Aggregation layer | Aggregator | Game launches in the wrong currency or not at all |
| CDN and asset delivery | Provider / hosting | Endless loading screen, assets fail on mobile networks |
| RNG and game server | Provider | Spin hangs, round result not returned |
| Wallet and balance sync | Operator / aggregator | Win shown, balance not updated |
| GEO configuration | Operator | Game available in one market, blocked or untranslated in another |
Each row passes its own check. The failure lives in the seams between rows, and none of the parties owns a seam. A health check on the game server says the server is up. It says nothing about whether a player in Ontario on an Android phone can launch the game, place a bet and see the win land in their balance.
That’s the gap the createIT team kept seeing from inside client projects: a release that was “tested” by every definition each party used, and still broken for a real player within an hour of going live.
What a broken player flow costs before anyone notices
The cost of a seam failure is mostly a function of one variable: how long it stays live before someone notices. In most setups, the detection method is a player complaint that climbs through support, then account management, then a ticket to the provider.
Take an illustrative example. These are not PlayPatrol client figures; replace them with your own:
- one slot generates €3,000 GGR per day across an operator network,
- a CDN or GEO issue breaks it for mobile players in one market, about 15% of sessions,
- the issue stays live for 3 days before a complaint is escalated and confirmed.
That’s €3,000 × 15% × 3 = €1,350 lost on one title, in one incident.
Now scale it. A provider with 40 live titles that sees one such incident per title per quarter is looking at roughly €54,000 per quarter in lost GGR. And that’s before anyone counts:
- the engineering hours spent proving which side caused the fault instead of fixing it,
- the account manager hours spent smoothing over the operator relationship,
- the regulatory exposure when a fault affects player funds or game outcomes (see what UKGC asks after a game fault),
- the players who simply never come back to that game or that operator.
Run the same calculation for sportsbook testing and the numbers get sharper. A bet placement flow that fails during a peak match is not losing a slow trickle of sessions. It loses the highest-intent traffic of the week, all at once.
What player-side iGaming testing has to include
Closing the gap does not start with a tool. It starts with a different definition of “tested.” Whatever runs the checks, a player-side approach needs five things:
- The full player journey as the unit of testing. Login, lobby, game launch, spin or bet, win, balance update, and for sportsbooks bet placement and settlement. A test that stops at “page loaded” isn’t testing the journey.
- Production, not staging. The seams only exist in the live stack. Slot game testing in a provider sandbox can’t catch an aggregator currency mismatch on one operator.
- Real GEOs, devices and languages. GEO testing means running the journey from the market the player is actually in, on the devices they actually use.
- Frequency weighted by revenue exposure. Top titles and peak sportsbook windows get checked far more often than the long tail.
- Evidence-grade output. Video, timestamps, the exact step that failed, and the network context. Evidence is what turns a three-day argument between provider and operator into a same-day fix.
There is a sixth condition that is easy to underestimate: independence. If the provider tests, the operator questions the result. If the operator tests, the provider does. Game provider QA and operator QA both have a stake in where the fault lands. A neutral party that only reports what the player saw removes that friction.
This is the framework the createIT team built PlayPatrol around. An AI agent plays the games and sportsbook flows the way a player does, around the clock, across markets and devices, and records what broke on video. It needs no SDK or API integration to start, which matters for exactly the independence reason above. The details of the approach are on the how it works page, and sportsbook-specific coverage is on the sportsbooks page.
What changes when someone plays every game like a player
Go back to the example above. The variable that drove the cost was the 3-day detection lag. Cut it to a few hours and the same incident costs a fraction of the €1,350, multiplied across every title in the catalog.
In practice, teams that test from the player’s side see four changes:
- Faults are found before complaints. Support stops being the monitoring system.
- Disputes get shorter. A video of the failing step, with the market, device and time, settles who needs to fix what.
- Compliance reporting gets easier. When a regulator asks what happened and when, the answer already exists as a record.
- Engineering time goes back to building. The hours previously spent reproducing a vague “the game doesn’t work” ticket go to the actual fix.
For a development team, that last one is personal. It is the reason a company whose daily work is iGaming development ended up building a testing product at all.
Why the builder’s view matters for iGaming testing
Bartek Borkowski brings more than 20 years of technical and industry experience to both createIT and PlayPatrol. He also hosts CEOpen mic, a podcast where C-level executives across iGaming talk about their career paths, their big wins and, just as often, the failures behind them. The failures are the useful part. Almost every one starts the same way: something that looked fine on paper, and broke where nobody was looking. That’s the line from the iGaming Club Members Directory listing in practice. A team that built casinos for a decade learned where the stack fails, and built a player that goes there first. A build signed off in staging is not proof. An uptime check is not proof. A quiet support queue is not proof.
Proof is a real player journey that completes, in every market, every day.
How many of your live games would pass a real player’s journey right now?
PlayPatrol plays your casino games, slots and sportsbook flows like a real player and shows you what broke, on video.
Book a live demo
