Data Room

WordES is a Flutter/Dart-based, multi-mode and multilingual mobile game asset/project delivery. This handover package has been prepared to help the buyer understand the project more easily, recognize the file structure, and start their own development/release process more efficiently. WordES is positioned not as an active revenue-generating business sold on a revenue multiple, but as a pre-revenue mobile game asset / source-code asset / mobile game project acquisition. Therefore, the core value of the sale is based on the game concept, multi-mode gameplay structure, multilingual content architecture, Flutter-based project files, Android project structure, advertising/premium monetization foundation, and handover documentation. The handover package has been prepared by the seller in good faith for informational and transition-support purposes. These notes do not include source-code blocks, secret keys, live advertising IDs, payment account information, or private security information. The main Android application flows have been tested by the seller on Android devices. However, before going live, the buyer must complete their own technical, legal, store, advertising, payment, Android/iOS, privacy, consent, and production-readiness checks. Although an iOS-compatible Flutter architecture exists, the seller has not completed real iOS device testing, TestFlight testing, App Store testing, or live iOS payment/restore testing. Any buyer intending to release on iOS must complete final testing through their own Apple Developer account, iOS devices, and App Store Connect environment. The asset contents and word/question pools included in the project have been prepared for test/demo purposes to demonstrate the game content architecture and expandable structure. A significant portion of these contents was created through an AI-assisted production process. The handover notes do not provide an exact question/word count. Before final release, the buyer must review the contents through their own quality, language, copyright, legal suitability, and store-policy checks. This delivery is provided as-is. The seller does not guarantee revenue, user numbers, downloads, store approval, iOS approval, advertising revenue, payment conversion, trademark suitability, production-ready status, or any specific growth outcome. After receiving this project, the buyer should review it with their own technical team, test it, configure it, set up live advertising and payment settings, and complete all final pre-release checks.

WordES is a multi-mode mobile word and entertainment game project designed for solo players, friend groups, families and party settings. This document was prepared to help the buyer understand the project more quickly, understand the main structure and start their own development/publishing process more comfortably after handover. The core idea behind WordES is to bring different word, guessing, riddle and social game experiences together in a single app, support them with a multilingual content architecture and provide an expandable mobile game foundation for future development.

Main Game Modes

WordES is currently built around four main game modes.

1. Taboo

A social party game experience based on team-based describing and guessing. It is suitable for friend groups, family settings and group play scenarios.

2. Riddle

A playable mode based on solving riddles and questions. It can be used for solo players, and as the content pool expands it can support different difficulty, category and language experiences.

3. Charades

Supports a charades-style team/party game structure. It provides a fun social game experience based on players acting out words or concepts without speaking.

4. Word Master

Offers a word and question-based solving experience across different categories. The content structure was designed to be expandable.

Expandable Project Structure

WordES was not designed to be limited only to the existing four game modes. The project has a structure that can be developed further on the code side. New game modes can be added on top of the existing structure. For this, the relevant game flow, screen connections, data structure, content type, routing points and user interface connections need to be added technically according to the logic of the new game mode. In other words, adding a new game is not simply a matter of adding a new content file. However, the project architecture provides a foundation that can support new game modes when the proper technical development work is done. From this perspective, WordES can be viewed not only as a playable game in its current state, but also as an expandable mobile game foundation on which the buyer’s technical team can build new game modes, new content types and different gameplay flows.

Technical Extensibility Logic

The game modes in WordES are organized around a central game mode logic. These modes are connected with the home page flow, team setup flow, game screens, content loading system and user interface routing. This structure allows the existing game modes to provide separate experiences inside the app while also being managed under one shared mobile game framework. When adding a new game mode, development is generally needed in the following areas:

The purpose of this explanation is to show the project logic to the buyer without exposing source code. WordES provides a foundation where new modes can be added through code-level development. The buyer can build new games or different experiences on top of the existing four modes according to their own development plan.

• The core gameplay logic of the new game mode
• The screen or screen flow for the new mode
• The content type and data structure
• Home page or mode selection connection
• Routing flow based on team/solo play
• Score, timer, reward or progress logic if needed
• UI texts and language equivalents for the new mode
• Content loading and asset connections

Multilingual and Locale-Focused Content

Architecture

One of the strong points of WordES is its multilingual and locale-focused content architecture. The project includes a structure where content packages can be separated by different languages and regions. This structure was prepared with the goal of loading suitable content based on the user’s selected language or region.

Adding a new language generally requires the following steps:

Through this structure, WordES provides a foundation that can be adapted for different markets, different languages and different regional content sets. According to their own publishing strategy, the buyer can expand the existing content pools, add new languages, create regional content or prepare country-specific content packages.

• Preparing new content packages for the relevant language or region
• Updating the supported language/locale lists
• Registering the new content files in the app’s asset structure
• Adapting the required UI texts into the relevant language
• Testing the language selection and content loading flow

Asset and Content Structure

The words, questions, riddles and game content included in the project were prepared to demonstrate the content architecture and gameplay flows of WordES. The current asset files may include AI-assisted test/demo content. This content was prepared to show how the game works across different modes, demonstrate the expandable nature of the content pool and show how the system can be used with larger content packages. No exact number of questions or words is stated in the handover notes. The content pools should be treated as approximate, representative and expandable test/demo content structures. The buyer may edit, refresh, reduce, expand or completely replace these contents with their own content pool according to their publishing goals.

Monetization Infrastructure

WordES includes infrastructure suitable for advertising and premium access logic. Safe advertising configurations may be used in the project for testing and demo purposes. When the buyer wants to go live, they can configure the advertising system under their own account by adding their own ad identifiers. The premium access structure is also prepared in a way that can be developed with an in-app purchase model. The buyer can define products through their own store accounts and adjust the premium structure according to their own publishing strategy. This structure provides a foundation that can help the buyer move the project forward with different monetization strategies.

Platform Structure

WordES is a Flutter/Dart-based project. This structure provides a foundation for Android-focused mobile development while also offering a base that can be carried to iOS. Android project files are included in the handover package. The iOS side can also be evaluated within the natural mobile architecture of the Flutter project. The buyer can move the project forward according to their own publishing plan by completing Android and iOS build, store and device tests in their own technical environment.

Development Approach

The structure of WordES was organized to allow the buyer to continue development with their own technical team after handover. The existing system provides a foundation connecting game modes, content packages, language/locale selection, advertising/premium logic and user flows. With this foundation, the buyer does not have to use the project only as it currently is. The project can be developed for different markets or different user groups by adding new content, new categories, new languages, new regional packages and code-level new game modes.

Development Areas for the Buyer

WordES was designed as a game infrastructure that can grow with the right technical and content steps.

Some areas the buyer can develop include:

From the seller’s personal perspective, the current state of WordES is not only a starting point; with the right development, content management, store presentation and marketing steps, it has a structure that can be taken far beyond its current potential.

• Adding new game modes
• Adding new languages and regional content
• Expanding the existing content pools
• Extending the category system
• Adding new premium features
• Adjusting advertising and reward flows according to their own strategy
• Creating a different theme or brand language on the UI/UX side
• Making final optimizations for App Store and Google Play publishing processes
• Adapting content and store pages for new markets
• Preparing new content packages for community, family, education or party use cases

General Assessment

WordES is a mobile game asset/project that can be handed over with its multi-mode game concept, multilingual content structure, Flutter/Dart foundation, Android project files, premium/advertising infrastructure and expandable game architecture. This handover package was prepared to help the buyer understand the project more quickly, grasp the existing structure and start their own development process in a more organized way.

This document is a guiding and supporting project map prepared to help the buyer review the files and folders in the WordES handover package more easily. Its purpose is to help the buyer find their way through the delivered project files more quickly and to support the technical team during the first review process. The file explanations do not reproduce or explain the source code line by line. Instead, they summarize the general orientation value of the files inside the project and the possible connection areas they may relate to. In WordES, some files may touch more than one flow, and some connections may have changed during development or may be supported through different files. The files and folders included in this document were selected as the main areas that we considered generally useful for project orientation. This selection should not be read as a complete technical inventory of every file in the handover package or as a fixed ranking of importance. The buyer’s technical team may directly review other files and folders in the delivered project package according to their own review goals. For that reason, this document should be used to show where the technical team may start its review. The explanations in this document should be treated as practical orientation notes prepared to assist the buyer, not as definitive technical statements replacing the delivered source project. The final technical assessment should be made through direct review of the delivered project files.

General Package Logic

The WordES handover package generally includes the following main areas:

These areas are the main headings that can help the buyer understand the project structure inside the WordES handover package.

• Flutter/Dart application source files
• Data models and game mode definitions
• Pages and user flows
• Services and application logic
• Locale-based game content
• Visual and sound assets
• Android platform files
• iOS platform files
• Flutter project configuration

Main Architecture Reading Note

In WordES, game modes are handled through more than one file and flow. For a game mode to appear to the user, a content file alone is not enough. The game mode definition, home page or mode selection, team or solo start flow, related game page, content loading logic, progress/reward system, ad/premium services and UI texts may need to be considered together. lib/pages/game_page.dart is the main page related to the Riddle, Charades and Word Master games in WordES. This page relates to in-game areas such as question/word display, timer, answer/pass/transition behavior, progress and user interaction for the riddle, charades and word master modes. lib/pages/tabu_page.dart is the page kept separately for the Taboo game mode. The main reason Taboo is placed on a separate page is that this mode was later decided to be added to the project and was positioned as a separate game mode without disrupting the existing Riddle, Charades and Word Master page structure. This separation can be useful as an architectural example for the buyer. WordES was developed in a way that allowed a new game mode to be added later while preserving the existing game flows. Future game modes may also be evaluated inside an existing game page or handled as a separate page/flow, depending on their structure. On the language side, locale-based content packages and the content loading service should be considered together. To add a new language, a new content package, supported locale list, asset definition and UI text adaptation may be reviewed together. The file notes below are prepared to make orientation easier. A role mentioned here should not be read as the only possible role of that file. Some files may work together with multiple game flows, services or platform behaviors.

