Can Sendcore be vibe coded?
Campaigns, automations, popups and store attribution, installed into a Shopify or WooCommerce shop
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.
Jump to the build brief ↓Checked Aug 2026
What you pay today, before any DIY hosting
medium editorial confidence
Buildability by layer
Screens, forms, and focused interactions
The repeatable job the product performs
Availability and legality of required data
Uptime, queues, support, and maintenance
Security, compliance, and user confidence
The achievable core
- 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.
The parts a prompt cannot buy
- 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.
Why people still pay
Merchants pay for the parts nobody enjoys building: staying installed and billed inside Shopify, keeping consent and suppression records defensible when a customer or a regulator asks, and getting mail into inboxes from a domain the merchant owns. The campaign editor is the part that demos well and the part an agent reproduces easily, right up to the moment other people's content meets other people's inboxes. Pasted rich text with mixed inline formatting, merge tags that must not eat the punctuation around them, product blocks that survive Outlook, automation timing that has to line up with a real order: none of these are design problems. They are a backlog you only discover by sending mail on behalf of other businesses, and grinding through it is what separates a demo from something a shop trusts with its list.
Connectors, OAuth flows, and vendor API changes require constant upkeep.
Compliance, licensing, and legal accountability are core features.
Reliability at the vendor's scale is an operations problem, not a prompt.
The brief
Context, requirements, acceptance criteria, non-goals, and the full production standard — as Markdown, ready for any coding agent.
Build brief — a focused alternative to Sendcore
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
You still own the product
- 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.
Open-source prior art
Before you start
Can Sendcore be vibe coded?
Not faithfully. 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.
What can an AI coding agent reproduce from Sendcore?
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.
What will a DIY Sendcore replacement still be missing?
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 do I still own after building a Sendcore alternative?
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.