Show HN: Loopletter: Open-source email marketing platform
Show HN (score: 6)Description
What’s inside:
- Full campaign builder (visual editor, reusable templates, optional Spotify-powered layouts)
- Audience management tooling (imports, segmentation, consent workflows, list cleanup)
- Queue-driven sending with AWS SES, BullMQ, and Redis — handles rate limits, retries, and
deliverability feedback
- Analytics dashboards with real-time metrics, campaign history, and basic attribution
- Infrastructure scripts for Supabase, AWS EventBridge/Lambda, and Upstash Redis so you can set
everything up from scratch
Tech stack: Next.js, React 19, TypeScript, Tailwind, Clerk for auth, Supabase (Postgres)
for storage, AWS SES + S3 for mail/asset delivery. The repo has docs, scripts, and a demo data
sandbox because we know email platforms can be boring to set up without real content.
Why open-source? Most tools in this space are either huge enterprise SaaS products or
very marketing/sales oriented. Independent artists have different needs (merch drops, tour
announcements, limited release windows) and usually lean on social platforms they don’t control.
Email still converts best for them, but standing up a full stack is painful. We’d love to see
small labels, agencies, and indie devs fork it, run it for their communities, or contribute
features.
I'm especially curious if this has potential to be something bigger.
Repo link: https://github.com/createdbymax/Loopletter-Open-source-email-marketing-platform
Production website: https://loopletter.co/
Happy to answer questions about the project, SES deliverability, or anything else related to
running email at indie scale. Thanks for taking a look!More from Show
Show HN: I just fixed .env once and for all – better-env
Show HN: I just fixed .env once and for all – better-env .env files have always felt archaic, insecure, clunky and honestly just not fun to work with. I see my friends (and myself) accidentally committing them all the time. Managing secrets across projects becomes a mess of copy-pasting keys into scattered env files with no real way to sync anything.<p>So I built better-env: a secure, developer-friendly alternative to .env.<p>Store your secrets once in a global encrypted store, and load them per-project at runtime.<p>I’d love feedback on whether this feels useful beyond solo devs, and what you’d want for teams or CI setups.<p>Fully open source: <a href="https://github.com/HarishChandran3304/better-env" rel="nofollow">https://github.com/HarishChandran3304/better-env</a>
Show HN: Built a tool solve the nightmare of chunking tables in PDF vs. Markdown
Show HN: Built a tool solve the nightmare of chunking tables in PDF vs. Markdown Hey HN, solo dev here. After years of frustration with how LLMs handle complex documents, especially PDFs with tables, I decided to build a solution myself. My approach uses a Markdown conversion step to preserve the table structure, which seems to work surprisingly well for chunking. This little parser is the first public piece of a much larger, privacy-focused AI platform I'm building. I'm pretty much running on fumes financially, so any feedback, critique, or support is massively appreciated. Happy to answer any questions about the approach!
Show HN: better-env – A Secure, Developer-Friendly Alternative to .env
Show HN: better-env – A Secure, Developer-Friendly Alternative to .env I’ve always hated how archaic .env files feel. Plaintext, easy to leak, and once they hit git history… you’re cooked. After accidentally committing secrets a few too many times, I finally asked myself: why don't we encrypt secrets just like passwords?<p>So I built better-env: a local, encrypted way to manage secrets without exposing plaintext all over your machine. One place for secrets, nothing sensitive in git, your secrets get directly loaded at runtime, project-wise.<p>It’s early, local-first, and still rough around the edges, but it already removed a whole category of stress from my workflow. I’d love feedback on whether this feels useful beyond solo devs, and what you’d want for team/CI setups.<p>It's open source too! (<a href="https://github.com/HarishChandran3304/better-env" rel="nofollow">https://github.com/HarishChandran3304/better-env</a>)
Show HN: YAAT – Privacy-first analytics for EU companies (need for beta users)
Show HN: YAAT – Privacy-first analytics for EU companies (need for beta users) I built YAAT for EU companies that can't of send data to US servers or being locked into pre-built dashboards that can't answer custom questions.<p>What makes it different:<p>Direct SQL access to your data. Not just pre-built reports – write actual queries against your raw events. Want to know which UTM campaigns convert best for mobile users in Germany? Write the query, get the answer, save it as a dashboard panel.<p>Full analytics stack:<p>Web analytics: pageviews, sessions, traffic sources, UTM tracking, device/browser/geo data Error tracking: JavaScript exceptions, unhandled promises, stack traces, filtering by browser/version Performance monitoring: Core Web Vitals (LCP, FID, CLS, INP), page load times, TTFB<p>Custom dashboards: Drag-drop panels anywhere. Time series, bar charts, pie charts, maps, tables. Monaco editor with SQL autocomplete. Export data as Parquet files – full ownership.<p>Privacy-first: EU-hosted infrastructure (no data transfers), GDPR-compliant, no cookies needed, lightweight script (<2KB).<p>Domain verification via DNS ensures only your sites can send data.<p>Current state: Beta with 7 verified domains tracking production traffic. Looking for 10 EU companies to test for 3 months free.<p>Want feedback on SQL interface and what analytics patterns matter most for your business.<p>Try it: <a href="https://yaat.io/beta" rel="nofollow">https://yaat.io/beta</a><p>Built in Valencia, Spain. All data stays in EU.
No other tools from this source yet.