Design a multi-screen app UI concept that keeps its own design system straight across screens

PHASE 1 — ESTABLISH THE SCREEN AND THE DESIGN SYSTEM

APP CONCEPT
A budgeting app for freelancers that tracks irregular income against fixed monthly bills

SCREEN TO DESIGN FIRST
the home dashboard, showing this month's income so far against upcoming bills

DESIGN SYSTEM TO ESTABLISH
rounded 20px corners on cards, a single teal accent (#1F8A70) used only for primary actions and the income number, generous whitespace, a clean geometric sans for numbers and a softer sans for labels. State these as fixed rules for every screen this conversation goes on to produce, not a style suggestion for this one image — corner radius, type scale, spacing rhythm, and the specific accent color should read as deliberate, repeatable system choices, not a one-off illustration style that happened to look good once.

DEVICE FRAME
a modern iPhone frame, portrait orientation, shown as a realistic device mockup rather than a flat rectangle

Generate this first screen now as a clean, high-fidelity concept render — real-looking UI chrome (status bar, navigation, buttons) with legible label text rendered directly in the image, not lorem-ipsum blocks standing in for text.

PHASE 2 — ADD SCREENS THAT REUSE THE SAME SYSTEM (same conversation, after Phase 1 is approved)
the bill-list screen and the add-income screen. For each one, explicitly instruct: reuse the exact type scale, corner radius, spacing, and accent color from the approved first screen — reference "the same design system as the screen above" rather than restating the whole design-system description again, so the follow-up generation anchors to what was already approved instead of independently reinterpreting a generic app style for each new screen.

PHASE 3 — CATCH DRIFT BEFORE IT COMPOUNDS
After each new screen comes back, check it against the first screen specifically for: the accent color hasn't shifted hue, the corner radius on cards and buttons matches, the type weight and hierarchy match. If any screen drifts, correct it as an in-context edit ("match the button corner radius to the first screen exactly") rather than accepting the drift and hoping the next screen self-corrects — small inconsistencies compound across a multi-screen set faster than they get noticed one screen at a time.

WHAT NOT TO DO
Do not ask for all screens in one single combined image — a single generation asked to render several different app screens at once reliably shrinks each one down toward illegibility and blends their UI chrome together. Request one screen per generation, in sequence, in this same conversation.

OUTPUT
One high-fidelity concept image per screen, delivered in sequence, each one visibly sharing the same type, color, and shape system as the first.