00 - Root / Flutter Project Configuration

pubspec.yaml

Role:: Flutter project configuration

Description:: This file is related to package dependencies, asset declarations, icon/splash

configuration and project version information. When a new asset, sound, visual resource or locale content package is added, the technical team may prefer to review this file.

When the buyer may review it:: Dependency setup, asset additions, icon/splash updates and new

language package registration.

01 - lib/models / Data Models

lib/models/game_mode.dart

Role:: Central game mode definition

Description:: This file relates to the central definition of the game modes inside WordES. When a

new game mode idea is evaluated, this file may be one of the important connection points. However, defining a new game mode here alone would not complete the work; the home page, team/solo flow, game screen, content loader and UI texts are better reviewed together.

When the buyer may review it:: New game mode planning, mode names and mode routing

chain.

lib/models/player_progress.dart

Role:: Player progress and premium state model

Description:: This file relates to player XP/level, diamonds, premium access, temporary premium,

daily rewards, used/solved content and game progress fields. If a new game mode will connect to progress, XP, diamonds, premium or solved/seen content tracking, the technical team may review this file.

When the buyer may review it:: Premium, diamonds, rewards, XP, levels and progress behavior.

lib/models/team.dart

Role:: Team model

Description:: This file relates to basic team data such as team name, score and team color in

team-based games. If a new game mode will be team-based, it may be useful to review this model together with the existing team flow.

When the buyer may review it:: Team games, score screens and team setup flows.

02 - lib/pages and lib/main.dart / App Flow and Pages

lib/game_page.dart

Role:: Compatibility export file

Description:: This file provides a compatibility route to the main game page through an older or

shorter import path. The actual game screen is under the related pages folder.

When the buyer may review it:: Import compatibility or older import path review.

lib/main.dart

Role:: Application start and entry point

Description:: This file relates to the application start flow, main theme, localization delegates,

first launch routing, privacy/language/access gates and ad/purchase startup order. When new language behavior, first launch behavior, privacy flow or global routing is reviewed, this file may be an important starting point.

When the buyer may review it:: Startup flow, language/privacy transition, general theme and

first routing checks.

lib/pages/access_gate_page.dart

Role:: Access/connection gate page

Description:: This page relates to gate flows that may be checked before taking the user to the

home page, such as internet, premium or access conditions.

When the buyer may review it:: Offline, premium or connection-based access decisions.

lib/pages/diamond_shop_page.dart

Role:: Diamond, reward and premium shop area

Description:: This page relates to diamonds, temporary premium, lifetime premium, ad rewards,

purchase connections and the premium agreement approval flow. If a new game mode will connect to diamonds, rewards, premium advantages or in-app purchases, this page may also be evaluated.

When the buyer may review it:: Premium/IAP, rewarded ad rewards, diamond economy and

purchase-facing user areas.

lib/pages/fruit_levels_page.dart

Role:: Level/fruit progress screen

Description:: This page relates to player progress, level/fruit visualization and presentation of

progress state to the user.

When the buyer may review it:: Level visualization and progress presentation.

lib/pages/game_page.dart

Role:: Riddle, Charades and Word Master game page

Description:: This page relates to the Riddle, Charades and Word Master game modes inside

WordES. It includes the in-game flows for riddle solving, charades word/concept display and word master question/answer structure. Timer, question or word display, answer/pass/transition behavior, in-game progress and user interactions are the main areas to review in this page. If a new game mode is considered and its structure is close to Riddle, Charades or Word Master, the technical team may prefer to review this page. If the new game has a noticeably different structure, creating a separate page/flow, similar to the Taboo example, may be a more organized option.

When the buyer may review it:: Riddle, Charades and Word Master flows; evaluating whether a

new mode may be reviewed together with the existing game page.

lib/pages/home_page.dart

Role:: Home screen and game mode entry center

Description:: This page relates to the main entry and game mode selection flow in WordES. It has

a central role in directing users to game modes, settings, language selection, premium/reward areas, the word bank area and general app sections. When a new game mode, major feature or new user entry point is added, this page may be one of the places where the visible navigation area is evaluated.

When the buyer may review it:: Home menu layout, mode selection, shop, rewards, language

and settings entry points.

lib/pages/intro_page.dart

Role:: First launch / intro flow

Description:: This page relates to the first user encounter, logo/intro and initial routing behavior.

When the buyer may review it:: First impression, onboarding start and intro adjustments.

lib/pages/language_selection_page.dart

Role:: Language and locale selection

Description:: This page relates to the user selecting the app language or locale and saving that

choice through the related services. It is one of the screens that may be reviewed when adding a new language. When a new locale is added, how that language appears to the user may be evaluated together with this page.

When the buyer may review it:: New language addition, language list and language selection UI.

lib/pages/privacy_consent_page.dart

Role:: Privacy and ad consent start flow

Description:: This page relates to privacy acceptance, ad consent logic, purchase/ad service

startup and user approval flows.

When the buyer may review it:: Consent, privacy acceptance and ad/purchase startup order.

lib/pages/privacy_read_page.dart

Role:: Privacy text reading page

Description:: This page relates to presenting privacy/policy text to the user in a readable format.

When the buyer may review it:: Privacy text updates or reading flow.

lib/pages/privacy_webview_page.dart

Role:: Privacy WebView page

Description:: This page relates to displaying an external or web-based privacy page inside a

WebView area.

When the buyer may review it:: Privacy link or web page display.

lib/pages/result_page.dart

Role:: Result screen

Description:: This page relates to team scores and result display after a game. If a new game

mode will show team scores, result comparison or end-game statistics, this page may be useful to review. Depending on the new game structure, the existing result screen may be used or a separate result flow may be evaluated.

When the buyer may review it:: Team game result display or score presentation adjustments.

lib/pages/tabu_page.dart

Role:: Taboo game page

Description:: This page relates to the Taboo game mode inside WordES. Taboo was later decided

to be added as a separate game mode, so it was positioned as a separate page/flow without disrupting the existing Riddle, Charades and Word Master page structure. This choice allowed Taboo to be added while preserving the existing game flows. Therefore, tabu_page.dart is one of the useful files showing that WordES can be developed in a way that supports adding a new game mode later. Taboo has its own in-game areas such as forbidden words, explanation flow, team turns, pass/transition, timer and score. However, the main architectural reason for keeping it separate is that Taboo was added later as a separate game mode. For a future new game mode, the technical team may evaluate two approaches: connecting the new mode to the existing game page structure, or adding it as a separate page/flow without disrupting the existing structure, similar to the Taboo example.

When the buyer may review it:: Taboo game flow, later-added game mode structure and the

approach of adding a new mode without disrupting the existing game page.

lib/pages/team_setup_page.dart

Role:: Team setup and mode routing page

Description:: This page relates to team count, team names and routing to the relevant game

page based on the selected game mode in flows that require team setup or team selection. If a new game mode is team-based, whether it starts directly or after team setup may be evaluated together with this page.

When the buyer may review it:: Team count, team names and mode-based game start.

lib/pages/word_bank_page.dart

Role:: Content pool viewing area

Description:: This page relates to showing words, questions or card content from different game

modes in a list/review style. It works together with the locale-based content loading structure. If content from a new game mode will appear in the Word Bank, this page may also be reviewed.

When the buyer may review it:: Word Bank, content viewing and content filter/display flows.

03 - lib/services / Services and Application Logic

lib/services/access_service.dart

Role:: Premium/offline access evaluation service

Description:: This service relates to evaluating access decisions based on the user’s premium

status and connection conditions. If a new game will be affected by premium, offline or connection-based access decisions, this service may be reviewed together with that flow.

When the buyer may review it:: Premium/offline access rules.

lib/services/ad_controller.dart

Role:: Ad rule and quota control layer

Description:: This service relates to higher-level ad rules such as when ads appear, daily limits,

question/time-based triggers and rewarded ad logic. If a new game mode will use ad display, rewarded ads, extra rights, extra time or ad-based advantages, this service may be reviewed.

When the buyer may review it:: Ad frequency, rewarded ads and premium ad-free rules.

lib/services/ad_service.dart

Role:: Ad service layer

Description:: This service relates to Google Mobile Ads integration, ad loading/showing,

rewarded/interstitial behavior and consent/premium-based ad gates. If a new game mode will use the ad system, this service may be evaluated together with the ad controller structure.

When the buyer may review it:: AdMob transition, moving from test ads to live ads and ad

behavior.

lib/services/locale_game_data_loader.dart

Role:: Locale-based game data loader

Description:: This service relates to loading asset content for the selected language/locale,

normalizing different JSON schemas and preparing data for game modes. It is one of the most important services to review when adding a new language or new content schema. If a new game mode has its own content pool, the technical team may review how a new content type could be loaded through this file.

When the buyer may review it:: New language addition, JSON asset compatibility and content

loader behavior.

