Inspiration

PitchMirror came from a very specific frustration that I only understood after years of speaking experience.

I have been doing public speaking for most of my life. Since Grade 1, I was involved in declamations and speaking competitions. In middle school and high school, that evolved into Model UN and Parliamentary Debate. So by the time I entered university, speaking in front of an audience was already something I had spent years doing.

But then I stepped into startup environments, and the rules changed.

While studying at NYU Abu Dhabi, I started interning at a couple of early-stage startups. Even though my role was in software engineering, small teams naturally expose you to much more than code. You hear founder conversations, product discussions, investor-style thinking, and the way ideas need to be communicated when time and attention are limited. Around the same time, I also started working on a startup idea with a friend, and that is where the difference became impossible to ignore: being a good debater does not automatically make you a good pitcher.

Debating and pitching may both involve speaking, but they reward very different instincts. In debate, verbosity can be useful. Aggressive rebuttals can be useful. A certain style of body language, pacing, and argumentative intensity can help. In pitching, those same habits can become liabilities. A good pitch is not about overwhelming someone with words. It is about clarity, structure, confidence, pacing, and trust. You are not trying to defeat an opponent. You are trying to make someone believe in an idea.

That gap is what inspired PitchMirror.

The first version of the idea was actually much broader. I initially thought of building a generic public speaking coach. But the more I sat with the problem, the more I realized that public speaking was too wide and too vague. Giving good feedback for a speech, a classroom talk, a debate round, a startup pitch, and a sales presentation are all different problems. So I narrowed the scope and made the product much sharper.

PitchMirror became a coach specifically for pitches: startup funding pitches, hackathon demos, student presentations to school or university leadership, internal strategy pitches, and other moments where people need to communicate an idea clearly and persuasively under pressure.

That shift made everything click. The project stopped being a generic AI speaking tool and became a purpose-built system for a real communication problem I had personally experienced.

What it does

PitchMirror is a multimodal pitch-coaching web app powered by Amazon Nova.

A user uploads a short practice pitch video, optionally adds a transcript, chooses a coaching mode, and receives a structured report with feedback on how to improve. The report is designed to be practical rather than vague. Instead of just saying be more confident or improve your delivery, it highlights concrete issues, prioritizes top fixes, and suggests drills and a short practice plan.

The product currently supports three main coaching modes:

  • Audio coaching for voice delivery, pacing, and clarity
  • Camera coaching for on-camera presence and body language
  • Full pitch review for combined voice, presence, and content-aware feedback

The output is a premium-style structured coaching report that includes things like:

  • an overall summary
  • top fixes
  • voice feedback
  • presence feedback
  • content feedback
  • a short practice plan
  • metadata about whether AI and transcript evidence were used

What I like most about the product is that it is not trying to be a general public speaking assistant. It is intentionally focused on the specific communication demands of a pitch. That means the feedback is trying to answer a different question: not did you speak well in general? but did you communicate your idea in a way that would make someone trust it, understand it, and remember it?

That is a much more useful target for founders, students, hackathon teams, and anyone pitching an idea in a high-stakes setting.

How we built it

This was a solo student-built project, and I built the entire thing end to end.

On the product side, I built a polished landing page and a studio workflow where users can choose a mode, upload their video, optionally attach a transcript, start analysis, track progress, and view a structured report.

On the systems side, I designed PitchMirror as an asynchronous AWS pipeline rather than a simple synchronous upload and wait app. The architecture uses:

  • Next.js / React on the frontend
  • Node.js + TypeScript + Fastify on the backend
  • Amazon S3 for raw uploads and derived artifacts
  • DynamoDB for job state
  • AWS Step Functions for orchestration
  • ECS Fargate for the worker that handles media processing
  • Amazon Bedrock with Amazon Nova Pro for the multimodal reasoning layer

A big design principle behind the system was that I did not want the project to be AI or nothing. I wanted it to remain useful even when certain parts of the pipeline were unavailable or partial. So I designed it in layers:

  1. a deterministic baseline report built from preprocessing and lightweight metrics
  2. transcript-aware enhancement when textual evidence is available
  3. conditional Nova-powered reasoning when the mode and evidence support it

That fallback-first design became central to the product. I wanted the system to always return something useful instead of leaving the user at a dead end.

Another important technical decision was how to handle different kinds of evidence. Instead of treating the uploaded pitch as a single monolithic input, I split the analysis more deliberately: visual evidence for presence, audio-related evidence for voice, and transcript evidence for content. That made the system more controllable in terms of cost, latency, and reliability.

I also spent a lot of time thinking about the final report contract. One lesson I learned quickly was that structured AI output is an engineering problem, not just a prompting problem. The app needed a canonical report.json, a standard report fallback, metadata fields like analysis_mode, ai_used, and transcript_used, and a validation flow that could normalize or repair model output before showing it to the user.

In other words, the hard part was not only call Nova. The hard part was building the full system around it.

Challenges we ran into

The biggest challenge, surprisingly, was not the backend.

