Postforge

← Back to projects

Tech stack

React / Typescript / Next.js / Express

Supabase + Drizzle ORM / Supabase auth

ngrok during development

Building Postforge

Postforge was built for a public school in NYC who wanted to increase their social media presence by posting more often. The principal receives dozens of photo emails each day from teachers and parents. To create a single post, she had to open every email, go through each attachment, choose a photo, download it onto her phone, upload to instagram and finally write a caption.

I worked directly with the principal to identify the core features PostForge needed: email ingestion, image dashboard, and caption generation.

What was hard?

Handling real-world photo attachments + volume turned out to be the main difficulty I faced. During end-to-end testing I faced problems such as:

• HEIC/HEIF photo formats not being renderable
• Inconsistent photo orientation
• overwhelming Claude's token limits
• variable API costs for large batches
• Failures of image upload/processing.

Each part of the pipeline had to be idempotent, observable, and resilient to retries, because email ingestion and AI post generation turned out to be rather failure-prone in production.

Product decisions

In designing Postforge, my main goal was to respect the principal's on-the-go, mostly mobile and email-based workflow.

I realized she didn't need another dashboard of decisions, but to reduce friction + decision making as much as possible. I made a few key decisions to support this:

• Tap to share on iPhone: I served base64 images instead of png links. This avoids the extra step of downloading/screenshotting images before posting.
• Making the dashboard optional: manually choosing pictures would be easy compared to before, but the principal will be able to post even if she never logs in.

The solution here was the email digest: at the end of each school day, a cron job sends that day's images to Claude for caption generation, and ready-to-share posts will arrive directly in her inbox each evening.

Architectural flow

1. Teachers and parents send photos to a dedicated email on the school's domain.
2. All emails get forwarded to a webhook hosted on Postforge's server.
3. The server processes the photos.
   • Images in non-renderable formats like HEIC or HEIF get converted to PNG;
   • Fix image orientations
   • Resize large images
4. Processed photos are uploaded to a Supabase Storage bucket as PNG urls.
5. When a user clicks "Get Today's Posts," PNG URLs are batched sent to Claude.
   • Batching allows large photo dumps can be processed without overwhelming the API.
   • Some batches can succeed even if others fail.
6. On the frontend, images are served as base64 urls so that users can long-press to share to Instagram.

Deployment and Handoff

The app is not available for public use because it's been white-labeled for the school. I worked with the IT coordinator to host it on their own domain and accept pictures using custom email addresses.

In Closing

I learned that even "simple" software can become really complex in production when you're handling formats, limits, retries, API failures, UX edge cases, etc. Getting to MVP is the easy part. After that, there's a seemingly infinite amount of engineering to be done to cover all possible failure modes. I really had to prioritize.

I only have a limited amount of time and resources to build this and wish I could have polished it up more, but the principal is happy, and Postforge saves her time every day. Win! :)