lib/services/network_service.dart

Role:: Connection check service

Description:: This service relates to helper logic for checking whether the device has an internet

connection.

When the buyer may review it:: Connection-related gates and offline/premium checks.

lib/services/privacy_service.dart

Role:: Privacy and locale preference service

Description:: This service relates to storing the user’s privacy acceptance, selected

language/locale and related preferences on the device. When language or locale behavior is reviewed, this service may be evaluated together with the language selection page and content loader.

When the buyer may review it:: Privacy acceptance state and language/locale records.

lib/services/progress_service.dart

Role:: Persistent progress storage service

Description:: This service relates to storing, loading and updating player progress data on the

device. If a new game mode connects to XP, diamonds, premium state, used content or game progress, this service may be reviewed.

When the buyer may review it:: Progress, diamonds, XP and premium state records.

lib/services/purchase_service.dart

Role:: In-app purchase service

Description:: This service relates to store purchase connections, product querying, purchase

listening and restore/sync flows. If a new game mode connects to premium advantages or purchase flows, this service may be evaluated together with diamond_shop_page.dart.

When the buyer may review it:: Google Play/App Store products, premium purchases and restore

purchases.

lib/services/question_pool_service.dart

Role:: Legacy compatibility service bridge

Description:: This service appears to be a deprecated/compatibility-oriented bridge that points

toward the newer progress service structure. It may be kept so older references are not fully disconnected.

When the buyer may review it:: Older code references or backward compatibility review.

lib/services/sound_service.dart

Role:: Sound effects service

Description:: This service relates to playing short in-game sound effects such as correct, wrong

or countdown feedback. If a new game mode will use its own sound effects, this service and asset declarations may be reviewed together.

When the buyer may review it:: Adding/changing sound effects and in-game feedback.

04 - lib/theme and lib/widgets / UI Helpers

lib/theme/app_colors.dart

Role:: Base color constants

Description:: This file relates to some color constants used throughout the app. If a new game

should stay aligned with the existing visual identity, this area may be reviewed.

When the buyer may review it:: Theme or color changes.

lib/theme/wordes_responsive.dart

Role:: Responsive UI helpers

Description:: This file relates to UI sizing and framing helpers for different screen sizes. If a new

game screen is added, this helper structure may be reviewed for phone/tablet layout compatibility.

When the buyer may review it:: Phone/tablet screen compatibility and layout adjustments.

lib/widgets/compact_turn_title.dart

Role:: Compact turn title widget

Description:: This widget is used for compact turn/title display on game screens.

When the buyer may review it:: Turn/title UI layout.

lib/widgets/team_name_field.dart

Role:: Team name input widget

Description:: This reusable UI component is used for team name fields in team setup.

When the buyer may review it:: Team setup UI layout.

lib/widgets/wordes_settings_sheet.dart

Role:: Settings bottom sheet

Description:: This widget relates to a settings/action panel opened from the home page or other

areas. It may provide access to areas such as language selection.

When the buyer may review it:: Settings sheet, quick actions and language setting entry points.

05 - Guidance Note for Adding a New Game Mode

The current WordES file structure provides possible connection points for evaluating a new game mode idea. This section is not written as a fixed implementation instruction. It is an orientation note showing where the buyer or technical team may prefer to start reviewing the project. When a new game mode idea is evaluated, it may be useful to first look at how similar the new game is to the existing games. If the new game is close to question/answer, word display, guessing, timer or simple progress behavior, it may be reviewed together with the Riddle, Charades and Word Master structure in lib/pages/game_page.dart. If the new game requires a different turn structure, card logic, scoring system, player interaction or special flow that separates it from the existing games, lib/pages/tabu_page.dart may be a useful reference for the technical team. Taboo is important here because it was added later as a separate mode while the existing Riddle, Charades and Word Master structure was preserved. For that reason, the technical team may evaluate two approaches for a new game mode:

In my view, this decision is best made according to the gameplay structure of the new game.

• Reviewing the new game together with the existing game page structure
• Reviewing the new game as a separate page and flow, similar to the Taboo example

Possible files to review for a new game mode

lib/models/game_mode.dart

This file relates to the central game mode definition inside WordES. If a new game mode is considered, the technical team may first review how current modes are named and separated inside the app. If the new mode is planned as a separate game inside the app, this file may be one of the first likely connection points.

lib/pages/home_page.dart

This file relates to the main screen where users see and enter game modes. If a new game mode will be visible in the main menu, the technical team may evaluate whether a new card, button or routing entry should be added here.

lib/pages/team_setup_page.dart

This file is one of the areas related to the team/game start flow before a game begins. The technical team may review it when deciding whether the new game is solo, team-based, starts directly or starts after team selection.

lib/pages/game_page.dart

This file is the main game page for Riddle, Charades and Word Master. If the new game resembles one of these structures, the technical team may review whether the new game can be evaluated within this page.

lib/pages/tabu_page.dart

This file is the separate page/flow for Taboo. Since Taboo was added later as a separate mode, the technical team may use this approach as a reference if the new game does not fit naturally into the existing page structure.

lib/services/locale_game_data_loader.dart

This file relates to loading game content according to the selected language/locale. If the new game has its own content pool, the technical team may review how a new content type could be loaded. assets/game_data/ This folder contains language/locale-based game content packages. If a new game mode needs content, new content areas can be planned under the existing locale structure.

pubspec.yaml

This file relates to Flutter asset and dependency declarations. If the new game needs new assets, sounds, visuals or content packages, the technical team may also review this file.

lib/models/player_progress.dart

This file relates to player progress, XP, levels, diamonds, premium and used/solved content. If the new game will connect to progress, rewards, diamonds or seen/solved content tracking, this file may be reviewed.

lib/services/progress_service.dart

This file relates to storing and updating player progress. If the new game connects to progress, XP, diamonds, used content or daily rewards, reviewing this service may be useful.

lib/pages/result_page.dart

This file relates to the end-game result screen. If the new game will show team scores, result comparison or end-game statistics, the technical team may review it.

lib/pages/word_bank_page.dart

This file relates to displaying game content in a list or review area. If the new game content will appear in Word Bank, this page may be evaluated. lib/services/ad_controller.dart and lib/services/ad_service.dart These files relate to ad display rules, quota logic and ad services. If the new game will use ad display, rewarded ads, extra time or ad-based advantages, these services may be reviewed. lib/services/purchase_service.dart and lib/pages/diamond_shop_page.dart These files relate to in-app purchases, premium access, diamonds and reward areas. If the new game will be affected by premium advantages, diamond spend/reward logic or purchase behavior, these areas may be useful to review. lib/widgets/ and lib/theme/ These folders relate to reusable UI components and visual theme helpers. If the new game should match the current design language, the technical team may prefer to use or extend these areas.

Suggested review order for adding a new game

In my view, the technical team may prefer to evaluate a new game mode idea in the following order:

lib/pages/tabu_page.dart as a reference.

the new game. This approach may provide a clearer path for adding a new game without unnecessarily disturbing the existing structure.

• First, decide whether the new game is solo, team-based or supports both.
• Review whether the new game resembles Riddle, Charades or Word Master.
• If it does, consider reviewing it together with lib/pages/game_page.dart.
• If it needs a different game flow, review the separate page/flow approach using
• Evaluate how the new mode could be represented in the central game mode definition.
• Plan how it may appear to the user on the home page.
• Review how it may connect to the team/solo start flow.
• Design the content shape and locale-based content files for the new game.
• Evaluate the connection with the content loading service.
• Review progress, rewards, ads, premium and result screen connections according to the scope of

Brief summary

The idea of adding a new game mode to WordES can be evaluated through the existing file structure. In my view, the most important files for this review may include:

If the new game will connect to progress, rewards, ads, premium, result screens or Word Bank areas, the following files may also be reviewed:

This explanation presents the new game addition process as a project orientation map for the buyer’s technical team, not as a fixed setup instruction.

• lib/models/game_mode.dart
• lib/pages/home_page.dart
• lib/pages/team_setup_page.dart
• lib/pages/game_page.dart
• lib/pages/tabu_page.dart
• lib/services/locale_game_data_loader.dart
• assets/game_data/
• pubspec.yaml
• lib/models/player_progress.dart
• lib/services/progress_service.dart
• lib/services/ad_controller.dart
• lib/services/ad_service.dart
• lib/services/purchase_service.dart
• lib/pages/diamond_shop_page.dart
• lib/pages/result_page.dart
• lib/pages/word_bank_page.dart
• lib/widgets/
• lib/theme/

06 - assets/game_data / Locale-Based Game Content

This section contains the language and region-based game content packages for WordES. These contents are included in the handover package to show the game architecture, locale-based content loading structure and expandable content logic. The word and question pools may include AI-assisted test/demo content. For that reason, this document does not state exact word, question or content counts. The content should be treated as an approximate, representative and developable test/demo content pool. Before public release, the buyer may review these contents according to their own quality, language, cultural fit, copyright, store policy and target market considerations.

assets/game_data/ar_sa/ar_sa.json

Role:: ar_sa locale game content package

Description:: Locale-based game content file for the related language/region package.

When the buyer may review it:: Arabic / Saudi Arabia locale content, content quality review,

localization or content refresh work.

assets/game_data/de_de/de_de.json

Role:: de_de locale game content package

Description:: Locale-based game content file for the related language/region package.

When the buyer may review it:: German / Germany locale content, content quality review,

localization or content refresh work.

assets/game_data/en_gb/en_gb.json

