Product Introduction
Animated Digital Cards and Love Letters
Create personalized digital cards, love letters, and online gifts that feel alive.
Project Overview
Emocia.net is a platform for creating personalized digital cards for birthdays, anniversaries, long-distance relationships, love letters, and other special occasions.
Each Emocia card is built from animated pages containing personal messages or photos with captions. Text appears letter by letter, while music, custom designs, and visual effects transform the card into a cinematic digital experience.
Once complete, a card can be:
- Shared through a private link
- Delivered as an email surprise directly from Emocia
- Exported as a vertical 9:16 MP4 video
Emocia supports both free and Premium cards.
You can view a live demo card here: Open the Emocia demo card.
The Idea Behind Emocia
The idea behind Emocia is to help people create digital cards that feel more emotional, personal, and memorable than traditional greeting cards.
Instead of showing a static message, an Emocia card unfolds like a short cinematic story created from the user’s own words and photos.
The combination of animated text, personal memories, music, designs, and visual effects makes every card feel like a small digital gift rather than a simple greeting.
Early Launch and Initial Traction
I built and launched the first version of Emocia within a few weeks at the end of 2025.
Compared with the platform today, the initial release was extremely minimal. It included only the core experience required to create and share a simple animated digital card, without many of the features, administration tools, and technical systems that were added later.
Despite its simplicity, more than 1,000 cards were created during the Christmas and New Year holiday period.
That early response showed me that people were genuinely interested in the idea and were willing to use Emocia to create personal messages for the people they cared about. After the holiday period, I decided to take the project more seriously and began developing it into a complete product.
Growth, Sales, and User Feedback
As of June 23, 2026, more than 15,000 cards had been created through Emocia, with over 2,000 sales.
Across those sales, Emocia had received only one refund. There was also only one purchased card that was never completed by the customer.
I recently introduced a feedback form, and the response has been overwhelmingly positive. One of the most rewarding parts of building the project is seeing how much happiness these cards bring to people and how they help users express emotions that can sometimes be difficult to communicate through a normal message.
SEO and Organic Growth
SEO has been one of the most time-consuming and difficult parts of building Emocia.
It is especially important for the project because virtually all of its traffic comes from organic search. Paid advertising is difficult to justify for a product that costs only a few dollars, as the required conversion rate would need to be unusually high for the campaigns to remain profitable.
This has made organic discovery a core part of the product strategy rather than simply an additional marketing channel. It has required ongoing work around content structure, search intent, technical SEO, internal linking, indexing, and the relationship between different landing pages.
SEO is a broad topic and has played a significant role in the development of Emocia, so I plan to cover it in more detail in a separate article.
Technical Architecture
The Emocia platform is divided into two main projects.
The first project contains the main website, card editor, card player, administration tools, authentication, payments, and marketing content.
The second project is responsible for rendering completed cards as vertical videos.
Project 1: The Emocia Web Application
The main Emocia application is a full-stack Next.js application built on top of MongoDB.
It includes several modules:
- Marketing website
- Card editor
- Card player
- Custom administration panel
- Payload CMS
- Shared core module
The shared core module contains logic, types, utilities, and other code used across the different parts of the application.
User Interface and Animations
The interface is built with Tailwind CSS.
Instead of relying on a pre-built component library, I created the main interface components specifically for Emocia. This gives the product a more distinctive visual identity and allows the editor and player to behave exactly as required.
GSAP is used for many of the animations throughout the experience, including transitions, animated card elements, and parts of the card player.
The Card Editor and Player
The editor allows users to create cards from different types of pages.
A page can contain:
- An animated text message
- A photo with a caption
Users can also choose a background design, melody, and visual effects such as:
- Falling hearts
- Rising hearts
- Rain
- Snow
The player is responsible for presenting these elements as one continuous cinematic experience.
Text messages appear letter by letter, pages transition automatically, and the selected music, design, and effects are synchronized with the presentation.
Users can pause and resume the card at any time, while the progress bar allows them to move backward or forward through the experience.
Payload CMS and Marketing Content
The marketing website is managed through Payload CMS, which uses the same MongoDB database as the main application.
Payload CMS was not part of the original version of Emocia. Initially, the marketing content was written directly inside the application code.
That approach became difficult to maintain. Even small content changes required editing application files, navigating through unrelated code, rebuilding the project, and deploying a new version.
Adding Payload CMS made it much easier to manage pages, sections, blog content, and other marketing information without changing the main application code.
Transactional Data and the Custom Admin
The cards themselves are transactional application data and are not managed through Payload CMS.
Other important application data includes:
- Card backgrounds
- Melodies
- Visual effects
- Card configurations
This data is managed through a separate custom administration panel built specifically for Emocia.
After introducing Payload CMS, I considered moving the transactional data into it as well. I spent some time experimenting with this approach, but the card system required a large amount of custom business logic, specialized interfaces, and application-specific behavior.
Integrating all of that into Payload CMS introduced more complexity than it removed. I therefore decided to keep Payload CMS focused on editorial content and build a dedicated admin interface for the transactional parts of the platform.
This separation allows each administration system to focus on what it does best:
- Payload CMS manages marketing and editorial content.
- The custom admin manages cards, designs, melodies, effects, and other application data.
Authentication
Authentication was added more recently.
The main reason was to allow users to return to their cards easily, even after a long period of time. A card can represent an important memory, so users should not have to rely only on keeping the original private link.
For authentication, I use Better Auth.
I had previously worked with NextAuth, but Better Auth felt like a cleaner and more suitable solution for the current architecture and requirements of Emocia.
Rendering Strategy
The original marketing website was primarily statically generated.
While static generation provided fast responses, it introduced additional complexity whenever content changed. Updates required Next.js revalidation as well as cache invalidation in Cloudflare. This occasionally resulted in small caching problems and made the content workflow harder to reason about.
When authentication was introduced, I decided to move the website to server-side rendering.
The HTML is now generated on each request. This allows the authentication state to be resolved before the page reaches the browser and avoids a visible flash while the client waits for the user session to load.
For Emocia, SSR also simplified content updates and removed much of the complexity around revalidation and stale Cloudflare caches.
Static generation can still be a good choice for many projects, but for an authenticated application with frequently changing content, server-side rendering was the better trade-off.
Payments
Payments are handled through Lemon Squeezy.
The service is relatively expensive for a low-priced product such as Emocia, where a purchase may only be worth a few dollars. However, the overall experience it provides is excellent.
Its checkout is completed on a single page, which is particularly useful for an emotional and impulse-driven purchase. The technical integration is straightforward, and the payment experience feels polished and trustworthy.
For these reasons, Lemon Squeezy has remained a good fit for the project despite its fees.
Hosting and Deployment
The main application is hosted on my own VPS.
I use Coolify to manage:
- Application containers
- MongoDB
- Redis
- Deployments
- Environment variables
- Networking
- Other supporting services
The deployment process is automated through GitHub Actions and Coolify.
When code is pushed to the main branch:
- GitHub Actions builds the application image.
- GitHub notifies Coolify that a new version is available.
- Coolify pulls the image.
- A new application container is deployed.
This gives me a controlled and repeatable production deployment process while still allowing me to manage the infrastructure on my own server.
Cloudflare and Security
Cloudflare sits in front of the application and is used for security, proxying, caching, and traffic management.
I use Cloudflare Turnstile to protect public forms and authentication flows from automated abuse. Bot Fight Mode helps detect and block suspicious bot traffic before it reaches the application.
The administration interfaces are protected through Cloudflare Zero Trust Access. This prevents unauthorized visitors from reaching sensitive parts of the platform and adds an additional security layer between the public internet and the admin applications.
Project 2: Video Rendering Service
The second project is responsible for rendering Emocia cards as videos.
It uses:
- FFmpeg
- A headless browser
- BullMQ
- Redis
- S3-compatible object storage
The service runs as a BullMQ worker.
When a video export is requested, a job is added to the queue. The worker processes the card, combines the browser-rendered experience with FFmpeg, creates the final video, and stores it in S3-compatible storage.
The result is an MP4 video in a vertical 9:16 format.
Why Vertical Video?
The vertical format allows people to keep the card as a personal memory on their phone.
It can also be shared through platforms such as:
- Instagram Reels
- TikTok
- YouTube Shorts
Video export is a Premium feature and is intended to remain part of the Premium experience.
The exported videos are also useful for Emocia’s own marketing. They allow me to demonstrate real card experiences on social media, especially on TikTok, without having to recreate the presentation manually.
Future Potential
The video-rendering system is one of the most technically interesting parts of Emocia.
I am considering developing it into a separate product or rendering service in the future. The current system is designed specifically for Emocia, so turning it into a standalone platform would require additional work around configuration, scalability, APIs, user management, and infrastructure.
However, the core rendering pipeline already provides a strong foundation for that direction.