GAMEZONE ARENA — COD Orders, Checkout Location & Online Ludo Bug Fixes
Budget / Salary₹600–1,500
TypeFreelance project
LocationRemote
Posted2 hours ago
FIXED BUDGET
US$10–15 maximum. Preferred budget: US$10.
PROJECT OVERVIEW
I need an experienced Expo React Native developer to inspect and fix specific bugs in my existing GAMEZONE ARENA Android application.
I will provide the complete project ZIP file. The developer must inspect the actual source code first, identify the existing defects, implement the required fixes, and return the corrected files and any necessary Supabase SQL/RLS code.
This is a targeted bug-fixing task. Do not rebuild the application from scratch.
I will not provide access to my private Supabase or Clerk accounts. I will apply reviewed SQL migrations myself.
TASK 1 — COD ORDER CONFIRMATION AND COMPLETE BUYER–SELLER WORKFLOW
The existing COD order-saving functionality must be inspected first. Do not assume it is broken or replace it without evidence.
Required behavior:
1. Verify that a buyer's COD order is saved correctly.
2. Verify that the order appears in the correct seller's Seller Orders screen.
3. Verify that the buyer's My Orders screen displays the correct order.
4. Ensure orders are associated with the correct buyer and seller.
5. Allow the seller to accept or reject an order.
6. When the seller accepts an order, update the order status and notify the buyer that the order is confirmed.
7. When an order is rejected, notify the buyer and display the correct status.
8. Notify the seller when a new buyer order is placed.
9. Notify the appropriate parties when relevant order statuses change.
10. Display order confirmations and notifications inside the app.
11. Implement Android home-screen/system push notifications for order events if feasible within the agreed scope.
12. Prevent duplicate orders and duplicate notifications where appropriate.
13. Preserve existing orders, order history, multiple-order support, and working checkout functionality.
Inspect the existing order RPC, database schema, authentication, RLS policies, queries, and status values before changing the code.
Do not claim that order saving is fixed or broken without evidence from the supplied source and available tests.
TASK 2 — CHECKOUT CURRENT LOCATION AND MAP
Add a working Current Location feature to the existing Checkout/Basket screen.
Requirements:
1. Add a clearly visible Use Current Location button.
2. Request the required Android location permissions.
3. Obtain the current GPS coordinates.
4. Use reverse geocoding to autofill available delivery-address fields.
5. Integrate a map or location picker if feasible within the agreed scope and compatible with the existing project.
6. Let the buyer review and edit the address before placing the order.
7. Save latitude and longitude when available and supported by the existing backend.
8. Keep manual address entry available if location permission is denied.
9. Preserve the existing COD checkout and order-saving flow.
Document any external map service or API key requirement. Do not invent or replace existing map infrastructure unnecessarily.
TASK 3 — MY BUSINESS: ADD MY SERVICE / ADD MY BUSINESS DELETE BUG
Inspect the existing Add My Service and Add My Business flows.
Reported problem:
- An item created through Add My Service may not be deleting correctly from the relevant My Business screen.
Requirements:
1. Trace the actual screen, delete handler, database query, and relevant RLS policies.
2. Verify that the correct item ID is used for deletion.
3. Verify whether the deletion succeeds in the database or only appears successful in the UI.
4. Correct the delete operation so the intended listing is removed.
5. Show a success message only after successful deletion.
6. Display a clear error if deletion fails.
7. Ensure one Delete button does not trigger deletion for multiple cards.
8. Preserve owner-only deletion permissions.
9. Do not delete unrelated listings, services, products, or business records.
10. Do not change public marketplace behavior unnecessarily.
Inspect the existing source and relevant SQL before deciding the cause.
TASK 4 — ONLINE LUDO AUTOMATIC PLAYER MATCHMAKING
Inspect and fix the existing Online Ludo player-search functionality.
Requirements:
1. Automatically search for available online players when the user starts matchmaking.
2. Do not require repeated manual Search button presses or manual refreshing.
3. Show a clear Searching/Matching status.
4. When a compatible player is available, match the players through the existing game flow.
5. If no compatible player is available within the defined timeout, show Player Not Available or an equivalent clear message.
6. Handle timeout, retry, cancellation, and leaving the matchmaking screen correctly.
7. Prevent duplicate matchmaking requests and duplicate matches.
8. Inspect the actual backend, database, and realtime implementation before making changes.
9. Preserve existing Online Ludo functionality.
10. Do not create a completely new multiplayer backend unless the supplied code proves it is necessary.
Online Ludo Chat and Calling
Inspect whether the existing Online Ludo architecture supports player-to-player chat or calling.
- If feasible within the agreed budget, add or repair the appropriate in-game chat functionality.
- Investigate voice calling separately and explain any required third-party service, signaling server, permissions, or additional infrastructure.
- Do not claim that voice calling works if only a button or interface has been added.
- If chat and calling cannot realistically fit within the fixed budget, identify them clearly as additional scope before implementation.
TASK 5 — LUDO DICE AND TOKEN SOUND TIMING
Correct the existing Android sound effects without removing working game audio.
Requirements:
1. Dice-roll sound must start immediately when the dice-roll action occurs.
2. Token movement sound must start promptly when the token begins moving.
3. The token capture/cut sound must play immediately when an opponent's token is captured.
4. Avoid unnecessary delays caused by animations, asynchronous operations, or player initialization.
5. Avoid duplicate sounds for a single game event.
6. Ensure audio stops correctly when movement ends or the game screen closes.
7. Preserve existing background music and other working sound effects.
8. Test repeated dice rolls, repeated token movements, captures, and rapid successive events on Android.
Inspect the actual event handlers, audio players, loading states, and lifecycle before changing the implementation.
TASK 6 — LUDO WINNER APPLAUSE SOUND
Add a suitable applause/cheering sound when the game logic confirms that a player has won.
Requirements:
1. Play the applause sound at the correct winner event.
2. Make the sound clearly audible and appropriately loud without clipping or distortion.
3. Prevent repeated playback caused by React rerenders or repeated winner-state updates.
4. Do not delay the winner screen.
5. Preserve the existing winner logic and other audio.
6. Use a properly licensed sound asset and document its source.
SECURITY AND DEVELOPMENT RULES
- Inspect the supplied ZIP before making changes.
- Work on the existing Expo React Native application only.
- Do not rebuild the app from scratch.
- Do not remove working features.
- Do not change website or AdSense files.
- Do not request private Supabase or Clerk account access.
- Do not request passwords, production credentials, or secret keys.
- Do not modify the live production database.
- Inspect the existing SQL migrations and schema references before preparing new SQL.
- Do not guess table names, RPC parameters, columns, IDs, or status values.
- Do not delete existing orders, products, users, services, or business data.
- Do not use destructive SQL.
- Prepare complete SQL/RLS migrations for me to review and apply myself.
- Include required database functions, triggers, grants, and notification logic if actually needed.
- Clearly separate verified fixes from features requiring further testing.
- Do not claim that an untested feature works.
REQUIRED DELIVERABLES
Return:
1. A report identifying the actual defects found in the supplied ZIP.
2. Complete corrected source files or a clean patch.
3. The complete Supabase SQL migration, including required RLS policies and database functions.
4. Any required notification server/Edge Function code, if push notifications are included.
5. Any required Android permission or package changes.
6. Any new Ludo sound assets and their licensing information.
7. Exact instructions for replacing or adding each source file.
8. Exact instructions for reviewing and applying the SQL in my own Supabase account.
9. A test report listing the tests performed and actual results.
10. A list of remaining limitations and features not completed.
ACCEPTANCE CRITERIA
The work must demonstrate that:
- COD orders remain saved correctly.
- Buyer and seller order lists show the correct orders.
- Seller acceptance/rejection updates the buyer's order status.
- Appropriate buyer and seller notifications are generated.
- Home-screen/system push notifications are verified separately if implemented.
- Checkout Current Location works and manual address entry remains available.
- The reported My Business deletion issue is corrected.
- Online Ludo automatically searches for players and handles unavailable players clearly.
- Dice, movement, and capture sounds play promptly.
- Winner applause plays at the correct time.
- Existing functionality and historical orders remain intact.
First inspect the complete ZIP and identify the actual defects. Then fix the existing code and return the complete corrected files and SQL/RLS code. Do not request private account access or modify the live database.
Before accepting the project, confirm what can realistically be completed within the US$10–15 maximum budget and identify any additional-cost requirements.
US$10–15 maximum. Preferred budget: US$10.
PROJECT OVERVIEW
I need an experienced Expo React Native developer to inspect and fix specific bugs in my existing GAMEZONE ARENA Android application.
I will provide the complete project ZIP file. The developer must inspect the actual source code first, identify the existing defects, implement the required fixes, and return the corrected files and any necessary Supabase SQL/RLS code.
This is a targeted bug-fixing task. Do not rebuild the application from scratch.
I will not provide access to my private Supabase or Clerk accounts. I will apply reviewed SQL migrations myself.
TASK 1 — COD ORDER CONFIRMATION AND COMPLETE BUYER–SELLER WORKFLOW
The existing COD order-saving functionality must be inspected first. Do not assume it is broken or replace it without evidence.
Required behavior:
1. Verify that a buyer's COD order is saved correctly.
2. Verify that the order appears in the correct seller's Seller Orders screen.
3. Verify that the buyer's My Orders screen displays the correct order.
4. Ensure orders are associated with the correct buyer and seller.
5. Allow the seller to accept or reject an order.
6. When the seller accepts an order, update the order status and notify the buyer that the order is confirmed.
7. When an order is rejected, notify the buyer and display the correct status.
8. Notify the seller when a new buyer order is placed.
9. Notify the appropriate parties when relevant order statuses change.
10. Display order confirmations and notifications inside the app.
11. Implement Android home-screen/system push notifications for order events if feasible within the agreed scope.
12. Prevent duplicate orders and duplicate notifications where appropriate.
13. Preserve existing orders, order history, multiple-order support, and working checkout functionality.
Inspect the existing order RPC, database schema, authentication, RLS policies, queries, and status values before changing the code.
Do not claim that order saving is fixed or broken without evidence from the supplied source and available tests.
TASK 2 — CHECKOUT CURRENT LOCATION AND MAP
Add a working Current Location feature to the existing Checkout/Basket screen.
Requirements:
1. Add a clearly visible Use Current Location button.
2. Request the required Android location permissions.
3. Obtain the current GPS coordinates.
4. Use reverse geocoding to autofill available delivery-address fields.
5. Integrate a map or location picker if feasible within the agreed scope and compatible with the existing project.
6. Let the buyer review and edit the address before placing the order.
7. Save latitude and longitude when available and supported by the existing backend.
8. Keep manual address entry available if location permission is denied.
9. Preserve the existing COD checkout and order-saving flow.
Document any external map service or API key requirement. Do not invent or replace existing map infrastructure unnecessarily.
TASK 3 — MY BUSINESS: ADD MY SERVICE / ADD MY BUSINESS DELETE BUG
Inspect the existing Add My Service and Add My Business flows.
Reported problem:
- An item created through Add My Service may not be deleting correctly from the relevant My Business screen.
Requirements:
1. Trace the actual screen, delete handler, database query, and relevant RLS policies.
2. Verify that the correct item ID is used for deletion.
3. Verify whether the deletion succeeds in the database or only appears successful in the UI.
4. Correct the delete operation so the intended listing is removed.
5. Show a success message only after successful deletion.
6. Display a clear error if deletion fails.
7. Ensure one Delete button does not trigger deletion for multiple cards.
8. Preserve owner-only deletion permissions.
9. Do not delete unrelated listings, services, products, or business records.
10. Do not change public marketplace behavior unnecessarily.
Inspect the existing source and relevant SQL before deciding the cause.
TASK 4 — ONLINE LUDO AUTOMATIC PLAYER MATCHMAKING
Inspect and fix the existing Online Ludo player-search functionality.
Requirements:
1. Automatically search for available online players when the user starts matchmaking.
2. Do not require repeated manual Search button presses or manual refreshing.
3. Show a clear Searching/Matching status.
4. When a compatible player is available, match the players through the existing game flow.
5. If no compatible player is available within the defined timeout, show Player Not Available or an equivalent clear message.
6. Handle timeout, retry, cancellation, and leaving the matchmaking screen correctly.
7. Prevent duplicate matchmaking requests and duplicate matches.
8. Inspect the actual backend, database, and realtime implementation before making changes.
9. Preserve existing Online Ludo functionality.
10. Do not create a completely new multiplayer backend unless the supplied code proves it is necessary.
Online Ludo Chat and Calling
Inspect whether the existing Online Ludo architecture supports player-to-player chat or calling.
- If feasible within the agreed budget, add or repair the appropriate in-game chat functionality.
- Investigate voice calling separately and explain any required third-party service, signaling server, permissions, or additional infrastructure.
- Do not claim that voice calling works if only a button or interface has been added.
- If chat and calling cannot realistically fit within the fixed budget, identify them clearly as additional scope before implementation.
TASK 5 — LUDO DICE AND TOKEN SOUND TIMING
Correct the existing Android sound effects without removing working game audio.
Requirements:
1. Dice-roll sound must start immediately when the dice-roll action occurs.
2. Token movement sound must start promptly when the token begins moving.
3. The token capture/cut sound must play immediately when an opponent's token is captured.
4. Avoid unnecessary delays caused by animations, asynchronous operations, or player initialization.
5. Avoid duplicate sounds for a single game event.
6. Ensure audio stops correctly when movement ends or the game screen closes.
7. Preserve existing background music and other working sound effects.
8. Test repeated dice rolls, repeated token movements, captures, and rapid successive events on Android.
Inspect the actual event handlers, audio players, loading states, and lifecycle before changing the implementation.
TASK 6 — LUDO WINNER APPLAUSE SOUND
Add a suitable applause/cheering sound when the game logic confirms that a player has won.
Requirements:
1. Play the applause sound at the correct winner event.
2. Make the sound clearly audible and appropriately loud without clipping or distortion.
3. Prevent repeated playback caused by React rerenders or repeated winner-state updates.
4. Do not delay the winner screen.
5. Preserve the existing winner logic and other audio.
6. Use a properly licensed sound asset and document its source.
SECURITY AND DEVELOPMENT RULES
- Inspect the supplied ZIP before making changes.
- Work on the existing Expo React Native application only.
- Do not rebuild the app from scratch.
- Do not remove working features.
- Do not change website or AdSense files.
- Do not request private Supabase or Clerk account access.
- Do not request passwords, production credentials, or secret keys.
- Do not modify the live production database.
- Inspect the existing SQL migrations and schema references before preparing new SQL.
- Do not guess table names, RPC parameters, columns, IDs, or status values.
- Do not delete existing orders, products, users, services, or business data.
- Do not use destructive SQL.
- Prepare complete SQL/RLS migrations for me to review and apply myself.
- Include required database functions, triggers, grants, and notification logic if actually needed.
- Clearly separate verified fixes from features requiring further testing.
- Do not claim that an untested feature works.
REQUIRED DELIVERABLES
Return:
1. A report identifying the actual defects found in the supplied ZIP.
2. Complete corrected source files or a clean patch.
3. The complete Supabase SQL migration, including required RLS policies and database functions.
4. Any required notification server/Edge Function code, if push notifications are included.
5. Any required Android permission or package changes.
6. Any new Ludo sound assets and their licensing information.
7. Exact instructions for replacing or adding each source file.
8. Exact instructions for reviewing and applying the SQL in my own Supabase account.
9. A test report listing the tests performed and actual results.
10. A list of remaining limitations and features not completed.
ACCEPTANCE CRITERIA
The work must demonstrate that:
- COD orders remain saved correctly.
- Buyer and seller order lists show the correct orders.
- Seller acceptance/rejection updates the buyer's order status.
- Appropriate buyer and seller notifications are generated.
- Home-screen/system push notifications are verified separately if implemented.
- Checkout Current Location works and manual address entry remains available.
- The reported My Business deletion issue is corrected.
- Online Ludo automatically searches for players and handles unavailable players clearly.
- Dice, movement, and capture sounds play promptly.
- Winner applause plays at the correct time.
- Existing functionality and historical orders remain intact.
First inspect the complete ZIP and identify the actual defects. Then fix the existing code and return the complete corrected files and SQL/RLS code. Do not request private account access or modify the live database.
Before accepting the project, confirm what can realistically be completed within the US$10–15 maximum budget and identify any additional-cost requirements.
Apply on Freelancer →
Project sourced from Freelancer.com. Applications happen directly on the original platform — we never collect your data.