Song Tailor: how we connected orders, payments and outreach controls for a small custom‑song business
Song Tailor (songtailor.net) is our founder's own custom‑song business, operated under EGYRICAN LLC. It is an internal implementation project, not an independent paying client. We use it to build and test the kind of systems we offer small businesses.
The songs are written, produced, reviewed and delivered by people. What we automated is the work around them: collecting the right details, matching payments to orders, and running outreach with guardrails. Some of it runs on its own, some is run by the owner on demand, and some is planned. Each item below says which.
Status is taken from deployment and operating reports dated October 24, 2026. The code backup we could inspect directly is dated October 2, 2026, so later changes are described from those reports rather than a fresh inspection of the live systems.
The business problem
Song Tailor is run by its owner, so every manual step competes with making songs. The business needed to:
- Collect customer stories and song requirements the same way every time.
- Connect each payment to the right customer brief and package.
- Collect separate details for every song in a multi‑song bundle.
- Run outreach to schools and daycares without contacting anyone twice or breaking send limits.
- Track failures and sends whose outcome was uncertain.
- Check where emails land before sending more outreach.
- Produce branded promotional videos with less repetitive editing.
- Stay manageable for one person.
What we built
Fifteen pieces of automation in four groups, with their status as reported on October 24, 2026.
| # | Automation | Status |
|---|---|---|
| 1 | Customer brief to checkout | Deployed (production reports) |
| 2 | Payment verification and order creation | Deployed |
| 3 | Multi‑song bundle intake | Deployed; a two‑song test order saved both briefs |
| 4 | Automatic payment receipts | Confirmed in an owner‑funded checkout test |
| 5 | Unfinished‑bundle check | Built and reported used; run by the owner, no schedule |
| 6 | K‑12 school outreach | Previously in production; paused |
| 7 | College athletics outreach | Previously in production; paused |
| 8 | Daycare outreach | Previously in production; paused |
| 9 | Shared sending controls and alerts | Deployed (reports) |
| 10 | Deliverability testing and protective pauses | Implemented with operator involvement |
| 11 | Seed‑result expiry and readiness reporting | Implemented and reported tested |
| 12 | Contact‑data repair and temporary holds | Done once, as reviewed maintenance |
| 13 | Social‑video production | Owner‑run tools |
| 14 | Creator‑outreach document builder | Owner‑run tool |
| 15 | Deployment checks | Used for deployment (reports) |
Orders and payments
1. Customer brief to checkout
- Trigger
- The customer submits the order form.
- Steps
- The customer picks a package and describes the occasion, names, story and preferences. The server checks the brief and a bot check, saves a temporary draft, and opens the matching Stripe checkout with a reference to that draft. A draft on its own grants nothing.
- Tools
- Website JavaScript, Cloudflare Pages Functions, Cloudflare Turnstile, Cloudflare KV, Stripe Payment Links.
- Replaces
- Gathering requirements through scattered messages and matching them to payments by hand.
2. Payment verification and order creation
- Trigger
- A Stripe webhook, or the customer returning to the thank‑you page.
- Steps
- Verify the payment notification or look up the checkout session, identify the package actually bought, check the amount, currency and any discount, attach the saved brief, create the order and its private access link, and show the customer its status.
- Tools
- Stripe, Cloudflare Pages Functions, Cloudflare KV.
- Replaces
- Checking payments, creating order records and copying requirements by hand.
- Why it helps
- The webhook can record an order even if the buyer closes the browser before returning to the site. Both paths are designed to create the order once, though no system is immune to every possible timing issue.
3. Multi‑song bundle intake
- Trigger
- The customer opens the order's brief page.
- Steps
- Check access to the order, read how many songs were bought, show completed and remaining briefs, collect each remaining song's details, save and lock each brief, and update progress.
- Tools
- Website JavaScript, Cloudflare Pages Functions, Cloudflare KV.
- Replaces
- Back‑and‑forth emails about which story belongs to which song. A completed brief is not a produced or delivered song.
4. Automatic payment receipts
- Trigger
- A successful payment, under the configured Stripe receipt settings.
- Steps
- Stripe sends the buyer a receipt and the owner a payment notification.
- Tools
- Stripe email notifications.
- Replaces
- Preparing receipts by hand. This is a receipt only, not a song‑delivery or order‑recovery email.
5. Unfinished‑bundle check
- Trigger
- The owner runs the check.
- Steps
- Read the orders, compare songs bought with briefs submitted, and list orders still missing details with their return links. The owner then contacts those customers personally; reminders are not automatic.
- Tools
- Cloudflare KV order records and an operational script.
- Replaces
- Opening orders one by one and counting missing briefs.
Outreach
Three outreach workflows ran in production and were paused as of the latest report. They follow the same pattern and share one set of sending controls.
6–8. K‑12 school, college athletics and daycare outreach
- Trigger
- Weekdays, when enabled: K‑12 at 7:30 AM, college athletics at 10:45 AM and daycares at 12:45 PM, New York time.
- Steps
- Read eligible contacts, remove suppressed and already‑contacted addresses, apply daily and per‑organization limits, choose wording for the type of school (athletics wording for colleges; the daycare's name when suitable, otherwise neutral wording), reserve permission to send, send one email, record its Gmail message ID, confirm the send, update the sheet, and pace before the next.
- Allocation
- Configured for up to 15 (K‑12), 7 (college athletics) and 8 (daycare) emails per weekday.
- Tools
- n8n, Google Sheets, Gmail/Google Workspace, a Cloudflare sending gate.
- Replaces
- Filtering spreadsheets, preparing and personalizing each email, sending one at a time, and recording outcomes.
9. Shared sending controls and alerts
- Trigger
- Every attempted send reservation, confirmation or workflow error.
- Steps
- Check eligibility and earlier reservations, check the shared daily and per‑domain limits, reserve a sending slot, send through the workflow, and confirm with the Gmail message ID. Sends with an uncertain outcome are kept for reconciliation and are never retried automatically. When an error needs attention, the workflow stops and alerts the owner using only sanitized, allowlisted details.
- Limits
- 30 prospect emails per day overall, and 2 per recipient organization domain per New York day. Personal email domains are not treated as one organization. Grouping by domain is an approximation, since one organization can use several domains.
- Tools
- Cloudflare Worker and Durable Object, n8n, Google Sheets, Gmail alerts.
- Replaces
- Coordinating several campaigns by hand and investigating uncertain sends.
Deliverability checks
10. Deliverability testing and protective pauses
- Trigger
- A scheduled Claude task, or a test the owner starts.
- Steps
- Send campaign samples to fixed test inboxes, wait for results, classify inbox, Gmail tab and spam placement, record the results, check them against thresholds, deactivate affected outreach workflows when the hold rules require it, then read back the workflow states and report.
- Limits
- Not enforced inside the sending gate. A browser approval prompt or an unavailable Mac can stop a scheduled run. Gmail's Promotions and Forums tabs count as inbox, with Primary reported separately. A seed test is a diagnostic sample, not a guarantee of delivery to real prospects. The latest configured batch was 84 emails (28 seed recipients for each of three campaigns); that is a configured size, not proof that every batch completed.
- Tools
- Claude scheduled tasks with browser interaction, a protected n8n webhook, Gmail, MailReach, local result logs.
- Replaces
- Repeated manual test sends, collecting results and pausing campaigns by hand.
11. Seed‑result expiry and readiness reporting
- Trigger
- The status script runs, including for scheduled reports.
- Steps
- Read recorded results, apply documented corrections while keeping original timestamps, take the latest completed result per campaign, work out when it expires, check whether it is still valid, and forecast whether it covers upcoming scheduled runs. A newer FAIL overrides an earlier PASS, and incomplete or skipped tests do not extend validity. Reports never re‑enable outreach on their own.
- Tools
- Node.js, the seed‑result log, campaign thresholds.
- Replaces
- Calculating deadlines and comparing schedules by hand.
Maintenance and production tools
12. Contact‑data repair and temporary holds
- Trigger
- The owner starts a maintenance workflow.
- Steps
- Identify affected rows, verify the expected old values and unsent status, correct the intended fields or add temporary provider holds, read back and verify the results, and keep undo records. This is not continuous data cleanup.
- Tools
- n8n, Google Sheets, source‑directory data, checking scripts.
- Replaces
- Hundreds of individual edits and manual cross‑checks.
13. Social‑video production
- Trigger
- The owner runs a Python script.
- Steps
- Load prepared songs, footage, text and brand assets, assemble scenes and audio, add animated lyrics, transitions, graphics and branding, render, and export vertical (9:16) and feed (4:5) versions. Some scripts use beat‑responsive effects, and a shared toolkit checks decoding, loudness, peak level and file size.
- Limits
- It does not create customer songs or publish to social platforms. Creative review stays with a person.
- Tools
- Python, FFmpeg, Pillow, NumPy, PyAV.
- Replaces
- Rebuilding layouts, transitions, branding and export settings for every video.
14. Creator‑outreach document builder
- Trigger
- The owner supplies a structured creator list and runs the script.
- Steps
- Read grouped creator information, add profile links and the supplied reasons for fit, combine personal openers with category templates, and export a formatted Word document. Finding and checking creators is separate, and nothing is sent automatically.
- Tools
- Node.js and the docx library.
- Replaces
- Formatting documents and assembling outreach drafts by hand.
15. Deployment checks
- Trigger
- The owner starts the deployment script.
- Steps
- Check the generated video‑size list, run the test suite, stop if anything fails, and deploy only if everything passes. The owner then checks the live site.
- Tools
- Shell and Node.js scripts, automated tests, Wrangler, Cloudflare Pages.
- Replaces
- Remembering and running each pre‑deployment check by hand.
Overall stack
| Website | Static HTML, CSS and JavaScript on Cloudflare Pages |
|---|---|
| Server logic | Cloudflare Pages Functions and Workers |
| Data | Cloudflare KV for drafts and orders; Durable Object storage for outreach coordination |
| Bot protection | Cloudflare Turnstile |
| Payments | Stripe Payment Links, Checkout Sessions, webhooks and receipts |
| Outreach | n8n Cloud, Google Sheets, Gmail/Google Workspace with OAuth |
| Deliverability | MailReach, Google Postmaster Tools, Instantly warm‑up |
| AI | Claude and Claude Code for development and operator‑assisted scheduled tasks |
| Media | Python, FFmpeg, Pillow, NumPy, PyAV |
| Documents | Node.js and docx |
| Delivery | Git/GitHub, automated tests, Wrangler |
Suno is used in the creative process, but there is no verified integration that sends orders to Suno. We found no verified live OpenAI API integration, no Make scenarios, no automated final‑song delivery and no autonomous social publishing.
Results we can substantiate
These figures come from dated operating reports. They are not independently verified current totals.
| What | Figure | Qualification |
|---|---|---|
| Packages offered | 20, across five service categories | As reported |
| Outreach campaigns | 3 | Paused in the latest report |
| Sending ceiling | 30 prospect emails per day | Configured limit, not volume achieved |
| Per‑organization cap | 2 emails per domain per day | Configured; domain grouping is approximate |
| Reconciled sends | 45 in one documented interval | Send log grew from 495 to 540 rows |
| One full K‑12 run | 15 of 15 emails sent, confirmed and logged | A single run |
| Data maintenance | 602 row updates (563 + 39) | Two one‑time operations |
| Deliverability holds | 3,743 temporary holds | Reported on October 22, 2026 |
| Payment paths | Validated with an owner‑funded paid checkout and a fully discounted checkout | Test transactions, not revenue |
| Paid order records | 3 in production | Includes testing; not three paying customers |
| Automated tests | 157 website, 36 gate and 11 seed‑status tests | Reported at different stages; not one combined total |
We have no verified figures for delivered songs, genuine customers, revenue, conversions or hours saved, so we make no claims about them. The time saved is in the manual steps each automation replaces, described above.
Planned improvements
None of these are live.
- Email follow‑ups (built; disabled / dry‑run): a scheduled n8n workflow that checks Gmail threads for replies and prepares follow‑ups around days four and nine, then logs outcomes.
- Gate‑enforced seed freshness (proposed): check for fresh deliverability results before every send reservation, so it no longer depends on an awake Mac.
- Week 8 monitoring (designed): bounce, reply and opt‑out monitoring with holds and daily reporting.
- List‑Unsubscribe headers (built, not published): send through the raw Gmail API to add unsubscribe headers while keeping the sending controls.
- Website inquiry form (optional endpoint exists, disabled).
What this shows for your business
We keep your technology working, and help your business work smarter. Song Tailor is where we practise that on our own business first. We automate the repetitive steps around the work, such as intake, payment matching and outreach admin, and keep people in charge of quality and decisions. We build in limits, logging and alerts from the start, test before we deploy, and tell you plainly what is live, what someone still runs by hand, and what is only planned. The same building blocks fit a dental office, a tax practice or a contractor that takes bookings, payments or leads online.