Who will use it?
Attendees, neighbors, travelers, volunteers, a team, or another clear audience.
Name the person, the main action, and the useful result. The kiosk requires at least 180 characters—about three sentences. The builder will choose the data model, LLM, interface, and deployment approach.
Attendees, neighbors, travelers, volunteers, a team, or another clear audience.
Add and browse, search and save, compare and summarize, track changes, or another primary action.
Ideas, events, tasks, places, notes, results, or other records the experience needs.
Say what the user should find, understand, decide, create, or notice after using the app.
The builder has to guess who contributes, what belongs in the museum, and what visitors should discover.
Build a Pocket Museum where attendees upload a photo of an everyday object, add its story and where they found it, and browse the collection by theme. Let them ask the built-in AI vision capability to examine a photo and write a museum label grounded in the image and saved story.
People contribute an image and story, MongoDB Atlas stores the object record, visitors explore the collection, and multimodal AI creates a useful label.
Review the proposed plan and approve it as written.
Use up to two feedback rounds if the plan misses your intent.
After submitting, open the first email to track your build; your claim code is a backup.
Open the second email when the app is ready, then use one optional post-build feedback round if data or behavior needs a fix.
A focused idea leaves time to build, test, repair, and deploy every visible feature.
Use real public information and normal app records. Leave out credentials, private company information, payment cards, government IDs, medical records, and biometrics.
Ask for the smallest complete version of the idea rather than a large product full of unfinished features.