Business Networking SNS for Executives, Japan
BizOn! is not a business card exchange app. It is a full-feature social network — scrolling feed, direct messaging, profile-based matching, event listings, group discussions, and push notifications — built for executives. Think Facebook, but the member list is C-suite. At launch, 14,284 executives were active on the platform within the first 30 days. Japan's largest executive networking community, running on a single Flutter codebase that serves iOS, Android, and Web simultaneously.
The platform had genuine traction. What it didn't have was a second revenue layer. Membership fees alone weren't the model WizBiz wanted to build on. As the user base grew, the question became clear: how do you let companies pay to reach this specific audience — in a structured, reviewed way — without disrupting the community that made the audience valuable in the first place?
The executives were connecting. The infrastructure to monetize that network was missing entirely.
The ask was clear: build an ad placement system that lets companies purchase visibility within the app. But the moment we started designing it, three hard constraints surfaced simultaneously — each one made more complicated by the fact that the platform ran on Flutter.
First, Apple's Steering regulation: any flow that appears to circumvent Apple's payment system is grounds for rejection. Because BizOn! is a Flutter app, price data compiled into the Dart bundle becomes part of the iOS binary that Apple reviews. A single pricing string in the wrong place — even a display-only label — could trigger a rejection. Second, the payment processor: GMO's 3DS authentication uses a redirect flow that required a full server-side state machine. No off-the-shelf Flutter package covered the specific GMO contract terms. Third, Japan's Special Commercial Transactions Law mandates legally complete disclosures for any fee-based service — disclosures that had to be data-model accurate, not just copy-pasted text on a page.
None of these was exceptional on its own. All three arriving simultaneously, on a live Flutter app with 14,284 existing users, while coordinating iOS App Store, Google Play, and web deployment windows — that was the actual challenge.
The foundation of the design was a single architectural decision: price information lives only on the web. The app shows placements, shows active campaigns, shows engagement metrics — but never shows a price tag. That information lives at the web URL that the app links to. Apple's reviewer sees an app with no in-app purchase flow. The advertiser completes payment on the web. Both sides of the equation are satisfied.
Simple in principle. In practice, it meant building two completely separate payment journeys — one for the web dashboard where advertisers submit and pay, one for the app where operators and admins review and manage — and keeping them synchronized without ever letting price data cross into the native app bundle.
Flutter was the right choice for BizOn!: one Dart codebase, three deployment targets, pixel-identical UI across iOS, Android, and the web. The entire social layer — feed, direct messaging, profile matching, events, notifications — is maintained in a single codebase that builds to all three platforms simultaneously. For a platform this size, that is not a convenience; it is a structural advantage.
But Flutter's single-codebase model creates a specific problem with Apple's Steering regulation. Any data present in the compiled Dart bundle — including pricing information — becomes part of the iOS binary. We made the architectural decision early: all pricing logic lives exclusively in the PHP backend and is served only to the web frontend. The Flutter app has no knowledge of prices, plans, or billing amounts. Apple's reviewer sees an app that, structurally, cannot display or process pricing. That is not a workaround — it is a clean separation of concerns that also happens to satisfy the regulation completely.
GMO's redirect-based 3D Secure authentication is not plug-and-play. The redirect loop — payment initiation, 3DS challenge, return callback, transaction confirmation — required building a full server-side state machine to track where each payment was in the flow. Dropped sessions, partial authorizations, and timeout edge cases all had to be handled explicitly. No off-the-shelf solution covered our specific GMO contract terms, so we built it from scratch.
Japan's Act on Specified Commercial Transactions requires specific disclosures for fee-based services — seller identity, pricing structure, cancellation policy, and more. Rather than treating this as a legal checkbox at the end of development, we built the disclosure framework into the data model early. Every pricing tier, every plan, every invoice automatically pulls from the same compliance-reviewed data source. When the law is satisfied at the data level, the UI never has the opportunity to violate it.
iOS, Android, and Web had to release together. A staged rollout would have created two-tier support — users on the updated platform asking about features users on the old platform couldn't access. We coordinated the Apple App Store review, Google Play review, and web deployment as a single synchronized release window. The App Store review alone required multiple rounds of Steering regulation documentation. We submitted knowing the first review might come back rejected — and planned for that iteration in the timeline rather than hoping to avoid it.
Companies apply for ad placements through a dedicated web dashboard: choose a plan, complete GMO payment, submit creative assets for review. Once approved, the campaign goes live inside the app. Billing, receipts, and campaign status are all visible from the same dashboard. The advertiser never needs to contact anyone.
BizOn! has the full feature surface of a modern social network — scrolling feed, direct messaging, profile-based matching, event listings, group discussions, and push notifications — all built in Flutter. One Dart codebase renders identically on iOS, Android, and Web. Approved ad placements appear as clearly labeled sponsored content within the feed, relevant to the executive audience. The social layer stays intact; the platform gains its financial foundation.
Admins review incoming ad applications, approve or decline campaigns, and monitor active placements from a single management screen. Billing records pull automatically from the GMO payment flow. Receipt generation is automated — no manual entry, no gaps in the financial record. The monthly accounting closes itself.
| Before | After | ||
|---|---|---|---|
| Revenue model | Membership fees only | → | Membership + ad placement tiers (¥10,000–¥80,000/plan) |
| Ad placement | Not possible | → | Self-service web dashboard — submit, pay, go live |
| Apple Steering compliance | Not addressed | → | Architecture reviewed, App Store approved |
| Release scope | iOS only | → | iOS + Android + Web, simultaneous launch |
| Billing & receipts | Manual process | → | Automated — GMO payment → receipt generation, zero manual entry |
"The ad platform launched without a single support ticket about billing. The payment flow just worked. That was the part I was most worried about."
CEO, WizBiz
Business networking platform for executives, Japan
Building a platform that needs to monetize?
30 minutes. No cost. Comes with a written next-step summary.