E-Cards Platform — Template Engine + Batch Personalization
A LogicBison showcase project: a browser-based card designer that ports InDesign batch behaviors, maps messy contact files, and exports personalized cards in batches
This is a LogicBison showcase — not a customer deployment. It demonstrates a class of problem every ops team recognizes: corporate cards designed in Adobe InDesign, driven by a JSX script that named every text frame, auto-fit type, and applied per-word brand coloring. The workflow worked — until batch scale and messy HR exports made desktop tooling the bottleneck.
The public instances are a browser-based Fabric.js designer you can exercise end to end: sign in with the shared Tools Dashboard account (the app prompts you), import a contact file, map the columns the parser does not recognize, apply a template, and export one personalized card per record. From there everything stays in your browser — the demo banner is literal: data stays in this browser (localStorage / IndexedDB), nothing is saved on the server, and the demo server rejects writes. The free demo caps how many records one batch can carry, which is why the figures below come from a controlled run rather than from a click-through.
The repository also includes a full server-side architecture (Python batch parser, queue render worker, hybrid storage, OAuth via the Tools Dashboard identity provider) — built as portfolio engineering depth, not deployed as a multi-tenant production service for any client.
The Problem
The problem class: manual card design in InDesign doesn't scale for batch personalization. Contact lists arrive messy — alias column names, headers in Spanish or French, phone numbers split into number and extension, names that need a human eye before they go on a badge. Existing tools fail at behavioral parity with a designer's InDesign habits (named objects, per-word coloring, auto-fit rules, icon clamp positioning).
This project shows the modernization order: port the behaviors first, build the batch engine second, leave the pretty designer for third.
The Approach
Designer layer (what you can try today): a Next.js canvas editor on Fabric.js that reproduces InDesign-style behaviors — named elements, multi-color text, auto-fit that shrinks text on genuine width overflow and never scales it up, dynamic icon clamp positioning, and line compaction. A reusable template forks into a new design on save; the gallery separates templates from designs, and global templates are shared across users either through the API (role-gated) or as bundled files shipped with the app. A template exports as a ZIP carrying its preview image and a sidecar descriptor, so it can be handed to another workspace intact.
Batch layer: import from .csv, .txt, .md, .vcf, .xls, and .xlsx (including transposed spreadsheets with headers down column A), or paste rows straight from the clipboard, or start from a blank import template. Field mapping resolves headers through per-language alias tables (English, Spanish, French) plus fuzzy matching; anything still unresolved goes through an interactive mapping dialog, and any mapping can be saved as a reusable preset. vCard 2.1 to 4.0 files import as one record per card, unknown fields are preserved rather than dropped, and phone numbers are normalized with extension detection. Export writes one individualized PNG or JPG per record into a single ZIP.
Repository layer (portfolio depth, not customer production): the browser mode is backed by the same parsing and rendering rules as the server path — a Python parsing service (file parsing, field normalization, name parsing, phone normalization) spawned from a Node queue worker, results split across PostgreSQL for searchable batch fields and Cassandra for the full contact record, object storage for files and exports, and OAuth 2.0 with PKCE against the sibling Tools Dashboard — the app does not own its own auth, by design.
The Outcome
A linkable portfolio proof: two public instances (demo and production of this personal project) where visitors can exercise the designer. Controlled test on the live designer: about 2 seconds to parse 1,000 contacts; under one minute to export 1,000 individualized PNG cards.
What this is not: a production deployment for a paying client, a live multi-tenant SaaS, or evidence of user adoption or revenue.
Try the demo in your browser
LogicBison portfolio project — not deployed for any customer. Access goes through the shared Tools Dashboard account (you are prompted to sign in), and from there the designer runs in your browser: every template, batch, and export stays in your browser (localStorage / IndexedDB), nothing is saved on the demo server, and the server rejects writes. The free demo caps how many records a batch can carry; the production instance at ecards.aiepic.app runs the same designer. The server-side pipeline described in the repo is engineering depth, not what these public instances expose.
Try the demo in your browserKey Takeaway
Behavioral parity is what makes a legacy-tool port credible — and the batch engine is the product: solve the painful import-and-export workflow before making the designer pretty.
Ready to Build Your Platform?
One 30-minute call to see if we're a fit. No pitch. No pressure. In English or Spanish — just a conversation about what you need to build.
Every engagement is scoped and quoted individually — no rate card, and no price before we understand the system. The first step is a 30-minute call, in English or Spanish; you leave it with a clear read on scope, sequence, and what the work would take.