About This Project
NowIGetIt takes scientific PDFs and transforms them into shareable, interactive web pages that explain the paper to a layperson. Upload a PDF, Claude reads the paper and generates a single-page HTML app, which gets published to S3 and served at https://nowigetit.us. The goal is making academic research accessible to anyone.
Status: Live at https://nowigetit.us Started: 2026-02-21
System Architecture
Layered architecture showing CDN, frontend, API Gateway, Lambda functions, AI models, storage, and configuration. The frontend S3 bucket serves both the static site and the generated HTML pages plus thumbnails under pages/. A separate ShareIt bucket is used only for temporary PDF storage during processing.
Upload & Generation Sequence
The 8-step upload flow: browser gets a pre-signed URL, uploads the PDF directly to S3 (bypassing API Gateway size limits), confirms the upload which triggers Haiku screening and Opus generation, then polls for the result. The whole process takes 30-60 seconds depending on paper length.
Project Inception
The idea was simple: take a scientific paper (PDF), send it to Claude, and get back an interactive web page that explains the paper to a non-expert. The initial implementation was built as a FastAPI backend with a vanilla HTML frontend -- no React, no build tools, just the simplest thing that works.
The core pipeline: upload PDF -> extract text -> send to Claude Opus 4.6 -> parse the HTML response -> publish as a public GitHub Gist on the jbdamask account. The frontend polls for status while processing happens asynchronously.
The initial scaffolding came together quickly as a local dev setup with FastAPI serving both the API and the static frontend.
AWS Deployment and First Bugs
Moved from local dev to AWS: CloudFormation template with API Gateway (HTTP API), three Lambda functions (upload, process, status), DynamoDB for job tracking, and S3 for both the frontend and temporary PDF hosting.
The first deployment surfaced a classic Lambda gotcha -- pip installs macOS binaries by default, but Lambda runs on Linux. Fixed by adding --platform manylinux2014_x86_64 --only-binary=:all: to the pip install in the deploy script. Also discovered Claude's API requires HTTPS URLs for documents, so switched the PDF hosting to use HTTPS S3 URLs instead of HTTP.
The GitHub token needed for Gist publishing required a fine-grained PAT. The only way to grant Gists permission is to also select read-only access to all public repos -- a GitHub limitation, not a design choice.
Streaming and Truncation Fixes
Hit the first real production bug: Claude's responses for complex papers were getting truncated. The HTML output was being cut off mid-tag. The root cause was that large responses weren't being streamed -- the SDK was buffering the entire response before returning it.
Switched to client.messages.stream() with text_stream iteration, which solved the truncation issue and dramatically reduced memory pressure on the Lambda. Also bumped max_tokens to 64000 to give Claude enough room for complex papers.
Progress Stages and UI Redesign
Processing takes 30-60 seconds, which felt like an eternity with no feedback. Added a progress stepper to the frontend showing four stages: Uploading PDF, Reading paper, Generating interactive page, and Publishing to web. The backend writes progress_stage to DynamoDB, and the frontend polls it to update the stepper.
Also redesigned the entire frontend. Went from a basic unstyled form to a dark-themed UI with DM Serif Display headings, ambient glow effects, grain overlay, and smooth animations. The drop zone supports drag-and-drop with visual feedback. It's intentionally moody -- makes the "aha moment" when you get the result link feel more satisfying.