-
-
Sound is the product. Every choice contributes to a local audio mix and a visual scene that can be played back immediately.
-
Build Week made the web package judgeable. The AIT bundle now includes web audio assets and the export path needed by Toss WebView.
-
The project remained local-first. No account, server render, upload, or external generation is needed to create a summer memory.
-
Codex helped drive the boring hard parts: reproducing platform failures, patching the smallest boundary, and rerunning gates.
-
Results are made to leave the app. The result screen exports image, audio, and video assets for sharing or saving.
-
iPhone AIT behavior was fixed at the contract boundary. Binary outputs use the host file-export bridge, so the visible action is now Export.
-
Pick a summer, not a file. The app starts with recognizable summer moments and turns the selection into one coherent scene.
Project story
Inspiration
Summer Sound Maker is built around a simple idea: a season is easier to remember when it has a sound. Instead of asking people to edit timelines or manage audio files, the app lets them choose recognizable summer moments and turns those choices into a small playable scene.
What it does
The app lets a user select summer sounds such as waves, cicadas, rain, watermelon, footsteps, festival noise, and fireworks. It generates a visual result, a title, a local audio mix, and exportable media. The result can leave the app as an image, an audio clip, or a short video.
What changed during Build Week
The Build Week work focused on making the prototype survive real product edges: sound quality, layout stability, accessibility, Apps in Toss packaging, web audio in a bundled WebView, and reliable media export. The iPhone AIT issue was the clearest example. The first implementation treated save and share as separate web intents, but the host only provides a binary file-export flow. The fix moved the app to that contract and changed the visible wording to Export.
How Codex helped
Codex worked as a coding partner rather than a content generator. It read the repo rules, inspected the existing Flutter and web bridge code, compared the AIT host API contract, implemented the media export patch, updated the packaging script, and generated the submission packet. The human direction stayed at the product level: keep the app local-first, make the result shareable, and make the iPhone behavior honest instead of pretending that a native photo-save API exists.
What is technically interesting
The app spans Flutter UI, JavaScript canvas rendering, Web Audio mixing, native Android share/save paths, and Apps in Toss WebView packaging. For iPhone AIT, video generation now uses a deterministic FFmpeg/WASM fallback instead of depending on WebView MediaRecorder support. That keeps the app inside a static local bundle while still creating a real MP4 asset.
What's next
The next step is device verification on the final iPhone AIT package and a clearer export progress UI for slower phones. Longer term, the app can add saved local presets and bridge-compatible handoff into other OnnelLab apps without changing the core local-first boundary.
Log in or sign up for Devpost to join the conversation.