I Built 80% of an AI Video Generation Platform as a First-Year Intern & Here's What I Learned

Sambhavi — Fri, 02 Oct 2026 14:35:29 +0000

When I joined Plumo AI as a Software Developer Intern this summer, I expected to contribute to a small feature or two. What actually happened was that I ended up building the entire frontend in Flutter, roughly 80% of the NestJS backend, and integrating a multi-agent AI pipeline that connected Whisper, ElevenLabs, HeyGen, and the Instagram Graph API into one coherent system. This post is about what that actually looked like, not the polished version, but the real one.

What we were building:

Plumo AI is a B2C platform under which I was building this product that automates AI driven video content creation. The pipeline works like this: a user uploads or links a video, a transcription agent extracts the audio and converts it to text using Whisper, a voice replication agent recreates the voice using ElevenLabs, a video generation agent produces the final video using HeyGen and then the content gets published automatically via the Instagram Graph API. Each of these is a separate agent with its own input format, output format and failure mode. My job was to build the frontend that users interact with, the backend services that coordinate all of this, and wire the agents into a single working pipeline.

The first real problem: making frontend and backend actually talk

The hardest part wasn't any single agent. It was making the Flutter frontend, the NestJS backend and the agent layer all work together continuously without the flow breaking down somewhere in the middle. In theory, the architecture is clean, user action triggers a backend call, backend triggers the first agent, output flows to the next. In practice, every handoff point was a potential failure. The user authentication and account activation flow was particularly painful because it sat at the entry point of everything, if the session wasn't established correctly, none of the downstream agent calls would work either. Getting the full flow from sign-in through to a completed agent pipeline working end to end required debugging across three different layers simultaneously, which is something you cannot really prepare for by reading documentation.

The second real problem: agents that work individually but break together

Each agent worked fine in isolation. The transcription agent handled audio correctly. The voice replication agent produced accurate output when given clean text. But when I connected them, things broke in ways that were not obvious. The transcription agent would succeed and return its output in one format, but the next agent in the pipeline expected a slightly different structure, different field names, different nesting, different handling of edge cases like silence or background noise in the audio. When the extraction was working but transcription was failing, or vice versa, the error messages were often misleading because the failure was happening at the handoff between agents, not inside either agent itself.

What fixed it was building explicit validation at every handoff point. Before passing output from one agent to the next, I added checks that verified the response was in the expected format before the next agent tried to consume it. This sounds obvious in retrospect but when you're building a system this way for the first time, you assume the agents will just work together because they each work individually. They don't.

What I actually learned

The clearest thing I took away from this internship is the difference between building something that works and building something that keeps working as the system grows. When you have one API call in a project, error handling is simple. When you have five agents in sequence, each calling external APIs with their own rate limits, latency and output variations, the failure surface is completely different. A failure in agent three doesn't look like an error in agent three rather it looks like agent four returning nothing useful.

I also learned that system integration is its own skill, separate from knowing the individual technologies. I knew Flutter, I knew NestJS, I had used APIs before. But knowing each piece didn't automatically tell me how to make them work together at scale. That understanding only came from actually hitting the problems like the inconsistent formats, the session flow breaking, the agent pipeline dropping state in the middle and solving them one by one.

What's next

If I were to do it again, I'd build explicit contract tests between agents from day one rather than discovering format mismatches after connecting them. I'd also instrument every agent handoff with structured logging from the start, because when something breaks in the middle of a five step pipeline, knowing exactly what each agent received and returned is the only way to debug it efficiently.

For anyone building multi agent systems for the first time: the agents are not the hard part. The contracts between them are.

Why My Finance Dashboard Has Two Backends (And What Broke When I Deployed It)

Sambhavi — Tue, 16 Jun 2026 08:00:43 +0000

I built a personal finance dashboard to help people keep track of their expenses. Here's why I split it into two backends, and the CORS issue that taught me more than the rest of the project combined.
This finance dashboard is really helpful for users to keep track of their expenses. All you have to do is add your budget for your needs, that's it, you can relax now. When you start spending money, just let the finance dashboard know where and how much you are spending. Take a look at the finance dashboard at the end of the month to see where you spent the most and where you saved money. This product helps people be more careful and aware of their spending. It is mainly for young people who are just starting to spend their own money.
The Architecture
The finance dashboard has two backends: a Node and Express server that handles adding expenses, deleting them, and setting budgets, and a Python and FastAPI server that handles all the analysis and chart data. Both backends connect to the same MongoDB Atlas database.
I chose to use two languages because each one is good at different things. Node and Express are great for simple tasks like adding an expense or deleting an entry i.e. things where you want it to happen quickly and don't need a lot of computation. Express handles this with minimal overhead.
The analysis part is different. To see how much you spend each month, how much you spend in each category, and how your budget compares to what you actually spent, you need to look at all the data, group it by category and month, and do some math. This is what Python is good at i.e. looking at data, grouping it, and doing math.
If I had built this project entirely in Node, I would have had to write a lot of extra code to do the analysis. If I had built it entirely in Python, the simple tasks would have been more complicated. So I split it into two backends. Each one does what it's good at.
The downside is that I now have two servers to manage, which means two deployments, two sets of environment variables, and a connection between them that I have to maintain. This is the cost of my decision, and I want to be clear about it.
How They Talk to Each Other
The React frontend talks to both backends directly. When you add an expense, it goes to the Node server. When you look at the analysis, the pie chart or the line chart, it goes to the FastAPI server.
Here's how it works: when you add an expense, the React form sends a request to the Node server, which writes it to the MongoDB Atlas database. Then the frontend asks the FastAPI server for the updated analysis, which looks at the data, does the math, and returns the updated chart data. The two backends never talk to each other directly. They only share the database.
The Biggest Challenge — CORS
The biggest challenge wasn't the analysis or the simple tasks. It was getting the frontend to talk to both backends after deployment. When I was testing it on my computer, everything worked fine. When I deployed it, the frontend on Vercel, the Node server on Render, and the FastAPI server on Render as a separate service, each on a different domain, the browser started blocking requests because of CORS.
To fix this, I had to configure CORS on both backends separately. On the Express server, I added the cors package and specified which origin was allowed to make requests. On the FastAPI server, I did the same using FastAPI's CORSMiddleware.
What made this harder was that I had to debug two problems instead of one. If a request failed, it could be because of the Node CORS config, the FastAPI CORS config, or both. The fix that worked was being explicit i.e. only allowing the exact deployed frontend URL on both servers from the start.
What I'd Do Differently
If I were to start over, I would focus on CORS from the beginning and make sure both the Express server and the FastAPI server are configured correctly before deploying. This would make the deployment process smoother and avoid the back-and-forth debugging across both servers.

Live Demo: https://finance-dashboard-eight-ashen-75.vercel.app/

GitHub: https://github.com/sambhavi0/finance-dashboard

DEV Community: Sambhavi

I Built 80% of an AI Video Generation Platform as a First-Year Intern & Here's What I Learned

Why My Finance Dashboard Has Two Backends (And What Broke When I Deployed It)