Dear Tomorrow

• 

  result

• 

  result

• 

  landing page

Inspiration

I wanted to create something simple, but also personal: a time capsule that lets people leave an encouraging message for their future selves and receive it at exactly the moment they choose. Sometimes we go through difficult periods and wish that our future selves could hear a few words of encouragement. Sometimes we want to celebrate a future milestone, such as graduation, a new job, or the completion of an important goal. Other times, we simply want to imagine what our future might look like and leave a message for that version of ourselves. Dear Tomorrow was created around that idea.

What it does

Dear Tomorrow is an AI-powered time capsule service. A user writes a message, chooses a future delivery date and time, and provides the recipient's email address. The message is stored securely in the cloud and delivered by email when the scheduled time arrives.

The service can be used for many different situations. You can write a message to yourself when you are having a difficult day and ask your future self to remember that you made it through. You can write a graduation congratulations message and schedule it for the day you expect to graduate. You can write down your current goals and ask your future self to reflect on whether you achieved them. You can also send a time capsule to another person as a meaningful future message. The goal is not simply to store a note. The goal is to create a moment in the future when someone opens their inbox and receives something from the person they used to be.

How we built it

I chose a serverless architecture because this project did not need a continuously running backend server.

The capsule creation process now works approximately like this: The user submits the recipient email, subject, delivery date, and message. API Gateway sends the request to Lambda. Lambda validates the required fields and verifies that the delivery date is in the future. Lambda sends the original message to Amazon Bedrock. Bedrock returns the transformed message. Lambda stores both the original and AI-generated messages in DynamoDB. A separate Lambda checks for capsules whose scheduled delivery time has arrived. The ready capsule is sent through Amazon SES. DynamoDB is updated from pending to sent. For the AI component, I used Amazon Nova Micro through Amazon Bedrock's Converse API. This provided a simple way to integrate model inference directly into the serverless backend.

The main AWS services used in the project are: Amazon S3 — static frontend hosting Amazon CloudFront — HTTPS and content delivery Amazon API Gateway — HTTP API endpoint AWS Lambda — application logic and scheduled email processing Amazon DynamoDB — capsule storage and delivery state Amazon Bedrock — AI-powered message transformation Amazon SES — transactional email delivery AWS Certificate Manager (ACM) — HTTPS certificate Route 53 — explored during DNS configuration (Domain/Korean DNS provider (내도메인.한국) — domain registration and DNS record management)

Challenges we ran into

One of the biggest challenges was not actually writing the application code. It was connecting all the cloud services correctly. Custom domain configuration required understanding the relationship between domain registration, DNS records, ACM certificate validation, and CloudFront alternate domain names. Email delivery introduced another set of challenges. Amazon SES requires identity verification and proper email authentication. I configured a domain identity for dear-tomorrow.kro.kr, enabled Easy DKIM, and added DNS records for authentication. I also requested SES Production Access because the service is intended to send transactional messages to user-selected recipients rather than only verified test addresses. Another challenge was learning that AWS regions matter. ACM certificates used by CloudFront must be created in us-east-1, while the application runtime and SES configuration for this project are in Sydney. Understanding these regional differences was an important part of getting the architecture working.

What we learned

This project gave me practical experience with several AWS services, but more importantly, it taught me how those services work together as one system. I learned that a simple product idea can become a distributed cloud application very quickly. Even a small time capsule application involves frontend delivery, API management, serverless compute, database storage, AI inference, scheduling, email delivery, authentication, HTTPS, and DNS. I also learned that AI integration is not just about calling a model. The quality of the result depends heavily on the prompt, the constraints, and the way the model output is incorporated into the rest of the application. Finally, I learned the importance of preserving user-generated data before applying AI transformations. By keeping both the original and AI-generated messages, the system can improve the writing experience without losing the user's actual words.

What's next for Dear Tomorrow

There are several features I would like to add next. The first is an AI preview step. Instead of automatically saving the AI-generated message, users could first see the transformed version and choose whether to use it, edit it, or keep the original. I would also like to add different AI styles such as: Warm and supportive Friendly Calm and reflective Inspirational Graduation congratulations Future-self letter Other future improvements include secure attachment uploads, user accounts, capsule history, stronger scheduling with event-driven services, and better monitoring for email delivery failures.

Built With

• acm
• amazon-cloudfront-cdn
• amazon-dynamodb
• amazon-ses
• amazonapigateway
• bedrock
• lambda
• route53
• s3