WiseStamp

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me email signatures that replace WiseStamp: one template, everybody's details filled in, and a banner I can change centrally.

STACK
- Node 20+ with Fastify, server-rendered HTML
- SQLite through better-sqlite3, WAL mode
- MJML or a hand-written table-based renderer for the HTML. Do not write signature markup by hand
- Caddy in front

THE PROBLEM, WHICH IS ENTIRELY ABOUT MAIL CLIENTS
- A signature is HTML rendered by dozens of clients that support different subsets of CSS, some of them decades old
- So: tables for layout, inline styles only, no flexbox, no grid, no external stylesheet, no web font, no background image, no SVG. Widths in pixels with a fixed outer width
- Outlook for Windows renders with the Word engine, which ignores most CSS and handles images and spacing differently from everything else. It is the constraint that decides the design, and testing there is not optional
- Dark mode inverts colours unpredictably: a logo on a transparent background becomes invisible or a black box. Use images with a solid background matched to the signature, and test in dark mode in the main clients
- Images must be hosted absolutely and cached forever, and every one needs alt text because many clients block them by default. A signature whose only content is an image says nothing to a large share of readers

THE DATA MODEL
- templates: id, name, mjml_source, fields_json, version, is_active
- template_versions: id, template_id, version, mjml_source, published_at — a published signature is pinned to a version so a template edit does not silently change what people have already installed
- people: id, email, first_name, last_name, title, department, phone, mobile, pronouns, links_json, photo_path, is_active, group_id
- groups: id, name, template_id, banner_id — the department or office, because different teams need different templates
- banners: id, name, image_path, link_url, alt_text, starts_at, ends_at, group_ids_json, is_active
- signatures: id, person_id, template_version, banner_id, html, text, rendered_at
- clicks: id, signature_id, banner_id, at, ip_hash, bot — if the banner links anywhere
- Everything renders from the template plus the person plus the current banner. A signature is never edited by hand, or it stops being consistent within a week

THE CENTRAL BANNER, WHICH IS WHAT IS ACTUALLY BEING BOUGHT
- A banner has a date range and a target group. When it changes, everybody's signature changes without anybody editing their settings
- That works because the image is served from your own URL and the client fetches it when the mail is read. Change what that URL returns and every signature already sent updates too — which is powerful and slightly startling, so think about whether you want it for past mail and version the URL if you do not
- A short link through your own domain for the click, so you know whether the banner did anything
- Bots and mail-scanner fetches flagged and excluded from the numbers, because a corporate mail gateway fetches every image in every message

DELIVERY, WHICH IS THE AWKWARD PART
- There is no universal way to install a signature. The honest answer is per client:
  - a copy button that puts the rendered HTML on the clipboard as rich text, which works for most people in most clients
  - a downloadable HTML file for the clients that import one
  - an administrator route for the platforms that support a central policy, which is the only way it genuinely stays consistent
- Say plainly in the README which routes exist and which require somebody to paste. Pretending otherwise is how a rollout fails
- A per-person page with their signature, the copy button and step-by-step instructions for their own client. Sending forty people a generic instruction is how thirty of them end up with no signature

WHAT GOES IN A SIGNATURE
- Name, title, organisation, one phone number, one link. That is the useful part
- Everything else — a second phone, four social icons, a legal disclaimer, a quotation, a request not to print — makes it longer than the messages people send
- The tool should show the rendered height and warn past a threshold. A signature taller than a typical reply is the thing everybody complains about and nobody measures

TESTING
- Render every template into a preview grid at the widths clients use, and export a test message to send to a set of real addresses across the main providers
- A checklist in the interface: images blocked, dark mode, Outlook, phone width, plain text fallback
- The plain-text alternative generated from the same source, because a signature that is an unreadable block of markup in plain text is a signature people notice

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, HASH_SALT
- Migrations on boot, each once
- Images served with immutable cache headers and a content hash, except the banner if you intend it to update in place
- Nightly backup, restore script
- Health endpoint that renders one signature

WHAT MATTERS MOST
Outlook and images-blocked. Render your template there and with images off before designing anything else, then keep the signature short. Everything in this category that goes wrong goes wrong in those two places.

Give me the repository, the templates, the renderer, migrations, .env.example, the per-person install pages, and a README with the client compatibility table and the deployment routes.