Full-Stack Developer Needed to Build Minimalist Sports Logging Web App Prototype (MVP)

Couch Coach — M1 Stabilisation & Approved UI Implementation PROJECT OVERVIEW I am looking for an experienced developer to stabilise and refine an existing web-based football tactical insights application called Couch Coach. The original Bolt.new build is available in my own GitHub account and is intended to be the starting point for this engagement. The approved HERO design and detailed visual references will be made available to the selected developer once the engagement and appropriate confidentiality arrangements have been agreed. Applicants should assess the existing code and propose the most practical, cost-effective approach, avoiding an unnecessary rebuild. I am seeking a reliable, maintainable implementation of the agreed functionality and interface, with clear communication, realistic timescales and demonstrable testing. Please review the requirements below and provide your proposed technical approach, fixed-price estimate and delivery timescale. ## 1. USER INTERFACE AND DESIGN The application must retain a clean, minimalist presentation centred on a prominent, attractive, sunlit football stadium. The intended interface includes: - A stadium that remains clearly visible and is not obscured by excessive interface elements. - A discreet, single horizontal row of match controls. - A small white **PRE-MATCH PREVIEW & PREDICTION** box. - A larger white **LIVE TACTICAL INSIGHTS** notebook beneath it. - Black text on white backgrounds within both boxes. - Permanent titles integrated into the top of each box. - Voice and typed input for both boxes, with each input routed to the correct destination. - Live tactical observations displayed chronologically, oldest first and newest at the bottom, with clear match-minute timestamps. The interface must be practical and ergonomic, with no unnecessary dashboard cards, duplicate input boxes, decorative panels or redundant controls. Detailed visual references will be shared with the shortlisted or selected developer after appropriate contractual and confidentiality arrangements have been agreed. ## 2. MICROPHONE AND CONTINUOUS SPEECH-TO-TEXT — CRITICAL REQUIREMENT Reliable continuous speech-to-text is a core requirement of Couch Coach. The developer must inspect the original Bolt build and assess its existing speech-recognition implementation before proposing any replacement. Requirements: - Continuous voice input suitable for natural speech, spontaneous thoughts and extended streams of football observations. - Users must not need to reactivate the microphone for every sentence or short phrase. - Recognised text must appear promptly in the correct box. - Previously captured text must not silently disappear when recognition stops, encounters an error or reconnects. - Recognition must handle natural pauses and recover gracefully from browser recognition interruptions and transient errors wherever possible. - Microphone permission must be requested when necessary, with clear instructions if permission is blocked or denied. - Clear microphone controls and an understandable listening status. - Clear error messages and a Retry mechanism where appropriate. - Voice input must work independently in both the pre-match box and the live tactical notebook. The developer must identify the proposed speech-recognition API or library and explain the technical approach before replacing the existing mechanism. If the original build uses the browser's Web Speech API, including SpeechRecognition or webkitSpeechRecognition, its suitability for retention and improvement should be assessed before introducing another service. The developer should assess practical ways to improve recognition of football terminology, player names and team names, including the possible use of pre-match notes as contextual vocabulary. Perfect recognition is not assumed, but realistic football vocabulary must be tested. Live observations must be timestamped according to when the observation began, rather than simply when a delayed transcription is committed. ## 3. MATCH CONTROLS AND KICKOFF SYNCHRONISATION The controls must appear in one compact horizontal row without obstructing the stadium or notebook. Required controls: - First Half — START / STOP. - Second Half — START / STOP. - PAUSE / RESUME. Kickoff synchronisation is essential. The match clock must reflect actual elapsed match time relative to the agreed kickoff reference, rather than simply starting from zero when the user clicks START. The implementation must preserve elapsed time through pause and resume and support the transition between the first and second halves. If starting or synchronising fails, the user must receive a clear error message and a Retry option. The developer must explain how kickoff synchronisation is implemented and how its accuracy will be tested. ## 4. NEW MATCH, DATA RETENTION AND RECOVERY Starting a New Match must produce a completely clean match interface. All match-specific information from the previous match must be cleared from the active interface, including pre-match notes, predictions, live observations and timestamps. No previous-match content may remain visible or contaminate the new match. The application must also handle refreshes and temporary Wi-Fi interruptions without losing previously captured observations or their timestamps. Where speech recognition is interrupted, the application should recover gracefully while preserving all text and observations already captured. The developer must explain how notes and timestamps are stored and recovered reliably. ## 5. M1 ACCEPTANCE TESTS All six acceptance tests must be demonstrated before M1 is accepted. **Test 1 — Start Match / Sync Kickoff** The clock starts and synchronises correctly on the first attempt, reflects the appropriate elapsed match time, and provides a clear error and Retry option if synchronisation fails. **Test 2 — New Match** A new match starts cleanly, with no pre-match notes, predictions, observations or timestamps carried over from the previous match. **Test 3 — Voice and Typed Observations** Both input methods work reliably. Live observations are routed correctly, timestamped appropriately and displayed in chronological order. **Test 4 — Microphone Permissions** Using a clean Chrome profile with no previously granted microphone permission, verify the permission request and the instructions provided if access is blocked. **Test 5 — Refresh and Wi-Fi Interruption** Previously captured notes and timestamps survive a page refresh and temporary connectivity interruption. Speech recognition recovers as far as the browser and implementation permit, without discarding captured observations. **Test 6 — Visual Acceptance** The prominent stadium, minimalist layout, compact control row and two clearly differentiated white notebook boxes are implemented as agreed, without unnecessary cards or controls. Testing must include realistic extended speech input, natural pauses, football terminology and player names, as well as error and recovery scenarios. ## 6. TECHNICAL APPROACH AND HANDOVER Before implementation, the developer must assess the original Bolt.new build in my GitHub account and explain: - Which existing components can be retained or improved. - The proposed speech-recognition API or library and its limitations. - How continuous recognition, interruptions and recovery will be handled. - How notes and timestamps will be stored and recovered. - How kickoff synchronisation will work. - How the application will be tested and deployed. Deliverables must include: - A working, tested and responsive application. - Clean, maintainable source code in a repository under my control. - Deployment and setup instructions. - A clear explanation of the implemented functionality and any remaining limitations. The developer must not assume that code from a previous development engagement is available or required. ## 7. SCOPE, COST AND DELIVERY This engagement covers **M1 stabilisation, implementation of the agreed interface and functionality, testing, and handover**. Wider M2 development is excluded and will be considered separately after M1 has been completed and accepted. M2 features include fixture selection for European football competitions, user accounts, Fan League functionality, leaderboards, expanded prediction features and multi-sport support. Before work begins, please provide: 1. Your proposed technical approach. 2. A fixed-price estimate and realistic delivery timescale. 3. A list of deliverables and confirmation of how each acceptance test will be demonstrated. 4. Any significant technical risks or limitations identified in the original code. 5. Confirmation that the work will build on the existing GitHub code wherever practical, avoiding an unnecessary rebuild. I am looking for a developer who can assess the existing assets objectively, communicate clearly, implement the requirements reliably and deliver maintainable work without unnecessary complexity or scope expansion. Please address the specific requirements above in your response and explain your proposed approach.