Complete Working Damai Automated Ticket Booking Tool — Flexible Platform

Project Title: Complete Working Damai Automated Ticket Booking Tool — Flexible Platform PROJECT OVERVIEW I am looking for an experienced developer to build a complete, runnable, personal-use automated ticket booking tool for Damai (大麦), a Chinese ticketing platform. This is a full product development project. I am not looking for a reminder-only tool, a generic automation script, or a feasibility report only. The main goal is to automatically perform the supported ticket booking steps at the scheduled sale time and attempt to create an order for my selected event. I am flexible about the product format and operating environment. The solution may be: - A simple script. - A desktop application. - A browser extension. - A web automation tool. - A mobile application. - Another practical solution recommended by the developer. It may run on Windows, macOS, Android, iOS, or another suitable environment. I do not require multi-platform support. The first version only needs to support one agreed environment. Functionality is more important than appearance. A simple interface is acceptable as long as the tool is reliable, runnable, understandable, and delivered with clear instructions. PROJECT GOAL At the configured ticket sale time, the tool should automatically execute the supported Damai booking workflow and attempt to create an order. The intended result is that the tool reaches the order-created stage whenever tickets are available and the platform permits the requested actions. I will complete any required manual verification and payment. I understand that no developer can guarantee a successful purchase for every event because ticket availability, queues, platform restrictions, account status, network conditions, and other factors are outside the developer’s control. Please clearly distinguish between: - Functionality that can be demonstrated. - Functionality that depends on Damai’s live environment. - Functionality that requires manual user intervention. - Functionality that cannot be implemented because of platform restrictions. FLEXIBLE PLATFORM REQUIREMENT I do not require a specific technology, device, operating system, or product format. Please recommend the most practical implementation based on Damai’s actual purchase flow. The proposal must state: - Which Damai entry point you recommend. - Whether it is the website, desktop browser, Android app, iOS app, mini program, or another option. - Which operating system and device are required. - Why your proposed environment is more practical than the alternatives. - What I need to install or configure. - What limitations apply to the proposed environment. Only one environment is required for the first version. Windows, macOS, or mobile support are all acceptable if the proposed solution can perform the agreed workflow. CORE FUNCTIONAL REQUIREMENTS The tool should support the following workflow where technically and legally permitted: 1. Booking task configuration The user should be able to configure: - Event. - Date and session. - Ticket category or price level. - Quantity. - Eligible attendees already saved in the Damai account. - Scheduled sale time. - Maximum attempt duration or retry limit. - Preferred booking options, where supported. 2. Pre-sale preparation The tool should: - Open or access the relevant Damai event page. - Confirm that the required event information has been configured. - Check that the user has completed the required account setup. - Detect whether the user is logged in. - Warn the user if login or manual preparation is required. - Display the current task status before the sale starts. 3. Scheduled booking attempt At the configured sale time, the tool should: - Start the booking attempt automatically. - Perform supported ticket selection steps. - Perform supported attendee selection steps. - Perform supported form-filling steps. - Attempt to continue through the normal booking workflow. - Attempt to submit the order when tickets are available. - Use bounded retries and reasonable request intervals. - Stop after an order has been created or the configured attempt limit is reached. - Avoid creating duplicate orders. 4. Manual intervention The tool must pause and notify me when manual action is required, including: - CAPTCHA. - SMS verification code. - Login verification. - Identity verification. - Real-name confirmation. - Additional security verification. - Order confirmation requiring user approval. - Payment. I will complete these steps myself. The tool should provide a clear way to resume after I complete a required manual action, where resuming is technically supported. 5. User controls The tool should provide: - Start control. - Pause control. - Resume control where supported. - Immediate stop control. - Clear current status. - Clear error messages. - Basic activity logs. - Protection against duplicate order attempts. - A clear notification when an order is created. - A clear notification when the task fails or stops. The user interface may be simple. A command-line interface is acceptable if it is easy to use and documented. A graphical interface is preferred but not mandatory. SECURITY AND PRIVACY - I will handle account login, verification codes, CAPTCHA, identity verification, and payment myself. - Do not request or store my password or payment details. - Do not include passwords, session tokens, verification codes, or personal information in source code or logs. - Sensitive configuration must be stored securely if storage is necessary. - Provide a manual stop mechanism that can stop the task quickly. - Any test that could create a real order must be approved by me in advance. - The first version should support one user account and one booking task at a time. - Do not use my account for testing without my explicit permission. COMPLIANCE AND SCOPE LIMITATIONS This project must operate through permitted, user-authorized access and normal booking workflows. The project does not include: - CAPTCHA bypass. - Queue bypass. - Circumventing identity verification. - Circumventing payment controls. - Account farming. - Bulk account creation. - Bulk purchasing. - Ticket scalping functions. - Unauthorized access. - Abuse of private APIs. - Circumvention of platform access restrictions. - Any technique intended to evade Damai security or anti-automation controls. If a requested function cannot be implemented within these boundaries, explain the limitation before development begins. Please do not promise guaranteed ticket purchase success. The developer is expected to deliver a working tool that can demonstrate the agreed workflow, not guarantee ticket availability or defeat platform controls. DELIVERABLES The final delivery must include: 1. A complete runnable product for the agreed environment. 2. All source code. 3. Build files and dependency information. 4. Installation instructions. 5. Configuration instructions. 6. A user guide. 7. A working demonstration of the agreed booking workflow. 8. Clear status messages and error handling. 9. Documentation of all manual-intervention points. 10. A list of supported devices, operating systems, browsers, and versions. 11. A list of known limitations. 12. A short post-delivery bug-fix period. 13. A maintenance proposal for future Damai changes. 14. A final handover meeting or recorded walkthrough. ACCEPTANCE CRITERIA The product will be accepted when: - It can be installed and started using the provided instructions. - It runs in the agreed environment. - The user can configure the event, session, ticket category, quantity, attendees, and sale time. - It opens or accesses the agreed Damai booking entry point. - It starts the booking attempt at the configured time. - It performs the agreed supported selection and booking steps. - It pauses correctly when manual verification is required. - It clearly notifies the user when manual action is needed. - It provides a manual stop control. - It does not continue creating duplicate orders after an order is created. - It provides useful status information and error messages. - The developer demonstrates the agreed workflow. - All source code and documentation are delivered. A reminder-only program, a program that only opens the Damai page, or a generic script that does not demonstrate the agreed Damai booking workflow will not meet the acceptance criteria. TESTING AND DEMONSTRATION Before development starts, we will agree on: - The target Damai entry point. - The supported device and operating system. - The exact booking steps to be demonstrated. - The test method. - Whether a test may reach a real order page. - The acceptance criteria. - The delivery date. Testing must avoid unintended purchases. Any test that may create a real order requires my prior approval. Because live ticket inventory and platform conditions vary, acceptance will be based on the agreed demonstrated workflow and documented behavior, not on a guarantee that a specific live event will always be purchased successfully. PROPOSAL REQUIREMENTS Please include the following in your proposal: 1. Relevant automation, booking, reservation, or purchase workflow projects you personally completed. 2. Your specific role in each project. 3. Any experience with Chinese-language websites or ticketing platforms. 4. The Damai entry point you recommend supporting. 5. The device and operating system you recommend. 6. Your proposed technical approach and technology stack. 7. The exact features included in your quote. 8. The features excluded from your quote. 9. Your total fixed-price quote. 10. Your proposed milestone and payment schedule. 11. Your estimated delivery time. 12. The length and terms of the post-delivery bug-fix period. 13. Expected maintenance costs if Damai changes its booking flow. 14. Technical risks and assumptions. 15. A link to relevant work, a demo, or screenshots where available. BUDGET AND PAYMENT The budget is negotiable based on the confirmed scope, proposed environment, technical approach, relevant experience, and deliverables. Please provide a fixed-price quote for the complete runnable product. I prefer milestone-based payments. The final payment will be released after I verify the runnable product, source code, setup instructions, and documentation. Please do not begin custom development until the target environment, feature scope, milestones, and acceptance criteria are agreed in writing.