How to structure variants and variables for an auction app, with bid states and a countdown timer, so the prototype and Dev Mode handoff stay clean?

Hi everyone,

I am designing the screens for a mobile auction app in Figma Design and would like advice on how to structure the file before it grows. I work on the development side at a company that offers an auction app development service, so the design is meant to be handed off to developers through Dev Mode and built as a React Native app.

What the app needs to show

A single lot card and lot page have to look different depending on the state:

• Open (normal)
• Ending soon (last few minutes, countdown in a warning colour)
• You are leading
• You were outbid
• Reserve not met
• Closed (won or lost)

Besides the bidder screens, I also need a sign-in flow with two-factor login and an admin screen with a bid history table, so the file has many repeated patterns.

What I have tried

I built one component for the lot card with a variant property called "State" holding the six values above. It works, but the variant set is getting large, because I also need two sizes (list and grid) and light and dark modes. That is already 24 variants for one card.

My questions

1. Variants or variables? Is it better to keep "State" as a variant property, or use component properties and variables (string and boolean) for things like the price text, the badge and the colour mode? I would like to avoid a huge variant matrix and still keep the handoff readable for developers.
2. Countdown in a prototype. Figma has no real timer, so I am faking the countdown with chained "After delay" interactions and a number variable. It works for a demo but becomes messy. Is there a cleaner pattern for showing "10:00 to 09:59 to 09:58..." in a prototype, or should I only show 3 key moments (normal, ending soon, closed)?
3. Simulating a new bid. To show that a bid changes the price and puts the user in the "outbid" state, I use a button with "Set variable" and conditions. Is it normal to drive state changes from variables like this, or is it better to switch variants directly with Change to?
4. Dev Mode handoff. For states that depend on server logic (for example the "outbid" badge), how do you document the rules for developers: in the component description, with annotations, or in a separate page of the file? I would like the developers to see which values are placeholders and which are real rules.
5. File structure. Would you keep the bidder app, the sign-in flow and the admin screens in separate pages of one file, or in separate files that share a library?

I can share a screenshot of the variant set if it helps.

Thanks in advance!