Role:: en_gb locale game content package

Description:: Locale-based game content file for the related language/region package.

When the buyer may review it:: English / United Kingdom locale content, content quality review,

localization or content refresh work.

assets/game_data/en_us/en_us.json

Role:: en_us locale game content package

Description:: Locale-based game content file for the related language/region package.

When the buyer may review it:: English / United States locale content, content quality review,

localization or content refresh work.

assets/game_data/es_es/es_es.json

Role:: es_es locale game content package

Description:: Locale-based game content file for the related language/region package.

When the buyer may review it:: Spanish / Spain locale content, content quality review,

localization or content refresh work.

assets/game_data/fr_fr/fr_fr.json

Role:: fr_fr locale game content package

Description:: Locale-based game content file for the related language/region package.

When the buyer may review it:: French / France locale content, content quality review,

localization or content refresh work.

assets/game_data/hi_in/hi_in.json

Role:: hi_in locale game content package

Description:: Locale-based game content file for the related language/region package.

When the buyer may review it:: Hindi / India locale content, content quality review, localization

or content refresh work.

assets/game_data/it_it/it_it.json

Role:: it_it locale game content package

Description:: Locale-based game content file for the related language/region package.

When the buyer may review it:: Italian / Italy locale content, content quality review, localization

or content refresh work.

assets/game_data/ja_jp/ja_jp.json

Role:: ja_jp locale game content package

Description:: Locale-based game content file for the related language/region package.

When the buyer may review it:: Japanese / Japan locale content, content quality review,

localization or content refresh work.

assets/game_data/ko_kr/ko_kr.json

Role:: ko_kr locale game content package

Description:: Locale-based game content file for the related language/region package.

When the buyer may review it:: Korean / South Korea locale content, content quality review,

localization or content refresh work.

assets/game_data/pt_br/pt_br.json

Role:: pt_br locale game content package

Description:: Locale-based game content file for the related language/region package.

When the buyer may review it:: Portuguese / Brazil locale content, content quality review,

localization or content refresh work.

assets/game_data/pt_pt/pt_pt.json

Role:: pt_pt locale game content package

Description:: Locale-based game content file for the related language/region package.

When the buyer may review it:: Portuguese / Portugal locale content, content quality review,

localization or content refresh work.

assets/game_data/ru_ru/ru_ru.json

Role:: ru_ru locale game content package

Description:: Locale-based game content file for the related language/region package.

When the buyer may review it:: Russian / Russia locale content, content quality review,

localization or content refresh work.

assets/game_data/tr_tr/tr_tr.json

Role:: tr_tr locale game content package

Description:: Locale-based game content file for the related language/region package.

When the buyer may review it:: Turkish / Turkey locale content, content quality review,

localization or content refresh work.

assets/game_data/zh_cn/zh_cn.json

Role:: zh_cn locale game content package

Description:: Locale-based game content file for the related language/region package.

When the buyer may review it:: Chinese / China locale content, content quality review,

localization or content refresh work.

07 - assets/icon / Visual and Sound Assets

assets/icon/app_icon.png

Role:: App icon / visual asset

Description:: This file relates to the app icon or brand visual identity.

When the buyer may review it:: Brand/visual identity and icon changes.

assets/icon/intro_logo.png

Role:: Intro logo visual

Description:: This file relates to the intro or startup visual identity of the app.

When the buyer may review it:: Intro, logo or startup visual adjustments.

assets/icon/splash_logo.png

Role:: Splash logo visual

Description:: This file relates to splash or launch screen visual identity.

When the buyer may review it:: Splash/launch visual adjustments.

Sound effect assets

The following files relate to short in-game sound effects. They may be considered sound sources for correct answer, wrong answer, countdown or similar user feedback.

Note: Similar sound effects may appear under different folder names inside the zip. During final project organization, the buyer may prefer to simplify the active sound set and folder names with their technical team.

• assets/icon/sfx/correct_click.wav
• assets/icon/sfx/countdown_tick.wav
• assets/icon/sfx/wrong_buzz.wav
• assets/icon/sfx/Yeni klas#U00f6r/countdown_soft.wav
• assets/icon/sfx/Yeni klas#U00f6r/fail_soft.wav
• assets/icon/sfx/Yeni klas#U00f6r/success_soft.wav
• assets/icon/sfx/Yeni klasör/countdown_soft.wav
• assets/icon/sfx/Yeni klasör/fail_soft.wav
• assets/icon/sfx/Yeni klasör/success_soft.wav

08 - Android Generated / Local Metadata

The files in this section may be generated during the Android/Gradle build process or may contain development machine-specific metadata. They should not be evaluated as gameplay or product logic. They are listed for technical orientation. In the buyer’s own development environment, these areas may be generated or updated differently.

Android Gradle cache / metadata files

• android/.gradle/8.14/checksums/checksums.lock
• android/.gradle/8.14/checksums/md5-checksums.bin
• android/.gradle/8.14/checksums/sha1-checksums.bin
• android/.gradle/8.14/executionHistory/executionHistory.bin
• android/.gradle/8.14/executionHistory/executionHistory.lock
• android/.gradle/8.14/fileChanges/last-build.bin
• android/.gradle/8.14/fileHashes/fileHashes.bin
• android/.gradle/8.14/fileHashes/fileHashes.lock
• android/.gradle/8.14/fileHashes/resourceHashesCache.bin
• android/.gradle/8.14/gc.properties
• android/.gradle/buildOutputCleanup/buildOutputCleanup.lock
• android/.gradle/buildOutputCleanup/cache.properties
• android/.gradle/buildOutputCleanup/outputFiles.bin
• android/.gradle/file-system.probe
• android/.gradle/noVersion/buildLogic.lock
• android/.gradle/vcs-1/gc.properties

Role:: Local Android/Gradle build metadata files. These files are local cache or metadata areas

created during Gradle/Kotlin build processes. They do not contain game logic or game content and may be recreated in the buyer’s own development environment. android/ilk_uygulamam_android.iml

Role:: IDE project metadata file

Description:: Android/IntelliJ project metadata area. It does not represent product logic.

When the buyer may review it:: Usually managed by the IDE.

android/local.properties

Role:: Local Android SDK path file

Description:: This file relates to local settings such as Android SDK paths specific to a

development machine. It may be different on the buyer’s computer.

When the buyer may review it:: May be regenerated by Android Studio/Flutter in a new

environment.

09 - Android Platform Files

android/.gitignore

Role:: Android Git ignore settings

Description:: This file relates to Android-side files that should not be included in version control.

When the buyer may review it:: Version control organization.

android/app/build.gradle.kts

Role:: Android app module Gradle configuration

Description:: This file relates to the Android app module namespace, applicationId, SDK,

Java/Kotlin compatibility, build type and signing preparation areas.

When the buyer may review it:: Android build, applicationId, signing, release preparation and

store-side technical review.

Android manifest files

• android/app/src/debug/AndroidManifest.xml
• android/app/src/main/AndroidManifest.xml
• android/app/src/profile/AndroidManifest.xml

Role:: Android manifest files. These files relate to manifest settings for Android app/build

variants. The main manifest may include areas such as app label, icon, launch activity and ad application ID.

Flutter plugin and Android entry files

• android/app/src/main/java/io/flutter/plugins/GeneratedPluginRegistrant.java
• android/app/src/main/kotlin/com/example/ilk_uygulamam/MainActivity.kt
• android/app/src/main/kotlin/com/wordes/game/MainActivity.kt

Role:: Flutter plugin registration and Android native entry files. These files relate to Flutter plugin

registration on Android and native Android entry activities. They may be important when checking package/namespace transitions or native entry points. If more than one MainActivity path appears, the technical team may evaluate the active namespace together with the manifest connection.

Android drawable resource files

• android/app/src/main/res/drawable/background.png
• android/app/src/main/res/drawable/launch_background.xml
• android/app/src/main/res/drawable-v21/background.png
• android/app/src/main/res/drawable-v21/launch_background.xml
• android/app/src/main/res/drawable-hdpi/android12splash.png
• android/app/src/main/res/drawable-hdpi/ic_launcher_foreground.png
• android/app/src/main/res/drawable-hdpi/splash.png
• android/app/src/main/res/drawable-mdpi/android12splash.png
• android/app/src/main/res/drawable-mdpi/ic_launcher_foreground.png
• android/app/src/main/res/drawable-mdpi/splash.png
• android/app/src/main/res/drawable-xhdpi/android12splash.png
• android/app/src/main/res/drawable-xhdpi/ic_launcher_foreground.png
• android/app/src/main/res/drawable-xhdpi/splash.png
• android/app/src/main/res/drawable-xxhdpi/android12splash.png
• android/app/src/main/res/drawable-xxhdpi/ic_launcher_foreground.png
• android/app/src/main/res/drawable-xxhdpi/splash.png
• android/app/src/main/res/drawable-xxxhdpi/android12splash.png
• android/app/src/main/res/drawable-xxxhdpi/ic_launcher_foreground.png
• android/app/src/main/res/drawable-xxxhdpi/splash.png
• android/app/src/main/res/drawable-night-hdpi/android12splash.png
• android/app/src/main/res/drawable-night-mdpi/android12splash.png
• android/app/src/main/res/drawable-night-xhdpi/android12splash.png
• android/app/src/main/res/drawable-night-xxhdpi/android12splash.png
• android/app/src/main/res/drawable-night-xxxhdpi/android12splash.png

