Works — SaaS Development
Data Management SaaS for Japan's Regulated Gaming Industry
3 hours→ 0
3,200+
machine records
fetched automatically every day
3 hours→ 0
daily manual entry
fully eliminated
200+
migration bugs
identified and resolved
Change
| Before | After | ||
|---|---|---|---|
| Staff morning routine | 3 hours manual data entry | → | Fully automated, 0 min |
| Player research | Social media searches, reliability unknown | → | Real-time performance graphs |
| Operator competitive intelligence | Gut feeling and experience | → | Data and comparison dashboard |
| Migration bugs | 200+ latent issues | → | All resolved |
| Concurrent processing | Untested | → | 10,000 records — load test cleared |
"The biggest change from this project is that looking at the data has become a routine. The 3 hours of manual entry are gone. But the real shift is subtler: having the numbers at hand means the next decision comes faster."
Founder & CEO
Gaming industry operator, Tokyo — 200+ locations across Japan
Context
Japan's regulated gaming industry — pachislo — generates an enormous amount of machine-level performance data. The industry's largest data portal accumulates hall-by-hall, machine-by-machine figures every single day.
The problem was that none of it was actually reaching the people who needed it most: the gaming hall operators, the content creators who built audiences around this data, and the players themselves.
Staff at gaming halls started every morning by manually checking that portal and copying figures into a spreadsheet. Three hours. Every day. 3 hours × 300 days = 900 hours of someone's time, gone to a task that should have been automated years ago. Players searched social media and specialist sites for information, but the data was fragmented and its reliability varied wildly. Hall operators had no real-time view of how competitors were performing.
The data existed. It just wasn't connected.
Challenge
The founder of a 15-year-old gaming hall operation came to us with this:
At first glance, this looked like a scraping-and-display tool. But the more I listened, the clearer it became that the underlying problem was something entirely different. Three distinct user groups — staff, content creators, and hall operators — each needed different information in different formats for different purposes. Connecting all three in a single system meant rethinking the architecture from the ground up, not building a data fetcher with a UI bolted on.
Craft
We came in mid-project.
Another firm had already started development. Within the first few hours of reading the codebase, it was clear the existing architecture couldn't support commercial deployment. That firm eventually stepped away from the project.
What followed wasn't a handover. It was a rebuild.
Four months. The scope wasn't "a data display tool" — it was "a SaaS that delivers value across the entire gaming hall ecosystem." The backbone of the design was three distinct account types: hall operators, content creators, and end users. Every feature and every screen was built independently around one of those three.
The hardest part of the project, though, wasn't the architecture — it was the migration. The initial prototype had been built on Replit. Moving everything to a production-grade Laravel backend surfaced over 200 bugs. Honestly, more than we anticipated. But we resolved every single one. The reasoning was straightforward: cutting corners at this stage would compound into years of expensive maintenance. We made the call to do it right.
We built an automated data pipeline that fetches over 3,200 machine records daily. It includes retry logic, anomaly detection, and incremental updates — zero manual intervention required. Load testing confirmed the system can handle 10,000 concurrent records, enough to support multi-hall expansion without architectural changes.
When multiple gaming halls share the same system, data isolation and processing conflicts are a real risk. We chose a Docker Compose containerization architecture that keeps each hall's environment fully separate while keeping operational overhead low — a design built to scale horizontally as more halls onboard.
Core features are free. AI-powered analytics operate on a paid point system. This wasn't a default freemium decision — it was the founder's explicit intent: "I want people to build the habit of looking at data first. Then, when they're ready, experience what the AI shows them." Payment runs through both GMO and Stripe, with each handling separate use cases. Delinquent account management is built into the platform.
Players can view machine-by-machine performance graphs in real time. A scheduling UI surfaces hall event information. The question "which machines are performing well right now?" is answered the moment they open the app.
Creators can save performance graphs and convert them directly into post-ready images. Templates optimized for X (Twitter) and Instagram are built in. The entire workflow — see the data, publish a post — happens inside the same tool. Every time a creator posts, the hall's reach grows.
A competitive analytics dashboard gives operators real data on rival halls: machine payout rates, weekly floor activity, trend lines. An integrated inquiry system handles customer questions in one place, eliminating the dropped requests that used to fall through the cracks.
Tech Stack
More Works
Telemarketing SaaS
The numbers existed. Nobody could see them.
Pharma & Healthcare
The workflow that ran the operation wasn't in the spec.
Enterprise AI Platform
Every team had AI. The work between the tools was still done by hand.
Built something similar to what you need?
30 minutes. No cost. Comes with a written next-step summary.