# Build brief — a focused alternative to Sendcore

> **Verdict:** Not faithfully · **Buildability:** 6/100 · **Category:** Newsletter
> **Source:** https://www.canitbevibecoded.com/sendcore
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from Sendcore. Verify current pricing and capabilities before acting.

## Context

**Sendcore** — Campaigns, automations, popups and store attribution, installed into a Shopify or WooCommerce shop. It currently costs $16/mo.

The editor is the copyable part. A coding agent will happily build a private Shopify app that pulls your products, composes an HTML campaign and sends it with your own provider key, and for one store that is genuinely useful. What does not fall out of a one-shot is everything that makes it a product a merchant can run a business on: a listed App Store app with OAuth, mandatory GDPR data webhooks and billing that lands on the merchant's own Shopify invoice, per-tenant domain authentication with the DNS handholding it needs, and the consent, suppression and bounce records that keep sending both legal and delivered. Worth saying plainly: Sendcore is small and recent, with no audience network and no proprietary dataset to hide behind. It survives on platform surface, compliance plumbing and the unglamorous backlog that only real merchant sending reveals, which is a narrower moat than Klaviyo's and an honest one.

This brief describes a focused, single-operator replacement for the part of Sendcore that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

## What you are building

Build a private Shopify app that syncs your products and customers, composes an HTML campaign with a product block, and sends it to a consented segment through your own email provider key.

- Compose, segment, preview, and queue a small newsletter workflow.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- Node.js 22.
- SQLite.
- A sending domain you control, with SPF and DKIM already verified.

### Data and integrations

- Shopify custom app Admin API token (read_products, read_customers, read_orders).
- Bulk email provider key in.env.

Each of these needs a real account, credential, or quota. Set them up before writing feature code.

### Non-functional

- Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
- Security: server-side secrets, validated input, and no credentials in the client bundle.
- Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
- Portability: the operator can export their data and leave without losing it.

## Implementation brief

Build me a private Shopify campaign sender for one store I already own. Not a SaaS, not multi-tenant, no signup. Requirements:

- Node 22 + Fastify + better-sqlite3, server-rendered HTML, no client framework.
- Read the store with a Shopify custom app Admin API token I create myself
  (read_products, read_customers, read_orders); no OAuth, no App Store install flow.
- Send through one bulk email provider with my API key and my already-authenticated
  sending domain; both in .env, ship a .env.example.
- SQLite tables: contacts (email, consent state, source, created_at), products cached
  from Shopify, campaigns (subject, body_html, status, sent_at), and sends
  (contact_id, campaign_id, status, error).
- Every contact carries an explicit consent state. Never send to an unsubscribed or
  unconsented contact, and prove that with a test.
- Every email gets a working one-click unsubscribe link plus List-Unsubscribe
  headers, backed by a signed token and honoured immediately.
- The composer is a plain HTML textarea plus a product picker that inserts image,
  title, price, and link from the synced cache. Render with inline styles and a
  table layout so it survives Gmail and Outlook; no external stylesheets or web fonts.
- Always send a test to myself first, and require a typed confirmation of the
  recipient count before any real send.
- Send in batches with retry and backoff, one send row per recipient, so a crash
  resumes instead of double-sending. Report delivered and failed from the sends
  table only; do not invent open or click tracking.
- CSV import and export for contacts so the data is never trapped in the app.
- Tests: the consent gate, the unsubscribe token, batch resume, and one end-to-end
  campaign against a mocked provider.
- README states what this is not: no deliverability operations, no bounce or
  complaint processing, no App Store distribution, no billing. Say plainly that real
  volume from a cold domain lands in spam, and warmup is now the reader's job.

## Delivery standard

- Inspect the repository first, then write a short implementation plan before writing code.
- Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
- Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
- Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
- Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
- Add structured logs around every external call and return actionable errors without leaking sensitive details.
- Write unit tests for the core logic and one automated test of the main user journey.
- Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

## Acceptance criteria

- [ ] A clean install starts the app using only the README and .env.example.
- [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
- [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
- [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
- [ ] Tests, type checking, linting, and a production build all pass with no ignored failures.
- [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

## Non-goals

Do not build these, and do not claim to have replaced them:

- App Store distribution: OAuth install, app review and the mandatory GDPR data webhooks.
- Billing that appears on the merchant's own Shopify invoice instead of a separate card.
- Domain authentication onboarding and per-tenant sender reputation.
- Bounce, complaint and suppression handling.
- Connectors, OAuth flows, and vendor API changes require constant upkeep.
- Compliance, licensing, and legal accountability are core features.

## What you still own after launch

- Secure credentials, rotate secrets, and handle provider rate limits.
- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.
- Maintain every third-party integration as APIs and OAuth rules change.

## Risk

**High consequence.** Use this as a prototype or personal aid. Keep a qualified human and an established provider in the loop for consequential decisions.

Editorial confidence in this assessment: medium. No independent one-shot implementation is linked yet.

## Prior art

Working open-source software you can read, fork, or borrow from before starting:

- [listmonk](https://github.com/knadh/listmonk) — High-performance self-hosted newsletter and mailing-list manager
- [Mautic](https://github.com/mautic/mautic) — Open-source marketing automation platform
- [Keila](https://github.com/pentacent/keila) — Open-source newsletter tool with campaigns, segments and forms

---

Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/sendcore