Role:: Android visual resource files. These files are density/theme-specific versions of Android

icon, splash, foreground or launch visuals.

Android mipmap icon files

• android/app/src/main/res/mipmap-anydpi-v26/ic_launcher.xml
• android/app/src/main/res/mipmap-hdpi/ic_launcher.png
• android/app/src/main/res/mipmap-mdpi/ic_launcher.png
• android/app/src/main/res/mipmap-xhdpi/ic_launcher.png
• android/app/src/main/res/mipmap-xxhdpi/ic_launcher.png
• android/app/src/main/res/mipmap-xxxhdpi/ic_launcher.png

Role:: Android launcher icon resources. These files are different density versions and adaptive

resources for the Android launcher icon.

Android values / styles files

• android/app/src/main/res/values/colors.xml
• android/app/src/main/res/values/styles.xml
• android/app/src/main/res/values-night/styles.xml
• android/app/src/main/res/values-night-v31/styles.xml
• android/app/src/main/res/values-v31/styles.xml

Role:: Android theme and style resource files. These files relate to Android themes, colors,

adaptive icons or launch background resource definitions.

Android Gradle / Wrapper files

• android/build.gradle.kts
• android/gradle.properties
• android/settings.gradle.kts
• android/gradle/wrapper/gradle-wrapper.jar
• android/gradle/wrapper/gradle-wrapper.properties
• android/gradlew
• android/gradlew.bat

Role:: Top-level Android Gradle and wrapper configuration. These files relate to Gradle, plugin,

repository, wrapper and build settings for the Android project.

10 - iOS Generated / Ephemeral Metadata

The files in this section may be generated during Flutter iOS build/debug processes or may be temporary helper files. They should not be evaluated as product business logic.

• ios/Flutter/ephemeral/flutter_lldbinit
• ios/Flutter/ephemeral/flutter_lldb_helper.py

Role:: iOS Flutter ephemeral files. These are helper files created during Flutter iOS build/debug

processes and may be regenerated by Flutter.

11 - iOS Platform Files

ios/.gitignore

Role:: iOS Git ignore settings

Description:: This file relates to iOS-side files that should not be included in version control.

When the buyer may review it:: Version control organization.

iOS Flutter configuration files

• ios/Flutter/AppFrameworkInfo.plist
• ios/Flutter/Debug.xcconfig
• ios/Flutter/Generated.xcconfig
• ios/Flutter/Release.xcconfig
• ios/Flutter/flutter_export_environment.sh

Role:: iOS Flutter configuration files. These files relate to Flutter’s iOS debug/release and

framework configuration. ios/Podfile

Role:: iOS CocoaPods configuration

Description:: This file relates to managing iOS dependencies through CocoaPods.

When the buyer may review it:: iOS plugin/SDK dependency setup.

Xcode project and workspace files

• ios/Runner.xcodeproj/project.pbxproj
• ios/Runner.xcodeproj/project.xcworkspace/contents.xcworkspacedata
• ios/Runner.xcodeproj/project.xcworkspace/xcshareddata/IDEWorkspaceChecks.plist
• ios/Runner.xcodeproj/project.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings
• ios/Runner.xcodeproj/xcshareddata/xcschemes/Runner.xcscheme
• ios/Runner.xcworkspace/contents.xcworkspacedata
• ios/Runner.xcworkspace/xcshareddata/IDEWorkspaceChecks.plist
• ios/Runner.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings

Role:: Xcode project, workspace and scheme metadata. These files relate to iOS Runner build

targets, file references, workspace, scheme and IDE settings. iOS native start and lifecycle files

• ios/Runner/AppDelegate.swift
• ios/Runner/SceneDelegate.swift
• ios/Runner/Runner-Bridging-Header.h

Role:: iOS native entry and bridge files. These files relate to iOS application start, Flutter

integration, scene/window lifecycle and Swift/Objective-C bridge structures.

iOS App Icon asset files

• ios/Runner/Assets.xcassets/AppIcon.appiconset/Contents.json
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-1024x1024@1x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-20x20@1x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-20x20@2x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-20x20@3x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-29x29@1x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-29x29@2x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-29x29@3x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-40x40@1x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-40x40@2x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-40x40@3x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-50x50@1x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-50x50@2x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-57x57@1x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-57x57@2x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-60x60@2x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-60x60@3x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-72x72@1x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-72x72@2x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-76x76@1x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-76x76@2x.png
• ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-83.5x83.5@2x.png

Role:: iOS app icon assets. These files relate to different sizes of the iOS app icon and the icon

asset catalog definition. iOS launch / splash asset and storyboard files

• ios/Runner/Assets.xcassets/LaunchBackground.imageset/background.png
• ios/Runner/Assets.xcassets/LaunchBackground.imageset/Contents.json
• ios/Runner/Assets.xcassets/LaunchImage.imageset/Contents.json
• ios/Runner/Assets.xcassets/LaunchImage.imageset/LaunchImage.png
• ios/Runner/Assets.xcassets/LaunchImage.imageset/LaunchImage@2x.png
• ios/Runner/Assets.xcassets/LaunchImage.imageset/LaunchImage@3x.png
• ios/Runner/Assets.xcassets/LaunchImage.imageset/README.md
• ios/Runner/Base.lproj/LaunchScreen.storyboard
• ios/Runner/Base.lproj/Main.storyboard

Role:: iOS launch/splash visual and storyboard resources. These files relate to the iOS launch

screen, splash image and start storyboard areas. iOS plugin registration files

• ios/Runner/GeneratedPluginRegistrant.h
• ios/Runner/GeneratedPluginRegistrant.m

Role:: iOS Flutter plugin registration files. These files relate to registering Flutter plugins on iOS

and are considered generated files.

ios/Runner/Info.plist

Role:: iOS Info.plist

Description:: This file relates to iOS app name, bundle details, ad application ID, tracking

description, orientation and launch settings.

When the buyer may review it:: iOS app metadata, privacy/tracking, ad ID and App Store

preparation.

ios/RunnerTests/RunnerTests.swift

Role:: iOS test file

Description:: This file is a test area created for the iOS Runner test target.

When the buyer may review it:: iOS test target or Xcode test adjustments.

12 - Practical First Review Order for the Buyer

After receiving the project, the buyer may prefer to proceed generally in the following order:

lib/pages/game_page.dart, lib/pages/tabu_page.dart and lib/services/locale_game_data_loader.dart to understand the general application chain.

page.

files.

selection page and Flutter asset declarations may be evaluated together.

progress_service and Android/iOS platform ad definitions may be reviewed together.

configuration, icon/splash resources and signing-related areas.

and iOS device/TestFlight process may be evaluated together.

• First, review pubspec.yaml, lib/main.dart, lib/models/game_mode.dart, lib/pages/home_page.dart,
• If reviewing game flows, start with home_page, then team_setup_page, then the related game
• For Riddle, Charades and Word Master modes, lib/pages/game_page.dart is one of the main review
• For Taboo, lib/pages/tabu_page.dart may be reviewed separately.
• For new language or content work, assets/game_data packages, the locale loader, the language
• For ads and premium, ad_service, ad_controller, purchase_service, diamond_shop_page,
• For Android publishing preparation, the technical team may review Android manifests, Gradle
• If iOS work is planned, iOS Runner, Info.plist, Xcode project files, AppIcon/Launch assets, Podfile

13 - Development Environment and Metadata Note

Some local/build metadata files may appear inside the zip. These should be evaluated as files related to the development environment, IDE or build process, rather than as part of the product logic. In particular, the following areas may be reviewed with this perspective by the technical team:

These areas are not the main sources for understanding the project logic. They are more relevant to the development environment, build process or platform file organization.

• .gradle cache files
• local.properties
• IDE metadata files
• Flutter/iOS ephemeral files
• Areas where similar sound effects appear under different folder names
• Native entry files that may remain from older package paths

14 - General Assessment

This file map was prepared to show the buyer what the main and supporting files in the WordES handover package may relate to. The content explains the orientation value of the files inside the project without sharing source code content. The current WordES structure provides a developable foundation for adding new content, new languages, regional packages, visual updates, premium/ad strategies and new game modes through code-side development.

This document is a short supporting note prepared to clarify the general handover approach after delivery of the WordES project, the buyer's own continuation process, and post-sale communication expectations. WordES is a mobile game project/asset package transferred with its existing project files, game modes, multilingual content architecture, and advertising/premium-related areas. After delivery, the buyer is expected to proceed with the project through their own team or advisors, in line with their own goals, technical assessment, release plan, accounts, and platform requirements. This document is intended to clarify that the transaction should not be treated as an ongoing development, maintenance, live release management, or post-sale technical support arrangement. The WordES handover should be understood within the scope of project/asset transfer. Due to mandatory military service, the seller may be unable to provide follow-up communication, technical support, development support, live release preparation, or post-release assistance for an extended period. Therefore, the buyer should plan the post-delivery technical review, modifications, release preparation, platform checks, and development process with their own technical team or external advisors. WordES is transferred as an existing project/asset package. The buyer may proceed with the project according to their own goals, accounts, store strategy, content plan, and technical assessment. The agreed price has been considered in light of the project's pre-revenue status, the as-is asset/project handover, the fact that it does not include ongoing post-sale technical support or development services, and the buyer's responsibility for their own technical/release process. After the transfer, the seller does not intend to claim any additional copyright royalty, revenue share, license fee, operational control, or continuing usage right over the transferred WordES project/asset package. The purpose of this note is to make post-delivery expectations clearer and to help the buyer plan their own continuation process appropriately. Prepared as a supporting handover note for the WordES project/asset package.

