Why we are building MockSnaps
Every team ships screenshots. Almost nobody has a repeatable way to make them.
Shipping an app means shipping pictures of it. Store listings, changelogs, landing pages, launch posts, sales decks — all of them are screenshots, and almost all of them are made the same way: someone opens a design tool the night before, drops a PNG into a device frame, nudges it until it stops looking wrong, and exports at whatever size the platform asked for.
That works once. It does not survive a second locale, a second device size, or the day the button changes colour.
What actually goes wrong
The failure is never the picture. It is everything around it.
- The frames drift. Two people, two files, two slightly different corner radii.
- The copy is retyped for every size, so a typo fixed in one is fixed in one.
- Nobody can find last release's source file, so the set is rebuilt from zero.
- Review happens in a chat thread, and the feedback outlives the link to it.
None of that is a design problem. It is a pipeline problem, and pipelines are what software is good at.
What MockSnaps is
A project holds your screens, the frames and layouts you put them in, and the copy that sits on top. Change the copy once and every size re-renders. Change the screen and the set follows. Export the whole thing when you are done.
The unit of work is the set, not the image. That is the whole idea.
Reviewers get a link, not a file. Comments land on the artwork rather than beside it, and a viewer who only ever comments never needs an account of their own.
Where we are
Early. The foundation is a Phoenix application with accounts, organisations and workspaces already working, and the editor is being built on top of it. This blog is where the work gets written down as it lands.
If you want to follow along, the contact page is the fastest way to reach us.