How to run a hackathon that results in a working MVP, and how AI fits into the process.
Manychat helps creators and brands automate conversations on Instagram, TikTok and beyond. The more the customer uses it, the richer the picture gets — automations running, leads coming in, content performing differently across posts. We wanted to surface that picture clearly, in one place, directly for the people running those automations.
We had the data. What we didn’t have was clarity on which features would actually be useful, and in what form. Instead of locking that question into a quarterly plan and finding out three months later, we decided to find out in a week.
Three people: two backend engineers, one PM, plus a data engineer who wasn’t full-time but was critical during the data prep phase. A couple of AI agents. Three days in the Amsterdam office, two days of remote prep. The output: an MVP running on real user data and seven customer interviews the following week.
My name is Artur, I’m a Python Tech Lead here at Manychat. Here’s what we learned from our hackathon experience — and where AI made the difference.
1. Start the hackathon before the hackathon
The first thing to sort out in advance is access. AI tools, repositories, internal documentation, relevant services. Permissions always take longer than you expect and can become a serious blocker mid-hackathon. Deal with it before you start.
The second thing is product hypotheses. We spent two days exploring data from our data warehouse. The internal documentation was a Google Sheets file with table and view descriptions — not exactly human-readable — and a data engineer who helped us navigate it. We packaged all of that as context, fed it to an LLM (Claude Code and the Claude desktop app), and asked it to find something productively useful for our customers. The PM turned those findings into clear product hypotheses, wrote the first PRD, and built early prototypes in Lovable — screenshots of which we later used as UI references during the hackathon.
The key point here isn’t that the LLM “invented” the product. It helped us quickly make sense of unfamiliar data and structure what we already intuitively wanted to validate.
2. Planning takes 80% of the time — and that’s fine
During the hackathon itself, we barely wrote any code by hand. Most of the time went to something else: figuring out exactly what needed to be done and formulating it precisely enough for an AI agent to execute.
Review the plan, not the code. The main insight from day one: the more precisely a task is defined for the agent, the fewer iterations you need. We used plan mode in Claude Code before every task, challenged the plan as a team, and saved it as soon as we were happy with it.
We didn’t review the code — but that doesn’t mean quality didn’t matter. Instead of code review, we validated the output with tests. What mattered wasn’t how it was written, but whether it worked correctly.
Save the plan immediately. Once, we had a great plan. We ran it, but the result wasn’t good enough. So we did what people usually do in that situation — /clear — to start fresh. The plan disappeared and with it, we wiped out some of the most valuable work along the way. We had to rebuild from scratch. After that, saving the plan became a mandatory step before any iteration.
Don’t ask for refactoring — reformulate. If the output isn’t right, don’t ask the agent to improve or fix what’s there. Reformulate the task, update the plan, and ask it to redo the whole thing. Especially when the context window is already half full — at that point, trying to patch the existing result only makes things worse.
3. Delegate coordination to AI-agents
If planning takes 80% of the time, the next challenge is turning that plan into a system of well-aligned tasks. This is where things usually start to fall apart: dependencies get lost, responsibilities overlap, and the overall structure drifts.
We found that delegating coordination to AI agents helped keep everything consistent. We created one sub-agent per direction. Each sub-agent was responsible for writing a detailed implementation plan for its part of the work. Once the sub-agents had their plans, a “parent” agent merged them into a single whole — and checked for conflicts, duplication, or blockers between tasks. This replaced a significant chunk of the coordination overhead between people.
The approach let a three-person team — one PM and two engineers — work in parallel and move fast. So fast, we weren’t quite ready for it.
4. Keep tasks as independent as possible
People should work in parallel on maximally different things. This is less obvious than it sounds.
On day one, the two of us split the backend by endpoints: one handler each. Seemed logical. We finished unexpectedly quickly and had to jump into another planning iteration — coordinating again, figuring out what’s next. With AI, this kind of split doesn’t really make sense: an agent closes a handler faster than you can get out of each other’s way.
The next day we changed the approach: each person takes a fully independent direction. One writes a feature end-to-end, the other handles infrastructure. Or one does backend, the other does frontend. For the latter, AI came to the rescue again: Claude Code with Figma via MCP let us assemble an interface from Manychat’s existing design system components — no frontend experience required.
While the engineers were building, the PM was running a parallel track: refining scope, defining the Ideal Customer Profile, finding customers who matched it, and tapping the marketing team’s existing warm contacts to line up interviews.
Parallelization didn’t go away — it just moved up a level. Instead of “two people on one module,” it became “each person owns an entire layer.”
5. Log your compromises
During an MVP hackathon, you’re going to make shortcuts. Intentionally. The goal isn’t to avoid them, but to make sure they don’t turn into hidden debt.
We kept a “Compromises” table and updated it as we went. Every deliberate technical or process shortcut got its own line. If the product validates, we have a concrete list of what needs to be brought up to production standards. Nothing gets forgotten, nothing quietly becomes permanent.
6. Stay focused on the original goal
When we saw how fast we were moving, we decided to add an unplanned feature: AI Summary. A short insight block generated on dashboard load — top post, best automation, overall account dynamics for the week. It wasn’t in the original plan, took half a day, and turned out to be one of the most talked-about things in customer interviews.
Then we got ambitious. Instead of showing the feature from a laptop, we decided to run a real experiment with a feature flag for actual customers. I took on the negotiations with infra and security so the team could keep shipping. Security didn’t approve it — and for a fair reason. Our solution was read-only, which made it safe in its current state. But the security team flagged that if any write operations were added down the line, the architecture would need to be revisited to account for that. They weren’t ready to approve this potential risk quickly, and we lost a person-day.
At the retro, the conclusion was simple: every new action needs to be validated against the original goal. The MVP was never meant for production in the first place. We just thought — we’re moving fast, why not? It worked for the unplanned feature. It didn’t work for the prod deploy.
What we ended up with
We shipped a working MVP analytics dashboard running on real user data.
The dashboard has three parts. At the top, an AI Summary : a short auto-generated insight about the last 7 days — total leads, DMs, comments, URL clicks, top-performing post with CTR, and one clear action to take.
Below that, Account Performance: four KPI cards — automations running, leads collected, average CTR, time saved.
And the main section: Top Content by Conversion — a table of posts ranked by leads, with reach, clicks, CTR, engagement, saves, and automation status. For creators who monetize on Instagram, the key question is always the same: which content is actually working? Not working in terms of likes — working in terms of leads, DMs, conversions. We wanted to make that visible at a glance, so they could double down on what’s performing and add automations where they’re missing out. Posts without automations show an “Add automation” prompt inline, and the customer can act on it without leaving the page.
The week after the hackathon, the PM ran seven interviews with real customers on their real data. Four said they’d use the dashboard regularly. We got a concrete list of what was missing and clear input for the next quarter’s planning.
In a normal cycle, development alone would take around two sprints — four weeks. User validation in larger companies can stretch for months: UX research queues, alignment meetings, synthesis. Here, it took three days to build and one week to get real customer feedback.
A fast MVP wasn’t even the goal. Reducing risk was. Instead of committing a full quarter to something that might not land, you validate the idea first, and then decide whether it’s worth investing in. The hackathon format makes this possible. A small team goes from hypothesis to a validated MVP in about two weeks.
AI changes the equation. Implementation becomes a non-issue: one engineer with a system of agents can cover what used to require a team. The bottleneck shifts. It’s no longer about writing code — it’s about knowing what to build. AI helps there too.
Want to be part of the team building Manychat? See what roles we have open right now.
Top comments (0)