Ken 👨🏽‍💻

I remember when I started building StackShift and was using SES for emails. When I got closer to launch, I applied for SES production access so StackShift could send real emails to users, not just the one verified email I was using in sandbox. AWS kept rejecting it. They were asking for so many things I didn’t have yet: clearer use case, sending patterns, bounce handling, complaint handling, suppression strategy, opt-in details, domain setup, abuse prevention, and all the things you’re expected to already understand before you can even send email properly. At that point, I moved to Resend so I could keep shipping. But the thought stayed in my head: Why is this not a StackShift feature? If StackShift is supposed to help developers deploy and run real applications, then transactional email is part of that story. Apps need to send emails for several things. So instead of depending on yet another external service, I decided to build StackShift Mail. Not as a wrapper around SES. Not as a wrapper around Resend. Not as a wrapper around Mailgun. Actual StackShift-owned mail infrastructure. The flow now is: App calls StackShift Mail → message is stored → send job is queued → worker composes the email → DKIM/signing path is handled → Postfix hands it off → attempts/logs/status are tracked → failures can be retried → bounces can be processed → bad recipients can be suppressed And the most interesting part is that StackShift Mail is powered by another StackShift primitive I already built: StackShift Jobs. StackShift Jobs is the durable background execution system I built for work that should not die when the request ends. Instead of doing everything inside an HTTP request, you can offload work to StackShift Jobs and let it handle retries, attempts, logs, delayed execution, failures, and recovery. That means Mail does not have to block the user’s request. When you call mail.send, StackShift can accept the message, queue the work, process it safely, retry temporary failures, and keep a full trail of what happened. That same Jobs system also powers things like OTP expiry, webhook delivery retries, bounce processing, scheduled sends, batch sending, and reputation evaluation. This is why building platform primitives matters. One primitive unlocks another. So far, StackShift Mail now has: transactional email sending API-key scoped usage message persistence send attempts logs Postfix handoff DKIM/signing integration path customer domain verification SPF/DKIM/DMARC/return-path checks sender domain enforcement bounce handling hard/soft bounce classification suppression lists automatic blocking of bad recipients OTP send and verify OTP expiry max attempts resend cooldowns hashed OTP storage templates template versions backend template rendering template preview test sends sendTemplate API mail lifecycle events webhooks webhook signing webhook retries message timeline reputation checks sending limits warmup stages domain reputation scheduled emails transactional batches attachments inbound mail foundation analytics, etc. This started because I got blocked trying to send emails for StackShift. Now it’s becoming a full StackShift product. Deploy the app. Run the jobs. Send the emails. Track what happened.

Pushed WordPress much further on StackShift. It's not just a template. (Legacy) Now you can: - Create WordPress directly - Launch multisite networks - Import existing installs - See WordPress/PHP/runtime/storage/DB health at a glance - Install themes - Run safe actions like core updates, maintenance mode, permalinks flush, and admin reset - Deploy on StackShift managed server, your VPS, or Cloud account, etc. If you’re a WordPress designer, builder, or agency, I’d love to show you what we’re building.

Deployment on Stackshift

Day 15 of learning system design Today was all about understanding how databases actually behave when systems scale. I learnt about database transactions and why ACID properties (Atomicity, Consistency, Isolation, Durability) matter more than people think. It’s the reason why your data doesn’t randomly go missing when multiple processes hit the same database. It’s crazy how much reliability depends on those four principles, you can’t build scalable systems if your data layer is weak. I also watched an AWS event session on YouTube, but it wasn’t just theory, it was about how to deploy and manage projects using AWS tools. It gave me a clearer view of how real teams use AWS for scalability and system management, not just for hosting. Still using System Design Primer on GitHub. Hold me accountable ❤️