Design and BuildYour Own App

Separate a personal-use tool from a business product and define one concrete user need.

Draw a boundary around what the first version must and must not do.

Plan navigation plus empty, loading, error and success states before polishing screens.

Translate the idea into observable tests instead of adjectives.

Combine context, task, constraints, references and verification.

Use clarification and a short implementation plan before a multi-step change.

Control scope, dependencies and approved design decisions.

Use screenshots, reproduction steps and observed versus expected behavior.

Extract hierarchy, spacing, color relationships and motion principles from legitimate references.

Choose the main action, reading order, grouping and breathing room.

Create a small token set with usable contrast, a type scale and consistent spacing.

Produce a concise DESIGN.md that includes examples, limits and checks.

Define buttons, cards, fields and navigation once, then reuse them.

Treat disabled, focused, pressed, empty and error states as part of the design.

Check zoom, long text, keyboard navigation, focus order, contrast and reduced motion.

Compare real alternatives and explain what is stronger and why.

Use included original assets or optional generation and optimize the result.

Use restrained transitions and optional ambient backgrounds without making motion essential.

Expose a few meaningful surface parameters instead of making repeated blind changes.

Export tokens, apply them to real components, and remove development controls from production.

Define records, identifiers and valid inputs before adding more screens.

Test new days, time-zone changes, edits, interruptions and reopen behavior.

Provide a recoverable local-data path and validate imported files.

Use a small automated test or guard and verify it can catch a known failure.

Separate project purpose, design rules, current state and the next-chat handoff.

Date important choices, keep current rules clear and mark reversals as superseded.

Write a concise handoff with changed files, verified checks, blockers and next step.

Use one builder by default, small diffs, checkpoints and bounded investigation.

Separate the files on your computer, local Git history, a GitHub remote, and a deployed Vercel app.

Create a private remote repository, push the intended checkpoint, and verify the remote contents.

Transfer the method to a local-first checklist, planner or simple business utility.

Observe a first-time user without silently doing the difficult steps for them.

Ship a version, check the actual deployment, explain data limits and document the update path.

Present the user need, visual system, working behavior and known limitations.