The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
Receipt Ad — an animated receipt template for anyone who sells or books
A receipt prints line by line, gets stamped and tears off.
A 9-second loop for cafés, salons, hotels, shops and anyone who wants to show "your order is on its way".
Swap the logo, product image, items, prices, colours and button text and it's a new brand in minutes;
The same file ships as a 4:5 ad, a 9:16 story and a transparent, play-once "order confirmed" screen for checkouts.
It was built end to end with the SVGator MCP and Claude Code: one master project, then each new brand is a duplicate plus around 60 small edits, with the animation untouched.
https://www.linkedin.com/feed/update/urn:li:activity:7515869967750254594/
Open the template: https://app.svgator.com/editor#/31bd5f1e20bc436a9a509fe192557055
Both videos (proof + MCP session): https://meriform.dev/svgator/receipt-ad/
The part I'm proudest of is the MCP workflow. To test whether the template really is reusable, I gave a fresh Claude...
Receipt received, and it's a fun one 🤟 Here's hoping it pays off, Fábio!
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
Landing page for an AI-native terminal platform
Check the Live Sitemap Before Signing Off the Release
A sitemap can export correctly while the live website still serves an older URL list. The task needs a check at the public sitemap address after deployment.
That check should compare the published file with the pages the team agreed to include.
Imagine an export containing 200 URLs. The public sitemap also contains 200, but it still lists a retired service page and omits the new replacement. The totals match. The contents do not.
Before closing the task, check:
• The production sitemap address returns the expected XML.
• Its complete URL list matches the agreed inventory.
• Each intended page type is represented, including a newly published page.
• Deliberately excluded pages remain absent.
• Someone owns the process that keeps the file current.
Start with the sitemap already on the site. It may be an index pointing to several smaller files. Include those files in the comparison so a working index does not hide an outdated section underneath it.
Keep the inventory decision explicit: which service pages, locations, articles or products belong in this release? A crawler's export tells you what it discovered. Compare that list with the pages the site was supposed to publish.
Open a sample of the listed URLs as well. Check that they reach the intended production pages and use the preferred addresses. If the sitemap includes modification dates, those dates should reflect significant page updates; exporting the file again does not make every page newly updated.
For a site that publishes regularly, document how new pages enter the sitemap and how retired pages leave it. An automated generator still needs clear inclusion rules and a check when those rules change.
Keep the public address, inventory comparison and update owner in the release notes. Make the sitemap discoverable through Search Console or robots.txt, and check for retrieval or processing errors. Submission does not guarantee that every listed page will be crawled or indexed.
I put together the generation, export and publishing steps in the full guide on Technical SEO Notes:
https://technicalseonotes.org/how-to-generate-and-export-an-xml-sitemap/
Projects and client work: NikoCodes
https://nikocodes.com/
Solid checklist. I'd add lastmod: if every release stamps today's date on every URL, Google learns to ignore it. It should only change when the page content changes. Also worth confirming every sitemap URL returns a direct 200, not a redirect.
I built an AI support-ticket router on Replit, then tested it against the real model. Three things broke that no mock would have caught.
A silent failure. The first run sent 33 of 40 tickets to "needs a person". The newer Claude model rejects the temperature setting, and my code swallowed the error, so every call quietly failed. Now every failed call is logged.
The model thinks before it answers. With a tight token limit, some tickets got no answer at all and some draft replies stopped mid-sentence. Both have room now, and a cut-off draft is never saved.
One incident looked like four bugs. Four Safari checkout failures each got a different issue key, so the "3+ tickets, same problem" alert never fired. Sorting tickets in arrival order and asking for keys that name the problem rather than the customer turned them into one flagged incident.
If you're adding an LLM feature to your product, test it on real inputs early. The failures are rarely where you expect.
Live demo: https://sorta--krishnanbhupath.replit.app