Data room support document - current project state / as-is handover summary This document summarizes the current product state, handover scope, and acquisition opportunity. It is intended to be reviewed together with the screen-recording walkthrough, financial snapshot, technical handover notes, and the buyer's own acquisition review process. WordES is a multilingual mobile word/party game project developed by the seller as a solo, bootstrapped product. The project is offered as an as-is acquisition opportunity based on its current codebase, mobile application structure, game ecosystem, content foundation, monetization design, premium model, localization structure, and expansion potential. The current Android-side product is demonstrated in the accompanying screen-recording walkthrough. As shown in the video, the app presents an active product flow with supported language/localization behavior, legal/contract screens, multiple game modes, team-based gameplay structure, premium-related screens, monetization-related screens, and general in-app behavior. The seller considers the Android-side product to be near-final from a handover perspective, based on the seller’s own testing and the current recorded walkthrough. The app is presented in its current working handover version as shown in the video. Because the seller has a fixed military service deadline and limited remaining availability, the product has not been taken through a full commercial launch cycle by the seller. The sale is offered as an as-is handover of the current project state, supported by the screen-recording walkthrough and data room materials. The buyer can use the walkthrough, documents, and their own review process to evaluate the project and complete any final store setup, live configuration, platform validation, and production-readiness steps before release.

WordES currently includes a 4-game ecosystem:

The project was designed to support future expansion. A buyer may build on the existing structure by adding new original content packs, custom categories, subcategories, regional content, seasonal content, language/locale-specific content, and potentially additional game modes depending on the buyer’s own product vision and technical roadmap. The team-based gameplay structure is also expandable. The current product supports up to 8 team options, and the team-mode experience may be further developed by the buyer according to their own gameplay, party-game, and market strategy. A key monetization advantage is that premium access is not separated by language. When a user has premium access, including temporary premium access, the same premium entitlement can remain available across the supported languages/locales instead of requiring a separate premium purchase for each language. This may increase the perceived value of premium access for multilingual users, families, and group-play scenarios. The current question/word content pool should be treated as a test-stage content foundation prepared with AI assistance for development and demonstration purposes. This gives the buyer a starting content structure that can be reviewed, improved, replaced, or expanded according to the buyer’s own content-quality standards, target markets, localization strategy, and copyright review. The asset/JSON-based content structure is intended to make future content updates practical. When the question/word pool is updated through the project’s content structure, the Word Bank can reflect the updated content within the existing app logic. This gives the buyer flexibility to refresh content, build original category packs, adapt the product for different regions, and improve content quality over time. The advertising structure is currently configured with test ad IDs intentionally kept for safe development, testing, and handover. Live AdMob/ad unit IDs are not included as seller-owned revenue assets and should be replaced by the buyer after acquisition using the buyer’s own advertising account. The buyer can then complete live ad configuration, consent/region-policy review, and production ad validation as part of their release process. The seller has not been able to complete real iOS device testing or App Store environment testing because the seller does not currently have access to an iOS device or an iOS testing environment. For general compatibility awareness, the seller performed an AI-assisted code-level review. Based on that AI-assisted review, no obvious code-level iOS incompatibility was identified, and the project appears to have an iOS-compatible structure at the code level. The seller notes that the AI-assisted review is a preliminary code-level support review and may not capture every platform-specific requirement. Because the seller could not personally test the project on a real iOS device or App Store environment, the buyer should complete their own iOS device testing, App Store validation, Apple-specific review, and platform-specific release checks before any iOS release. WordES is being positioned as a fast-close acquisition opportunity for a buyer with publishing, marketing, technical validation, store-launch, content-quality, localization, and user acquisition capacity. The project already includes a working Android-side handover version, a 4-game ecosystem, team-play structure, premium model, monetization foundation, localization behavior, asset/JSON content structure, Word Bank logic, and expansion flexibility. This handover document is provided to summarize the current product state and acquisition opportunity. It should be reviewed together with the screen-recording walkthrough, financial snapshot, technical handover notes, and the buyer’s own acquisition review process. Prepared as a seller-provided data room support document for buyer review and handover context.

• Taboo
• Riddle
• Charades
• Word Master

Revised data room support document | Seller-prepared | As-is handover context

Overview

WordES is a Flutter/Dart-based mobile word/party game project with an Android-side handover version demonstrated in the accompanying screen-recording walkthrough. This document summarizes the technical handover scope, current project structure, integration notes, and buyer-side release preparation items. The project is offered as an as-is handover of the current project state. The Android-side product is presented in its current working handover version as shown in the screen-recording walkthrough. The buyer can use the walkthrough, this document, the product overview, and their own review process to evaluate the project and complete any final release steps.

1. Project Structure

WordES is built around a Flutter/Dart mobile application structure. The project includes game screens, service logic, progress/premium handling, monetization-related structure, localization behavior, asset/JSON content handling, and Android-side project files. The codebase is intended to provide a practical foundation for a buyer who wants to continue development, complete final store setup, replace live configuration values, improve content, and expand the product.

2. Android-Side Status

The Android-side product is demonstrated in the screen-recording walkthrough. As shown in the video, the app presents an active product flow with supported language/localization behavior, legal/contract screens, multiple game modes, team-based gameplay structure, premium-related screens, monetization-related screens, Word Bank behavior, and general in-app usage. From the seller's handover perspective, the Android-side build is considered near-final based on the seller's own testing and the recorded walkthrough. The buyer should still complete their own final Android review, device checks, store setup, live configuration, and release validation as part of their own launch process.

3. Game Modes

WordES currently includes a 4-game ecosystem:

The existing structure may be extended by the buyer with new original content packs, custom categories, subcategories, regional content, seasonal content, language/locale-specific content, and potentially additional game modes depending on the buyer's own product vision and technical roadmap.

• Taboo
• Riddle
• Charades
• Word Master

4. Team-Based Gameplay

The project includes team-based gameplay support. The current product supports up to 8 team options. The team-mode experience may be further developed by the buyer according to their own gameplay strategy, party-game positioning, target audience, and market plan.

5. Asset / JSON Content Structure

WordES uses an asset/JSON-based content structure for question and word content. This structure is intended to make content management and future expansion practical. The current question/word pool should be treated as a test-stage content foundation prepared with AI assistance for development and demonstration purposes. The buyer can review, improve, replace, or expand the content pool according to their own content-quality standards, target markets, localization strategy, and copyright review. When the question/word pool is updated through the project's content structure, the Word Bank can reflect updated content within the existing app logic. This gives the buyer flexibility to refresh content, add original category packs, expand supported languages/locales, create regional or seasonal content, and adapt the product for different markets.

6. Localization Structure

The project includes language/localization behavior demonstrated in the screen-recording walkthrough. The app is shown operating across the currently supported language/localization structure as observed by the seller during the recording. The buyer can review the existing localization structure, add or refine language/locale content, and complete their own final language, content, and market-specific validation before release.

7. Premium Model

WordES includes a premium access model and premium-related application logic. A key monetization advantage is that premium access is not separated by language. When a user has premium access, including temporary premium access, the same premium entitlement can remain available across the supported languages/locales instead of requiring a separate premium purchase for each language. This may increase the perceived value of premium access for multilingual users, families, and group-play scenarios.

8. Advertising Integration and SDK Notes

WordES includes an advertising integration structure configured for safe demo and testing with Google's official test ad units. The project is currently configured with test ad IDs intentionally kept for safe development, testing, and handover. Live AdMob or other live ad unit IDs are not included as seller-owned revenue assets. After acquisition, the buyer can replace the test ad IDs with their own live ad units using their own advertising account. During Android test build processes, standard Java compatibility or dependency-level notices may appear from third-party advertising dependencies such as Google Mobile Ads. These notices are understood as normal SDK/dependency maintenance context on the advertising/Android dependency side and are not presented as part of the core WordES gameplay logic or the tested user flow shown in the walkthrough. Before live release, the buyer should complete live ad configuration, consent/region-policy review, production ad validation, and any routine SDK/dependency updates as part of their own release process.

9. Store Setup, Live Purchase, and Restore Validation

The project includes monetization and premium-related logic, but live store configuration should be completed by the buyer after acquisition. The buyer should configure their own store accounts, product IDs, live purchase settings, live ad units, payment-related store setup, and restore validation according to their own publishing environment. Restore behavior, live purchase behavior, and store-specific production behavior should be reviewed by the buyer in their own live or pre-release store environment before public release.

10. iOS / App Store Notes

The seller has not completed real iOS device testing or App Store environment testing because the seller does not currently have access to an iOS device or iOS testing environment. For general compatibility awareness, the seller performed an AI-assisted code-level review. Based on that AI-assisted review, no obvious code-level iOS incompatibility was identified, and the project appears to have an iOS-compatible structure at the code level. The seller notes that the AI-assisted review is a preliminary code-level support review and may not capture every platform-specific requirement. Because the seller could not personally test the project on a real iOS device or App Store environment, the buyer should complete their own iOS device testing, App Store validation, Apple-specific review, and platform-specific release checks before any iOS release.

11. Sensitive Assets and Controlled Sharing

The data room materials are intended to support buyer evaluation without exposing sensitive credentials prematurely. The following items should be handled only in a controlled serious-buyer, escrow, or due-diligence context:

The buyer should replace all seller-side test or placeholder configuration values with their own production configuration during their release preparation.

