Turn a Family Scheduler Idea Into a Working App With Astra

Browse the Workflow Hub for a project that solves a recognizable problem. Open the post, read why its creator built it, and look at the comments for questions you might want your version to answer.

Shawn’s project brought family caregiving information into one place. We kept that coordination pattern and changed the focus to groceries, appointments, practices, recitals, and dinners. Give the original creator credit when you share your adaptation.

Try the starting example before writing requirements. Our first demo looked promising, but navigating to a future Tuesday exposed a calendar limitation. That gave us a concrete requirement for the next version: a calendar we could fully navigate and use.

Keep an existing demo in its own folder while you build the new version. We used a separate v2 app so we could compare results without overwriting the original.

Switch to Codex mode, select Astra, and enter /plan. Give it the inspiration link and explain the outcome you want.

Here is a reusable version of the request we used:

Write a new PRD—a product requirements document—that remixes this idea for [your audience and use case]: [source link].

Bring [the activities and information you want to organize] into one place. Make it usable on desktop and mobile, with a full calendar people can navigate, add to, and edit.

For this local prototype, use PostgreSQL and username-only member entry in one shared household. Treat username entry as profile selection, not secure authentication. Use fictional data.

Ask me multiple-choice questions about the decisions that affect the result. Write the PRD first. After I review it, we’ll create four visual concepts and choose one before implementation.

A PRD is the written agreement about what you’re building. Review who uses the app, which screens it needs, what its calendar supports, and how data should persist. Answer the questions Astra raises instead of letting those decisions stay implicit.

Pro tip: If Astra goes straight to work without clarifying the important choices, ask it to interview you with multiple-choice questions. We used those questions to choose how member entry and the full planner should work.

We chose local PostgreSQL, which added setup work during the build. If you already know your intended backend, specify it in the brief. We discussed Supabase as an alternative, but the prototype here uses the local database.

After reviewing the PRD, ask Astra for four distinct image mockups. Keep the features consistent across concepts and request a desktop screen beside a mobile screen so you can compare both layouts.

Use the approved PRD to create four distinct visual concepts. Show the desktop calendar and a mobile layout side by side in each image. Keep the functionality consistent so I can compare the visual directions. Wait for me to choose a concept before building the app.

We reviewed Hearth, Daylight, Patchwork, and Sunday, then chose Patchwork. Its large calendar, plum controls, pastel categories, and family-member labels gave the build a clear visual target.

This is the generated design concept, not an interactive app screenshot.

Look at the layout and hierarchy rather than treating every detail in the image as finished behavior. Calendar positions, dates, and buttons still need to work correctly in the implementation.

If you use design skills, choose ones that fit your stack and the job. An unrelated installed skill can pull the project toward the wrong framework or visual style. The useful instruction is to build from the design you selected.

Give Astra the approved concept and ask it to complete a working prototype. Our request also asked it to save progress with Git, set a goal, and use sub-agents for independent work.

Build a working prototype from the approved PRD and Patchwork concept in the new app folder. Preserve the earlier demo. Get it running in your browser so I can use it.

Use Git to track and save progress. Set a goal for completing the prototype, and use sub-agents for independent tasks that can run in parallel. Test the app and fix problems before handing it back.

Once the app opens, test the behavior that matters to you. We added a Piano recital event, saved it, logged out, refreshed, and returned with another username. The event was still there. Switching back to Billy also showed it.

That test confirmed persistence and revealed an important access decision: everyone belonged to the same household. Seeing the same event was expected for that design.

Pro tip: Define whether users share one household or get separate accounts before building. Username-only entry selects a member; it does not verify identity or protect private records. Use fictional data for this prototype.

Try a complete action, such as adding and reopening an event, before spending more time polishing the layout. Then check the task list, groceries, and dinner screens against your own requirements. Ask for a targeted correction if something behaves differently from what you intended.