← Projects

WrapItUp

2024

Event-driven microservice on AWS that lets users record and transcribe voice messages and receive LLM-generated summaries on a React frontend.

WrapItUp cover

Problem

Inspiration often strikes at the most inconvenient time — like while driving. In that moment there’s not much you can do to hold onto the thought: pulling over just to write a note usually isn’t possible, using your phone while driving is illegal, and recording a voice memo the normal way is still inconvenient enough that the idea slips away.

Solution

WrapItUp is an application that records your spoken thoughts and summarizes them for later reference, so capturing an idea takes no more effort than talking.

Provider & Technology Evaluation

The system runs on commodity cloud components for authentication, persistence, and application logic — storage, a database, serverless functions, and an API gateway — provisioned as Infrastructure as Code so the setup stays resilient and easy to replicate. On top of that sits an API layer for transcription and summarization, powered by external AI models.

To keep tech-stack complexity and integration overhead low, we deliberately stuck to a single cloud provider for the commodity pieces: AWS, chosen for its adoption rate, and used both for the infrastructure itself and for IaC via the AWS CDK — accepting the tradeoff of vendor lock-in. For the AI models, though, we didn’t want to limit ourselves to whatever AWS offered. After careful evaluation, OpenAI’s ChatGPT-4o and Whisper came out as the best fit, with the added benefit that their free-tier APIs let us validate the idea quickly and revisit the model choice later once the concept was proven out.

Obstacles & Learnings

Serverless turned out not to mean structureless. It’s a genuinely different architecture style, and it surfaced real friction: sharing libraries across Lambdas was awkward, logging became distributed and harder to trace, and using JavaScript in the Lambdas turned out to be a bad call.

Mixing stateful and stateless resources in the same stack was also a mistake — deployments got slower and slower as stateful resources, including manually created test data, piled up. We fixed this by splitting stacks into stateless and stateful groups, which introduced a new problem of its own: circular dependencies between the two.

The last lesson came from working as a team of four in one shared environment. Developing in parallel meant stepping on each other constantly — deleting someone else’s resources, accidentally removing authentication, overwriting each other’s implementation mid-test — and deployments simply didn’t hold up over an unstable connection. The fix was to move development local-first, and only deploy once things were stable.