• Full source code access
• Keystore files
• Keystore passwords
• API keys
• AdMob account credentials
• Google Play account credentials
• App Store account credentials
• Payment account credentials
• Any other production secrets or private credentials

12. Handover Positioning

WordES is positioned as a current working Android-side handover version with a 4-game ecosystem, team-play support, premium model, advertising integration structure, localization behavior, asset/JSON content foundation, Word Bank logic, and future expansion flexibility. This technical note is provided as handover support material. It should be reviewed together with the product overview, screen-recording walkthrough, financial snapshot, and the buyer's own acquisition review process.

This document is a short, directional and supporting note prepared to help the buyer review the asset and content files included in the WordES handover package more easily. Its purpose is not to explain each file technically one by one, but to summarize how the current asset and content structure may be evaluated. Asset and content files in WordES may relate to game modes, language/locale structure, visual resources, sound effects and user experience areas. This document should not be treated as a complete technical inventory of all assets in the handover package or as a definitive importance ranking. Final content, quality, language, release and store-related evaluation should be made by directly reviewing the delivered project files. The current word, question and game content was prepared as an AI-assisted test/demo content pool to demonstrate WordES’s multilingual and expandable content structure. For this reason, the handover notes do not provide an exact number of words, questions, riddles, cards or total content items. These contents should not be treated as a fixed final release content package. The current word, question and game content pools were prepared for test/demo purposes. Before final release, it is recommended that the buyer rebuild these pools from start to finish according to their own target audience, quality standards, language/cultural expectations and release strategy. If new content or a new language is planned, the technical team may review the existing locale content packages, content loading flow and asset declarations. However, rebuilding the final content pool according to the buyer’s own target market and release strategy would be the healthier approach. The buyer may review the existing assets and test/demo content as reference material, edit them, reduce them, expand them or replace them entirely with new content packages according to their own release plan.

This note has been prepared as a short, directional, and supporting handover note to help the buyer review the advertising-related areas in the WordES delivery package more easily. Its purpose is not to explain advertising code or service structures line by line, but to summarize how the existing advertising/test configuration may be evaluated. Advertising display flows in WordES may need to be considered together with user access, premium status, consent/privacy preferences, platform configuration, and store policies. This note should not be read as a complete technical inventory, live release guide, or policy compliance statement for the advertising structure. Final advertising, store, consent, privacy, and monetization evaluation should be made by directly reviewing the delivered project files and through the buyer’s own accounts. The advertising setup in WordES has been prepared with test ad identifiers that may be used during development and safe testing. The existing ad identifiers should be treated as test/demo references for reviewing ad flows, not as live revenue-generating ad units. Before a live release or any buyer-specific monetization plan, the buyer should reconfigure the advertising setup according to their own AdMob account, store account, privacy/consent requirements, target market, and publishing strategy. If live advertising is planned, the buyer’s technical team may review these areas together:

The test advertising configuration included in the delivery package does not replace the buyer’s own live advertising account or store account. Live ad serving, ad revenue, fill rate, AdMob account eligibility, store approval, and regional policy suitability should be handled within the buyer’s own accounts, publishing environment, and evaluation process. The buyer may review the current test advertising configuration as a reference, replace it entirely, or rebuild it according to their own monetization strategy. This note is a short orientation note intended to support the buyer on the advertising and monetization side. Final live ad setup, advertising account connections, store suitability, consent/privacy evaluation, and monetization decisions should be made according to the buyer’s own technical, commercial, and publishing goals.

• Replacing test ad identifiers with the buyer’s own live ad identifiers
• Android and, if applicable, iOS advertising configuration
• Advertising services and ad display flows
• Ad-free experience logic for premium users
• Rewarded ads, interstitial ads, or similar ad usage points
• Consent, privacy, and user permission flows
• Google Play, App Store, and AdMob policy requirements

WordES - Seller-Prepared Unaudited Financial

Snapshot

Data room support material - seller-prepared and unaudited

Project:: WordES

Prepared by:: Seller

Statement Type:: Seller-prepared, unaudited financial snapshot

Stage:: Development / pre-launch / handover stage

1. Overview

WordES is being offered as an asset-led acquisition opportunity rather than a historical revenue-led acquisition. The project is currently positioned around its current working Android-side handover version shown in the screen-recording walkthrough, its codebase, 4-game ecosystem, premium model, advertising integration structure, localization behavior, asset/JSON content foundation, Word Bank logic, and future expansion flexibility. The Android-side product has been tested by the seller and is demonstrated in the accompanying walkthrough video. The seller has not completed real iOS device testing or App Store environment testing because the seller does not currently have access to an iOS device or iOS testing environment. However, for general compatibility awareness, the seller performed an AI-assisted code-level review. Based on that AI-assisted review, no obvious code-level iOS incompatibility was identified, and the project appears to have an iOS-compatible structure at the code level. The buyer should complete their own iOS device testing, App Store validation, Apple-specific review, and platform-specific release checks before any iOS release. The seller has developed WordES as a solo, bootstrapped project using personal time, development work, and limited personal resources. The project has not been taken through a full seller-led commercial launch cycle due to the seller's fixed military service deadline, urgent personal financial needs, marriage plans after military service, family responsibilities, and very limited remaining availability.

2. Time-Sensitive Sale and Pricing Context

This is a time-sensitive acquisition opportunity. The seller currently has approximately 14 days available to complete the sale process, including buyer discussions, data room review, handover preparation, and closing coordination. The project is being offered at an attractive price because of the seller's limited timeline, urgent cash needs, fixed military service schedule, and personal/family commitments after military service. The pricing should not be interpreted as a reflection of low product potential or lack of belief in WordES. On the contrary, WordES was designed with the ambition to compete strongly in its word/party game category. Based on the seller's product assessment, structure, and expansion analysis, WordES has the characteristics of a category-leadership candidate if taken over by the right buyer with strong publishing, marketing, content-quality, localization, technical validation, and user acquisition execution. With the right strategy, store positioning, content improvement, regional launch plan, monetization execution, and continued development, the project may be capable of competing at a very high level in its category. The seller would prefer the product to be acquired by a buyer who understands its potential and can execute the next stage more effectively than the seller can under the current personal timeline.

3. Revenue Snapshot

WordES is being handed over before a full seller-led commercial monetization rollout. As a result, the seller is not presenting historical recurring revenue as the basis of this acquisition. The acquisition opportunity should be reviewed primarily through the product assets, codebase, application structure, monetization foundation, premium model, localization structure, content expansion system, working Android-side handover version, iOS code-level compatibility position, and buyer-side launch potential rather than past financial performance.

4. Advertising Revenue Position

WordES includes an advertising integration structure configured with Google's official test ad units for safe development, testing, demonstration, and handover. Live AdMob or other live advertising unit IDs are not included as seller-owned revenue assets. After acquisition, the buyer can replace the test ad IDs with their own live ad units using their own advertising account. Advertising monetization should be evaluated by the buyer based on their own publishing plan, target markets, consent/region-policy setup, live ad configuration, user acquisition strategy, and release environment.

5. In-App Purchase / Premium Revenue Position

WordES includes premium-related application logic and a premium access model. A key monetization advantage is that premium access is not separated by language. When a user has premium access, including temporary premium access, the same premium entitlement can remain available across the supported languages/locales instead of requiring a separate premium purchase for each language. This may increase the perceived value of premium access for multilingual users, families, and group-play scenarios. The buyer can configure their own store products, live purchase settings, payment-related setup, and restore validation as part of their own release process.

6. Cost / Funding Position

WordES was developed as a bootstrapped project. No venture capital, angel investment, crowdfunding, grants, or external loans were used to build the project. The project was primarily created through the seller's own development work, personal time, and limited personal resources. This gives the project a clean and simple ownership position from the seller's side, with no outside investors or financing parties attached to the sale.

7. Asset-Based Value Context

Because WordES is being offered before a full seller-led commercial launch, the project should be assessed as a current product and technical asset rather than only through historical profit and loss performance.

seasonal content, and language/locale-specific content

• Current working Android-side handover version shown in the screen recording
• Flutter/Dart codebase
• Android project structure
• AI-assisted iOS code-level compatibility review position
• 4-game ecosystem: Taboo, Riddle, Charades, and Word Master
• Team-based gameplay structure with up to 8 team options
• Premium model and premium access logic
• Premium access behavior that can remain usable across supported languages/locales
• Advertising integration structure with test ad IDs
• Asset/JSON-based question and word content structure
• Word Bank logic that can reflect updated content through the existing app structure
• Localization behavior and supported language/locale structure
• Expandable content foundation for new original content packs, custom categories, subcategories, regional content,
• Potential for future game-mode expansion depending on the buyer's product vision and technical roadmap

8. Content Pool Position

The current question/word content pool should be understood as a test-stage content foundation prepared with AI assistance for development and demonstration purposes. This gives the buyer a practical starting structure that can be reviewed, improved, replaced, or expanded according to the buyer's own content-quality standards, target markets, localization strategy, and copyright review. The structure is intended to make content updates practical. When the question/word pool is updated through the project's content structure, the Word Bank can reflect updated content within the existing app logic. This supports future content refreshes, category expansion, localization improvements, and market-specific content development.

9. Release Preparation Context

The buyer can use the screen-recording walkthrough, product overview, technical handover notes, this financial snapshot, and their own acquisition review process to evaluate the project. Before public release, the buyer can complete their own final store setup, live ad configuration, live purchase setup, restore validation, content-quality review, Android/iOS validation, platform-specific review, and production-readiness steps as part of their own publishing process.

