Thanks for the upvotes so far!

I would love to dig into the actual developer experience side. One of the main reasons I built this was to kill the sleep(5) or polling loops in CI by using Server-Sent Events (SSE) in the SDKs, so tests react instantly.

For those of you managing large test suites:

- Does your current team rely on mocks/Mailtrap style catch-alls, or do you just trust that the protocol (TLS/DKIM) works?

- How are you currently handling PII in dev/test email logs? (This is why I went with encryption for zero-plaintext storage on the server).

Any feedback would be really useful, since until now I have gotten none and as a solo dev it gets to a point that you do not know if it is a good idea or not.

Thanks again,

▲

rancar2 2 days ago | parent [-]

Having sent billions of emails between multiple startups:

RE setup and testing: Trust (as is most devops one-time setups). Once the initial email setup is complete, you typically aren’t paying with it much. The black swan outages aren’t really an active concern.

RE PII: email is non-secure and shouldn’t have sensitive data in production either. Also, dev/test shouldn’t have PII in regulated industries as a good hygiene practice (I’ve worked in healthcare, finance, and national security contexts).

Re licensing: I appreciate your openness and clarity on the licensing of the gateway engine as AGPL vs MIT for the rest. There’s a more modern licensing approach with FSL-1.1-MIT. It may be a better fit for customers (ie clear licensing terms when using a paid license and less concerns if the business goes defunct or pivots) and for your business plans.

▲

vaultsandbox 2 days ago | parent [-]

Thanks, someone who has sent billions of emails is exactly who I need to ask.

Regarding 'set and forget': I agree once infra is stable, it stays. But I see the value when the application layer changes—tweaking templates, switching providers, or DNS updates. Do you still feel mocks are enough there?

Regarding PII: You're 100% right on hygiene. The encryption (ML-KEM-768) is just a 'safety net' for the human errors.

Regarding FSL-1.1-MIT: Very interesting suggestion. I will investigate it.

Honest question: At your scale, is this a niche tool or is 'mock and pray' just the industry standard for a reason? Don’t worry about hurting my feelings, I just need to know if I'm solving a real problem.

▲

rancar2 2 days ago | parent [-]

For a bit more context, most email infrastructures I’ve worked with are for transactional and marketing DTC and B2B companies. I would read my response in this context.

Re one-time setups and one-time changes: I think this will answer both questions and the implied PMF question as well. For internal FTE staff, this will be handle as a one off exception consistently (it’s really no one’s full-time job or responsibility). You may wish to speak with teams that offer professional services / SaaS including self-hosted where this infrastructure would be helpful. Their jobs are made easier with additional predicable / dependable infrastructure software (ie chat with (a) Twilio’s messaging team which remains the SendGrid acquisition, (b) related Red Hat / IBM) vs more work for an individual who is just doing this one-off. You may wish to consider a revenue share and/or white-labeling as they co-install the infrastructure for your business.

	▲	vaultsandbox 2 days ago \| parent [-]
		Thanks for that perspective. My goal right now is not money, I just want to build something super helpful. If I can make some cash later, in a way that helps everyone, like with white-label or pro-services, that is great. If not, I am cool with that too. Building the community is the priority. If I do not solve a real problem for people, then the rest does not matter anyway. Really appreciate you taking the time to share that 'pro-services' angle. It has given me a lot to think about.