Short answer
RaftLabs built DropMock for Lead Seven: a credit-based image and video ad-mockup platform. V1 shipped in about 3 months with image mockups only; video mockups, then moving-mockup video ads, then direct ad-format video generation for platforms like Meta and Google followed in later 6-8 week releases on an 8-10 week cadence. Marketers searched a mockup library by use case, uploaded their own image or video with a guided crop step, chose a licensed or uploaded audio track for video mockups, and rendered a free low-resolution preview before spending credits on a watermark-free HD export. The delivery team recalls roughly 1,500 active customers and about 200 image and video mockups rendered per day in the first 3-4 months after launch; these figures come from team recollection of a circa-2017 engagement, not a retained analytics export.
Engagement
The DropMock engagement
- Client
- Lead Seven
- Product
- DropMock, an image and video ad-mockup platform
- Sector
- MarTech / creative tooling
- Initial timeline
- 3 months for V1 (image mockups only)
- Delivery cadence
- 6-8 week builds on an 8-10 week release cycle for V2-V4
- Team
- Frontend developer, backend developer, PM, QA
- Platform
- Credit-based web app
- Market
- Marketers and ad buyers, global
- Service
- SaaS development and UX/UI design
The situation
Marketers who needed ad mockups were already paying for PlaceIt. The problem wasn't that PlaceIt didn't work. It was what it didn't have: at the time, most of its mockups showed a bare product or an empty screen, with no model in the scene, and it had no video mockups at all. An ad that needs to feel real, a phone being held, a billboard on a real street, loses that realism without a model in frame.
Lead Seven brought us DropMock to close that gap: a cheaper mockup library with more scenes that included models, plus a format PlaceIt didn't offer yet: video mockups, where a marketer's own clip plays inside a phone screen, a billboard, or a storefront window instead of a static image.
The brief was simple to state and hard to ship. A marketer uploading a photo or a clip has no idea what aspect ratio the template actually needs. Get that wrong and the mockup's perspective warps, or the video that's supposed to sit flush inside a phone screen or billboard spills outside it. And video, unlike a static image, has to render somewhere, which meant solving for render latency, not just render quality.

