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 app 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 writes a museum label.
Review the proposed plan and approve it as written.
Use the one or two organizer-configured feedback rounds if the plan misses your intent.
After submitting, open the first email to track your build.
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.