Francesco Di Lorenzo

Side project needed

Jan 11, 2020

I need a distraction. What’s something that’s technically challenging, fun, limited in scope and that could actually be useful?

Ben Orenstein, co-founder of Tuple and co-host of Art of Product, gave me just the right idea in this tweet:

A service that gives you unique email addresses that you can use to get emails and newsletters on your own schedule. Nice bonus: it also protects your privacy and allows you to nuke an address if you start getting spam from it.

This is somewhat related to what we are building over at Superlinear with Mailbrew, but more limited in scope. Something I could build all on my own in a short time.

Does it fit the requirements?

I wanted this to be fun, limited in scope, useful and technically challenging. This would not be that technically challenging on its own, if I stick to my guns and build it with the same tech I use for all my other projects, but it could be very challenging if I try something new. I think this project is the perfect fit for some Amazon Web Services kung fu. Running it there with some of the tech I am going to mention below would also potentially make it very low-maintenance.

Why AWS

Up until know I have used AWS tangentially with the excellent Amazon S3 (storage) and Amazon SES (super-cheap email sending), but I have never built an app that runs entirely on AWS.

The desire to experiment with this has been growing since I started hearing from some friends about how cool AWS is, and the amazing things even small teams are building at scale on it. Then I started following Daniel Vassallo and read his excellent AWS: The Good Parts.

To top it up, last night I went to the Serverless meetup, hosted here in Milan at the AWS offices and something one of the speakers said stuck with me. There was this quote from Linus Torvalds saying how personal computers changed his life by allowing him to develop Linux while a teenager in his bedroom. And then the speaker talked about lambdas and other AWS tech that really democratizes building products by making it extremely cheap, easy to run and scale. This enables not only to fail fast, but to fail cheap. Bingo.

All of this to say: it’s about time I give this a try.

How would this service work

The way I am seeing this right now, you would setup an account and pick your username.

Then from inside the app you can start creating new email addresses. As an example, username-news@service.com could be your email for newsletters. After creating it you can set it up to only deliver emails on Sunday at 10am to your own email address.

With this you could enjoy a newsletter-free inbox for the rest of the week and go all-in on newsletters Sunday morning.

Another use case could be to throttle services that constantly emails you when what you want is just a digest each day (think of a customer support inbox, like in Ben’s original Twitter thread).

Building this service on AWS

First step is getting the inbound emails in order to process them. That’s easily done with Amazon SES. You can also attach a lambda that processes the email and does stuff to it, or just let the email be saved to an S3 bucket, still haven’t decided what’s the best option in my case. Emails would be encrypted at rest (S3 supports this out of the box).

Then comes processing the emails. In order to do this there needs to be some recurring jobs (lambda? Can they be run periodically?) that looks at the received emails and based on the recipient address finds the user, his desired schedule for that address and spawns another lambda that sends the message at the right time.

Between these two lambdas, the one processing the received emails and the one sending out the email there could be room for another AWS service, maybe something for queueing jobs that also offers retries if a job fails. Here my lack of knowledge in AWS-related topics starts to show. Feel free to reach out if you know what I need here.

I also need some sort of storage or db for users and their settings and, right now, for that I am thinking of giving a spin to DynamoDB after hearing of its amazing performances, costs and scaling features.

Conclusion

I don’t know if I am actually going to build this, but if I do it will be fun to come back to this post and see what I did different with respect to the plan.