A week ago, I was standing inside the Google London office, pitching a product our team had built in three days. We finished as finalists, Top 4 out of 26 teams. It’s the kind of result that sounds clean in retrospect. The build itself was anything but.
This one felt different. Not because of the outcome, but because of the problem we chose to work on.
Where it started
It came from something I was already living. A month before the hackathon, I’d written about how I automated my job application tracking with n8n, building a workflow to sync job listings across Google Sheets and Airtable because maintaining both manually was tedious enough that I kept skipping it. That post was essentially a confession: even with the tools to automate things, the process was still fragmented and still breaking down.
Job hunting as a student isn’t hard because it’s intellectually demanding. It’s hard because it’s scattered. Applications spread across tabs, spreadsheets, and email threads. Deadlines that slip because they were never in one place. The same form, name, phone number, degree, upload CV, filled out for the fortieth time. And the follow-ups that never happened because something else came up first.
Nothing in isolation is difficult. Everything together is exhausting.
At some point during that period, a clearer pattern emerged: students aren’t missing one tool. They’re using five of them. Tracking in a spreadsheet, finding jobs on LinkedIn, monitoring replies in Gmail, maintaining CV versions in Docs, trying to remember interview dates in a calendar. All disconnected. All manual. The workflow problem wasn’t any single step. It was the gaps between all of them.
Getting everyone on the same page
Having a problem you believe in is one thing. Getting a team to commit three days of their lives to it is another. Before you build anything, everyone has to actually be on board: not nodding along, but genuinely bought in. Onboarding your own team is the first product decision you make.
Ours started as something like a panel discussion. Everyone pitched their own idea of what we should build, and the ideas ranged across industries: finance, education, and the agentic ideas that float around every hackathon right now.
I was the advocate for this one, and I kept insisting on it. My argument was simple: as students, we were first-hand evaluators of this problem. We had lived it. That meant we would understand it better than any problem borrowed from someone else’s industry, and it would come through in what we built.
Five hours of discussion later, we decided this was the one. I’d managed to convince three more people to see it the way I did, and once they did, they were all in.
What we built
So instead of improving one step, we asked a simpler question: what if this was just one flow?
That’s what we built. Muesli, an AI-powered job application tracker that brings everything into one place. One view. No switching.
Apply less. Land more.
The people around it
One thing I didn’t expect going into this was how much the people around it would matter. We met mentors like Gabriela Giani Moreno and Daniela Gonzalez, who spoke honestly about what building actually looks like, the parts that don’t make it into the pitch deck. And Pam Sheemar, who came back after the semi-finals specifically to walk us through how we could improve. That kind of investment from someone who had no obligation to stay, it stays with you. It changed how I thought about the responsibility that comes with being on the other side of that dynamic someday.
What pitching taught me
Pitching at Google made one thing very clear: when time is limited and decisions matter, you stop overthinking and start seeing the problem for what it is. And more often than not, the problem isn’t complexity. It’s fragmentation.
We didn’t win. But we walked away with a product that feels genuinely worth building further, and a much clearer picture of what it’s actually trying to solve.
Originally shared as a short post on LinkedIn.