What makes an upload-and-render mockup tool hard
Users upload the wrong shape, and the mockup breaks
Most marketers don't own image or video editing software, so they can't crop or resize an asset to fit a template before uploading it. Drop the wrong aspect ratio into a perspective-warped mockup, like a phone screen tilted in 3D, and the image or video stretches, skews, or gets cut off in a way that looks broken rather than polished.
The fix had to happen before the render, not after. DropMock's upload step reads the template's required format, and when an upload doesn't match it, gives the user a guided crop-and-resize step that highlights the focal area of their asset so they can commit to the right frame without owning a separate editing tool.
Cloud rendering is fast for one image and slow for one video
Rendering a mockup server-side is routine for a still image. Video is a different cost: every mockup render means encoding a clip into a scene, and the straightforward version of that pipeline was too slow to review and approve in one sitting.
DropMock split the render into two passes instead of one. A fast, low-resolution preview renders first so the marketer can check the fit and the audio before committing to anything, and only the final approval triggers the full-resolution, watermark-free render, which is the one that actually costs the heavier compute.
The call
V1 shipped image mockups only. Video waited for proof the product worked.
Video mockups were the headline differentiator against PlaceIt, and it would have been easy to lead with them. We didn't. V1 scoped to image mockups: the upload, the guided crop, and the render loop, with no video rendering pipeline at all.
That pipeline was the expensive, failure-prone part of the brief, the exact latency problem described above. Building it before the core image loop had proven itself with real customers would have meant solving the harder engineering problem before knowing the simpler product was wanted. Image mockups shipped first, in about 3 months. Video mockups, and the two further video capabilities that followed it, were built in the 6-8 week release cycles after that, once the core loop had customers using it.
A comparable SaaS development engagement should scope its hardest technical bet as a later release, not the first one, unless the simpler version of the product has no standalone value.
System flow
From a library search to a credit-gated HD export
Every mockup, image or video, moves through the same four stages.
Discover
Searchable mockup library
Marketers search by use case (for example, real estate, retail, apparel) and hover to preview a mockup before picking it, video mockups play on hover, images show instantly.
Prepare
Guided crop and resize
The upload step checks the asset against the template's required format and lets the user adjust the focal crop before committing, so nothing warps in the final composite.
Soundtrack
Licensed or uploaded audio
For video mockups, the marketer picks a licensed music bed (cinematic, instrumental, indie, and similar categories) or uploads their own voiceover or background track.
Render
Preview free, finish on credits
A low-resolution preview renders first at no extra cost. Approving it triggers the full-resolution, watermark-free export, which draws more heavily on the credit balance than the preview did.
What shipped
The operating loop, made visible
One session, from search to a downloadable export
A marketer never leaves the browser between finding a mockup and downloading the finished file. They search the library, drop in their own image or video, adjust the crop if the upload didn't match the template, pick an audio track for video mockups, and render a free low-resolution preview before deciding whether to spend credits on the final HD export. Nothing in that loop requires a separate editing tool.
Credits priced to the render, not a flat seat
Every render drew from a credit balance rather than a flat per-seat subscription: a standard-definition render cost a set number of credits, and a high-definition, watermark-free export cost roughly double that. The pricing matched the part of the product that actually cost money, cloud render time, rather than charging the same amount whether a customer rendered five mockups or five hundred.
That same credit model is what let DropMock add capability without a pricing rework. Video mockups shipped first with a static mockup object and a playing video inside it. The next release made the mockup object itself move, a van driving past with the ad rotating on its side, for example. The release after that let marketers generate video ads built directly for platforms like Meta and Google, rather than exporting a mockup and reformatting it elsewhere. Each addition consumed credits the same way the one before it did.
Proof
What the delivery team recalls from the first few months
Recalled by the RaftLabs delivery team from a circa-2017 engagement. No contemporaneous analytics export was retained, so these are approximate, not audited figures.
| Result | What changed | Period or context | Evidence and limitation |
|---|---|---|---|
| Active customers | Roughly 1,500 marketers using DropMock | First 3-4 months after launch (approximate) | Team-recalled, not from a retained dashboard export |
| Daily mockup renders | Roughly 200 image and video mockups rendered per day | First 3-4 months after launch (approximate) | Team-recalled, not from a retained dashboard export |
| Time to first release | About 3 months to ship V1 (image mockups only) | Initial fixed-scope build | Project-recorded |
What changed
What changed for marketers choosing between PlaceIt and DropMock
- Marketers paid PlaceIt's pricing for a mockup library with no video mockups at the time
- Most available mockups showed a bare product or an empty screen, with no model in the scene
- Rendering was a flat part of a subscription, with no link between what something cost to render and what the customer was charged for it
- DropMock offered a cheaper mockup library covering the same use cases, including scenes with models
- Video mockups became available alongside image mockups, starting with a playing video inside a static mockup and expanding to moving mockups and native ad-format video generation
- A credit system tied cost to render type, a standard-definition render cost a set number of credits and a high-definition export cost roughly double, instead of a flat subscription ceiling
Where this applies
A fit for usage-priced creative tools, not for a first release that needs every format on day one
This story fits a team building a browser-based image or video creation tool where cloud render cost and latency are a real constraint, and where usage-based (credit) pricing matches the product better than a flat subscription. It's the wrong reference for a team that needs every output format, image, static-mockup video, moving-mockup video, and native ad-platform video, in the first release. DropMock earned that scope over four releases, not one.
Common questions
DropMock's V1, image mockups with the guided crop and render loop described here, took about 3 months. Each further capability (video mockups, moving mockups, then native ad-format video generation) shipped as its own 6-8 week build inside an 8-10 week release cycle. The right timeline for a comparable build depends on how many of those stages you need before your first customer.
Video rendering was the harder, more expensive problem: the latency challenge described above only exists because video has to be encoded into a scene server-side. Shipping the image loop first let the team validate that marketers wanted the product before committing to that heavier infrastructure.
Each render draws down a credit balance instead of a flat subscription. A standard-definition render cost a set number of credits, and a high-definition, watermark-free export cost roughly double that, because the heavier render is the one that actually costs more compute. It ties what a customer pays to what they actually render, rather than charging every customer the same amount regardless of usage.
Related work