I am very comfortable with technical debugging. If something is broken in infrastructure, permissions, orchestration, or model integration, I usually know how to attack it: inspect logs, isolate the failure, read the docs, test assumptions, and keep narrowing the problem until the issue becomes visible.

Frontend design is different.

The hardest challenge for me was building a UI and UX that actually felt polished, intuitive, and comfortable to use. I am good at identifying user problems and solving technical ones, but I do not naturally have an eye for visual design. That meant I could build the logic of the product much faster than I could make it feel elegant. The landing page and studio experience took a lot more iteration than I expected because I was trying to create something that did not just function, but also felt premium and trustworthy.

There were also meaningful technical challenges along the way. One major pivot was around transcription. The earlier plan leaned on managed transcription, but that path became unreliable for this setup, so I had to adapt and move toward a bring-your-own-transcript flow instead. That was not just a quick patch; it changed how evidence entered the system and how content-aware analysis would work.

Another recurring challenge was making the asynchronous pipeline reliable. Orchestrated systems are powerful, but they also create more surface area for subtle bugs: state transitions, task configuration, permissions, artifact paths, validation, and fallback behavior all have to line up correctly. I also had to be careful with model behavior, especially when generating structured reports. Getting AI output to be useful is one thing; getting it to be consistently valid and safe to promote into the final report is another.

So the project pushed me on two fronts at once: technical systems engineering on one side, and product polish on the other.

Accomplishments that we're proud of

The accomplishment I am proudest of is that PitchMirror is not just a concept mockup. It is a real, working multimodal application with an actual backend pipeline, a real frontend, and successful end-to-end flows.

The system is able to take a user from landing page to studio, accept a video upload, optionally accept transcript input, launch an asynchronous job, process evidence through the pipeline, and render a polished coaching report in the frontend. That by itself already makes the project feel substantial.

I am also proud that I built the entire thing solo. That includes the product thinking, the AWS architecture, the backend orchestration, the report design, the frontend workflow, and the overall debugging and integration effort.

From an engineering perspective, I am especially proud that the system was designed with reliability in mind. Instead of treating AI as a magical black box, I built a layered pipeline with deterministic baselines, schema-aware report generation, canonical outputs, and fallback behavior. That means the system is much closer to something dependable than a one-off demo script.

I am also proud that I chose a sharper product direction instead of settling for something generic. Narrowing the app from a broad speaking coach into a pitch-specific coach gave it a much stronger identity and made the feedback more meaningful.

And finally, I am proud that this project pushed me beyond my comfort zone. I came into it with stronger confidence in systems and ML than in design, but I still pushed through the UX work until the app felt much more real and presentable.

What we learned

This project taught me a lot, both technically and personally.

The first lesson was about product clarity. A product gets much stronger when it is built around a sharper problem. Public speaking coach was too broad. Pitch coach was specific enough to shape better decisions across the entire stack, from UI wording to backend evidence handling to report structure.

The second lesson was about multimodal AI systems. Before this hackathon, I had not really explored Amazon Nova in depth. Through this project, I learned much more about how Nova fits into real multimodal workflows and how different modalities need to be handled deliberately rather than treated as interchangeable.

The third lesson was that model quality is only one part of the system. The actual usefulness of an AI product also depends on preprocessing, orchestration, output validation, fallback behavior, and presentation. In other words, intelligence is not enough on its own. It has to be delivered through a system people can trust.

The fourth lesson was more personal. I learned how much design matters. A technically impressive backend can still feel weak if the user experience is clumsy or visually unconvincing. This project forced me to confront a skill gap I do not usually think about as much, and that was valuable.

Finally, I learned a lot about AWS architecture through actually building rather than just reading. Designing around asynchronous jobs, storage layers, orchestration, and worker execution gave me my first real experience of what it means to build a backend system that has to coordinate multiple moving pieces reliably.

What's next for PitchMirror

The current version of PitchMirror already proves the core idea: multimodal AI can give people actionable feedback on how they pitch, not just what they say.

The next step is to make the system even more useful and more refined.

One direction is deeper personalization. Right now, PitchMirror gives structured feedback on a single pitch session. Over time, it could evolve into a real practice companion that tracks progress across attempts, recognizes repeated weaknesses, and adapts its drills based on a user’s history.

Another direction is richer content intelligence. Right now, the product already uses transcript-aware analysis when that evidence is available, but there is room to make the content side stronger: better story-arc detection, better identification of whether the pitch clearly communicates the problem, solution, proof, and ask, and better differentiation between different pitch contexts.

There is also room to improve the input experience. For example, supporting more flexible media flows, richer transcript support, and even more transparent evidence previews could make the product easier and more trustworthy to use.

And on the product side, I want to continue improving the frontend design and overall polish. Building PitchMirror showed me that a strong AI product needs both intelligence and presence. That applies to the user as a pitcher, but it also applies to the product itself.

At its core, though, the mission stays the same: to help people communicate ideas better and get feedback that is immediate, structured, and actionable.

PitchMirror is the tool I wish I had when I first learned that speaking well is not the same thing as pitching well.

Built With

Share this project:

Updates

Submission history