10. Summary

WordES is being positioned as a fast-close acquisition opportunity for a buyer with publishing, marketing, technical validation, store-launch, content-quality, localization, and user acquisition capacity. The attractive pricing is driven by the seller's limited timeline, military service deadline, urgent cash needs, and personal/family commitments, not by a lack of confidence in the product's potential. The project was designed to become a strong competitor in its category and may be positioned as a category-leadership candidate with the right execution. This financial snapshot is provided to explain the current financial context of the project at the handover stage. It should be reviewed together with the product overview, screen-recording walkthrough, technical handover notes, and the buyer's own acquisition review process.

11. Final Handover Note

The sale is intended to be completed as an as-is handover of the current WordES project state. The seller has reviewed and tested the product within the available time and has also prepared supporting walkthrough and handover materials to show the current product condition. Because of the seller's limited timeline, military service deadline, and personal/family commitments, the seller believes that one final buyer-side review before public release would be the healthiest next step. This should be understood as a normal final release-preparation step in a mobile app acquisition, not as an indication that WordES is broken or incomplete. The current walkthrough may show that WordES is already in a strong handover position. A buyer's final review may confirm the current state, identify small refinements, or guide the last release-preparation steps according to the buyer's own store setup, target markets, content standards, and publishing strategy. The seller is offering WordES at this stage because the remaining time is too limited to personally complete another deep review cycle before military service. For the right buyer, this creates a practical fast-close opportunity to take over a developed product foundation, complete the final release review under their own standards, and move the project into the next stage.

Seller-prepared gross potential analysis

Pre-revenue mobile game asset - May 2026

Important Notice

This document is a seller-prepared illustrative gross potential model. It is not a revenue, profit, store approval, investment outcome, or business performance guarantee.

Purpose of This Financial Model

This document explains illustrative financial scenarios and the market-potential model prepared for the WordES mobile game asset. All numbers in this document are based on estimated analysis scenarios. This document does not guarantee revenue, profit, business performance, investment outcome, store approval, ad revenue, premium conversion, or commercial success.

WordES is positioned as a scalable multilingual mobile game foundation with 15-language localization architecture, JSON-based content structure, a 4-in-1 game system, app-wide premium logic, and advertising/premium monetization structure.

The target market/population model is based on a 4B+ potential audience population base across selected markets including Turkey, the United Kingdom, the United States, Spain, Germany, France, Italy, Portugal, Brazil, Russia, Saudi Arabia, India, Korea, China, and Japan. This does not represent active users, customers, downloads, or revenue. It is only a strategic base for describing potential addressable market size.

Target Population and Market Base

Illustrative market-base page only. Not a revenue guarantee. The 4B+ figure is used as a broad potential audience population base for strategic modeling.

15 Target Markets

Turkey, United Kingdom, United States, Spain, Germany, France, Italy, Portugal, Brazil, Russia, Saudi Arabia, India, Korea, China, Japan

Penetration and Premium Buyers

Premium calculation uses a base 5% conversion assumption and a $3.99 price point.

Premium gross is modeled as a base potential pool, not guaranteed actual sales.

Monthly Advertising Potential

Estimated MAU is modeled as 50% of the total user scenario. The model then applies 40 monetized ad impressions per estimated monthly active user per month. This is why the blended impression load equals approximately 20 monetized impressions per total user in the broader scenario base. Ad gross formula: impressions / 1,000 x eCPM.

Base eCPM assumption: $3 per 1,000 impressions. Actual ad results may vary by geography, consent rules, fill rate, eCPM, platform policies and execution.

Annual Gross Potential

Annual Gross Potential = Premium Gross + (Monthly Ad Gross x 12).

Gross figures are before costs, taxes, platform fees and provider deductions. Illustrative scenarios only.

10-Year Modeled Potential Target

The 10-year target is not Annual x 10. It uses a phased ramp factor: Y1 25%, Y2 45%, Y3 65%, Y4 80%, Y5 90%, Y6-Y10 100% = 8.05x cumulative.

Illustrative 10-year strategic target only. Actual outcomes depend on buyer execution.

Model Notes and Limitations

All premium, advertising, annual and 10-year figures are illustrative gross potential models only. They do not include provider/platform deductions, app store commissions, ad network deductions where applicable, payment processing fees, taxes, refunds, chargebacks, currency conversion, bank transfer costs, marketing spend, operating costs, legal/accounting costs, publishing costs, or any other buyer-side execution expenses.

Actual results may be higher or lower depending on buyer execution, product quality, publishing strategy, retention, localization, market conditions, ad fill rate, eCPM, consent rules, geography, monetization optimization, platform policies and long-term operational discipline. These figures are not revenue, profit, business performance, investment outcome, store approval, or monetization guarantees.

WordES is a handover-ready pre-revenue mobile game asset opportunity. Buyer completes final publishing, store setup, production checks, monetization setup, Android/iOS validation, and go-to-market execution.

This material is prepared for informational listing and buyer-review purposes. Qualified buyers may submit questions before moving forward. More detailed information, listing details, and controlled data room access can be requested through direct communication.

Disclaimer

This material is for illustrative strategic analysis only. It is not a guarantee of revenue, profit, business performance, store approval, investment outcome, or commercial result. Actual results may be materially higher or lower depending on execution, market conditions, product development, monetization, localization, platform policies, and buyer strategy.

Data Room Support Material

Overview

This document describes the comprehensive silent Android-side screen-recording walkthrough prepared for the WordES acquisition data room. The screen recording demonstrates the current Android-side product flow of WordES as shown by the seller. It visually presents the app’s supported language/localization behavior, legal/contract screens, multiple game modes, team-based gameplay structure, premium-related screens, monetization-related screens, Word Bank behavior, and general in-app experience. The video is silent and is intended as a visual product walkthrough. There is no voice narration. The purpose of the recording is to help buyers review the current working handover version of the Android-side product together with the supporting data room documents.

Game Ecosystem Shown in the Video

As shown in the walkthrough, WordES currently includes a 4-game ecosystem:

• Taboo
• Riddle
• Charades
• Word Master

Language and Localization Flow

The video also demonstrates the product’s language/localization flow. Based on the seller’s observation during the recording, the app operates across the currently supported language/localization structure shown in the walk- through. The buyer can review the video and complete their own final language, localization, content, and release checks as part of their acquisition review process.

Premium Access Advantage

A key product advantage shown in the project is that premium access is not separated by language. When a user has premium access, including temporary premium access, the same premium entitlement can remain available across the supported languages/locales instead of requiring a separate premium purchase for each language. This can strengthen the perceived value of premium access for multilingual users, families, and group-play scenarios.

Advertising Setup Shown in the Project

The project currently uses test ad IDs for advertising integration. These test ad IDs have been intentionally kept for safe development, testing, and handover. Live AdMob or other live ad unit IDs are not included as seller-owned revenue assets. After acquisition, the buyer can replace the test ad IDs with their own live ad units, using their own advertising account, and complete live ad configuration, consent/region-policy review, and release validation as part of their own launch process.

Content Pool and Word Bank Structure

The current question and word content pool should be understood as a test-stage content foundation prepared with AI assistance for development and demonstration purposes. This gives the buyer a practical starting structure that can be reviewed, improved, replaced, or expanded according to the buyer’s own content-quality standards, target markets, localization plan, and copyright review. The asset/JSON-based content structure is designed to make future content updates practical. When the ques- tion/word pool is updated through the project’s content structure, the Word Bank can reflect updated content within the existing app logic. This gives the buyer flexibility to refresh content, add original category packs, expand supported languages/locales, create regional or seasonal content, and adapt the product for different markets.

iOS Compatibility Review Context

The seller has not completed real iOS device testing or App Store environment testing because the seller does not currently have access to an iOS device or iOS testing environment. For general compatibility awareness, the seller performed an AI-assisted code-level review. Based on that AI-assisted review, no obvious code-level iOS incompatibility was identified, and the project appears to have an iOS-compatible structure at the code level. The seller notes that the AI-assisted review is a preliminary code-level support review and may not capture every platform-specific requirement. Because the seller could not personally test the project on a real iOS device or App Store environment, the buyer should complete their own iOS device testing, App Store validation, Apple-specific review, and platform-specific release checks before any iOS release.

Review Context

This screen recording description is provided as data room support material. It should be reviewed together with the video, product overview and handover notes, financial snapshot, technical handover notes, and the buyer’s own acquisition review process.

Prepared as supporting buyer review material for the WordES acquisition listing.

Purpose:: Backup video access for buyer review and due diligence.

Backup Access Notice

The Android product and localization walkthrough video has been uploaded directly to the Acquire listing when supported by the platform. This Google Drive link is provided as a backup access option in case the uploaded video cannot be viewed properly, processed correctly, or accessed through the platform during buyer review.

Google Drive Video Link

https://drive.google.com/file/d/1ku6bxfGToU6vX3dv0hiDMsThRkj-DGxX/view?usp=sharing

Access & Permission Note

The backup video is provided through a view-only Google Drive link. No edit access is granted to the original hosted file.

Review & Due Diligence Note

The video is provided for buyer review and due diligence purposes only. The sale remains as-is, and the buyer is encouraged to review the available documents, screenshots, video materials, and app package before completing the transaction.

The screenshots are presented in the dedicated gallery page.

Open Gallery