Smart locks: the latch still plus overlay app UI
Do not generate a homeowner.
Do not generate a homeowner. The lock is a latch you can photograph. The app is a UI you can screen-record. Motion is image-to-video from the latch still. The phone chrome is a picture-in-picture layer. A synthetic person in a hallway is a likeness you do not have, and a testimonial you cannot stand behind.
The ad is "this bolt moves, this phone shows the state." It is not "a happy couple arriving home." Those are different jobs. Only one of them is yours without a release.
The latch is the still
Photograph the hardware in the state the listing allows: deadbolt thrown, deadbolt open, interior thumbturn, exterior face. That PNG is the contract. Image-to-video treats the upload as frame one. Labels, finish, and screw pattern survive because they are already in the pixels.
Seedance 2.5 covers the still-to-motion job: native audio, four to thirty seconds in one pass, 720p ceiling on the image-to-video endpoint, first frame required, optional last frame when the shot has a destination. Add a second photo to set the close — thrown to open — when both stills are yours.
Prompt only the motion: bolt sliding, a slow push, light on the faceplate. Do not re-describe a "modern smart lock in a luxury foyer." That paragraph restages the hardware. Text-to-video of a lock is a cousin SKU. If the still were printed on the box and you would not ship the box, do not buy motion.
App UI is a layer
Do not ask the video model to draw the companion app on a generated phone. On-screen UI is the same typesetting failure as a nutrition panel: small type, specific glyphs, a state that has to match the hardware in the same second. Screen-record the real app in the state the lock is actually in. That file is the overlay.
Picture-in-picture is create_ugc_video_overlay: latch take as the base, phone recording as the overlay, position required in a defined corner. It is a composite, not a generate. A black backdrop on the overlay can be stripped; a different-colored phone background needs cleanup first.
Keep the overlay honest. If the latch is open in the base, the app must not show locked. That mismatch is a product-truth failure, not a style. Time the two files so the state change lands together. Do not generate a UI that implies a feature the listing does not have.
Do not cast a person you did not shoot
A generated homeowner is the expensive mistake: a face with no release, a "customer" who never existed. A random synthetic adult walking through a door is still a person you invented to sell a lock.
What you may generate around the latch: empty corridor, night porch light, a hand you photographed on the thumbturn if that still is locked. What you may not: a couple, a child at the door, a neighbour waving, a "user" holding a phone the model invented.
If the brief needs a person, shoot one, or skip the person. Overlay the app. Move the bolt. Ship the hardware.
FAQ
Can I generate a hand on the lock if I do not have a photo?
A hand is a likeness-shaped object. If the campaign needs a hand, photograph it on the real hardware. Do not let I2V invent a body to complete the shot.
Why overlay the app instead of prompting it into the generate?
Because the app is type and state. The model will restyle the screen and drift the lock icon. Screen-record the real UI. Composite it. Position is a corner, not a free pixel.
Do I need a last frame for the bolt?
Only when both ends are approved stills — closed and open, same hardware, same angle. A single hero faceplate with a slow push is a first-frame job. A last frame is control when the destination matters.
Is a talking generated homeowner a better demo?
No. It is a presenter you do not have, on a product that did not need one. The latch and the app are the demo. Keep the mouth off the ad unless it is a real, consented person.