How I Made Summarizesh*t.com

I made a new application recently that checks off all the latest buzzwords: "Highly scalable", "AI-powered", "Distributed", and "Cloud native". In addition to that, it's automatically deployed, scales to zero, and I did all of it in less than a day. There was no copy/paste, no code generators, and no, it doesn't even resemble a cobbled-together mess. I'll admit I did have a few things like accounts on the platforms I needed already in hand.

Let's talk about the idea. My wife walked by me last week glued to her phone and shaking her head. Immediately, because I'm super caring [obviously], I asked her what was wrong. She shook her head again and told me that someone had "sent her a book" of an email and that she was having trouble reading between the lines to gather action items and any information she needed to glean from the message.

I've had that exact problem before. Only a few moments later I smiled and said, "Hey, what about this...". She turned her head, cueing me to start a ramble. I described to her a service to which you could forward this email, some short time later it would reply with a summarized message. This could extend to large email threads, like conversations you've just been made privy to and don't want to read back through. Of course, it would use GPT because it's a game-changer for stuff like this.

So I got to thinking. 🤔 💭

This seemingly simple idea is actually surprisingly complex under the surface. Mail interfaces are never easy, and fairly slow. You would need something that could respond extremely quickly to limit user distraction. I also would never know my input traffic size, or be able to control it much at all, so I would need something scalable to process messages in parallel.

I'm also a busy guy, and I only had time for about one night of hacking to get it done. So to see if I could get this done in one night I had to do a bit of discovery. Since the product was fairly limited in scope, this came by way of a user story and then a quick product management introspection on what work items I needed to make this work. In the back of my mind, a system diagram was forming.

The user story ended up being like this:

This is the general user story for this side project:

1. I go to summarizeshit.com

2. I see instructions on how to get shit summarized which are as follows:
Thank you for your interest in summarizeshit.com! Does Jeannie at the office send you huge email messages with only two actionable items buried inside? Well, summarizeshit.com is built for you! Our service is designed to summarize long annoying messages [not just from Jeannie] into actionable content and insightful information. How does it work? Text ~ Forward a text [or book masquerading as a text] to 123-123-1234 and receive back a summarization text! Email ~ Forward an email to i@summarizeshit.com and receive back a summarization email!

3. I send an email to i@summarizeshit.com

4. I get an email with a summary back including "actionable items" and "insightful information".

Then I put into words how I thought it might work, following along with the user story a bit.

How this should work:

- We stand up an email account under Sendgrid or alike

- We process emails via webhook to a service running somewhere

- We extract the most recent message in an email thread and send it to GPT with "actionable" and "insightful" keywords

- We mark the incoming email address in a database with a count of uses

- We send an email back including the information and the number of remaining uses

The system diagram forming in my mind was like this:

So it was the end of the day and I thought to myself again, "I think tomorrow night I'll just do it."

Doing the thing

An important thing I strive to live by or teach those around me is to take calculated risks and just "Do the thing". Stop strategizing, planning, and sprinting so much, and just do the thing.

Just do it!
- Shia LaBeouf, at some point

In order to optimize my time, I had to make crucial decisions to make sure that I could indeed stand this thing up very quickly. I bought the domain summarizeshit.com and mapped the apex/www. DNS to GitHub the day before after a quick brainstorming session with the wife over coffee. This would ensure I didn't have to wait on DNS propagation or run into creativity issues right away.

I had chosen to deploy the landing page, the place of discoverability/instructions for my product on GitHub pages. It was a quick way to get a secure HTML page running. No need for API interactions, just a simple page. I skipped the creative part of building the static page and just made sure it worked, to begin with. I used the base GitHub actions from GitHub pages to deploy it from a folder named static. This optimized my time for the far more important inner workings.

Now I had to build an email ingress. I didn't know much about this but after a quick google, I found Sendgrid inbound webhooks. I thought this could be exactly what I needed, but alas when I went to sign up I found I had a deactivated account and it would take waiting and talking to customer support to reactivate it. No good, and a massive time waste. More googling revealed a competitor with a similar interface and inbound webhook system, Postmark. I signed up and had an API Key within minutes.

Next, with an email ingress now up, I had to wire this to some sort of API or service that was responsible for parsing and transmitting information to GPT. For the aforementioned variables such as speed, large overhead for transmission time, and ease of deployment, I chose google cloud functions to deploy a service. Within an hour I had a GitHub action wired up to deploy a cloud function on the Node runtime that would allow me to inspect the payload of a webhook. I fired off a test payload that allowed me to build an interface in TypeScript.

And yeah, I used TypeScript. For this sort of application, I wanted a surefire way to make sure a late-night fumble didn't cost me ten minutes of deployment iteration time waste. I already had a TypeScript boilerplate, so I used a basic tsconfig and got rolling. Normally TypeScript would slow you down at first, but I didn't find this to be the case with boilerplate already in place.

With the service stood up and an interface built around the payload expected along with an ingress API key (that ensures the email service is the only one that can trigger the function), I built a simple bridge for OpenAI GPT. With this bridge built, it would funnel email text into prompts and then ask a final question with the conversational model to summarize the text and provide action items.

After wiring up the GPT bridge, I connected this output to an email reply via Postmark. This was pretty simple, but I had to ensure my sender domain was verified before attempting to send via summarizeshit.com.

After a deploy, it was time to test!

And it worked amazingly- so I sent it out to friends, who also happened to be devs. Unfortunately, like all devs, they are natural-born QA people so they immediately broke the application.

💥 My GPT wrapper was revealed! But that's ok, it allowed me to tweak responses for null output and figure out that I had a bug that limited character input. After a quick tweak to fix character limits, the blog post was summarized!

So, the last step was making a landing page. Again for time efficacy and ease, I decided to skip frameworks, preprocessors, and backends. I built a simple HTML page, with all inline styles.

And look at that, a near-perfect lighthouse score. 😂

Here's the codepen/source if you want to dig in:

🎨 I think this is all to illustrate that simplicity is a catalyst for just doing the thing. Look at your next project through the most pragmatic lens possible, and use a mix of modern tools that you're comfortable with and allow you to move fast. Then, after you do the thing and have some users, you can make optimizations to make it faster, work better, etc.