Day #2 App Hackathon — AI Skills
Theme: AI Skills & Skill Sharing
Objective
Explore what an ecosystem for AI skills could look like, identify the highest-value direction, build an MVP in a single day, and document what was learned.
Context
The previous night we worked until around midnight finishing a release, writing a blog post, and wrapping up other company work. Rather than forcing another marathon session, we intentionally started later at 2:00 PM.
Before beginning we:
Finished outstanding work we ignored from the day before while hacking.
Walked Rosie and got outside for some sun.
Ate lunch.
Mentally reset from the late night.
We also made a conscious decision that this hackathon would end earlier than the previous night, even if that meant shipping less. Better decisions and consistency were more valuable than squeezing in a few extra hours.
Timeline
2:00 PM — Blue Sky
The day began with unrestricted brainstorming around a single theme:
AI Skills & Skill Sharing
The purpose wasn’t to decide on a product immediately. Instead, we wanted to maximize optionality by putting every interesting idea on the board before narrowing our focus.
Questions we explored included:
How should AI skills be shared?
How do people discover good skills?
How do people trust them?
How can skills improve over time?
What would make sharing skills genuinely valuable?
The emphasis was on quantity and exploration rather than feasibility.
2:35 PM — Choose a Direction
With enough ideas generated, we shifted from exploration to commitment.
Several promising directions were relatively straightforward to build, but we ultimately chose a more ambitious concept:
A platform where AI skills could be shared, benchmarked, arena-tested, improved, and trusted.
Looking back, this was probably the biggest strategic mistake of the day.
We chose one of the hardest possible implementations because it was intellectually exciting, rather than because it was the smallest path to delivering value.
The biggest source of complexity was our desire to prove that a skill deserved to be trusted.
2:45 PM — Target & Vision
Next we narrowed the audience.
Rather than trying to build something for everyone, we intentionally selected one primary customer.
Possible audiences included:
Developers
Designers
Finance professionals
Others
We chose designers.
Reasons included:
Balazs understands designers and their workflows extremely well.
Designers are increasingly becoming design engineers.
Developers already have many AI tools available.
Designers have more opportunity to benefit from reusable AI skills.
The product vision became:
Help designers confidently use AI skills by giving them confidence through examples, evidence, and proof that the skills are useful.
3:00 PM — Design Ideas
Once both the direction and target audience were chosen, we moved to the whiteboard.
We sketched:
Product flows
Landing pages
Skill browsing
Skill sharing
Public profiles
Benchmark concepts
Navigation
User experience
The goal wasn’t visual polish.
It was reducing ambiguity by committing to one coherent product direction.
3:11 PM — Break
We intentionally stepped away from work.
Lunch and a short break provided a mental reset before beginning implementation.
4:00 PM — Create the MVP
We converted the whiteboard sketches into actual interface designs.
The workflow was:
Photograph the whiteboard.
Import sketches into Figma.
Use Figma Make to generate UI concepts.
Iterate together until the product was concrete enough to build.
This phase focused on quickly increasing fidelity rather than polishing every detail.
5:08 PM — Pre-Development Review
Before writing code, we reviewed the implementation plan.
This included:
Choosing the technology stack.
Deciding how to divide the work.
Reviewing architecture.
Identifying dependencies.
Both of us agreed to build using:
Next.js
Vercel
During this conversation we noticed ourselves slipping into over-planning.
We were discussing every possible thing that could go wrong before we had written any code.
At that point we intentionally stopped ourselves.
One of the principles behind these hackathons is:
A hackathon exists to discover reality—not to perfectly predict it.
Instead of trying to eliminate uncertainty, we decided to begin building and let implementation reveal the real problems.
5:30 PM — Development
Development lasted roughly four and a half hours.
By the end of the session we had working versions of:
Authentication
Registration
Database
Marketing website
Branding
Core application
Initial deployment
The major feature that remained unfinished was the Arena.
As we built, it became increasingly clear that benchmarking AI skills was dramatically more complicated than expected.
The challenge wasn’t simply comparing outputs.
The real difficulty was deciding:
What should be measured?
Which scenarios mattered?
What constitutes quality?
How do you compare vastly different design tasks?
How do you ensure the benchmarks themselves produce meaningful value?
The number of possibilities grew exponentially.
Rather than continuing to expand scope, we intentionally stopped.
9:00 PM — Deployment
Development transitioned into deployment.
The next hour focused on getting the application into a working state.
This involved:
Deploying the application.
Fixing deployment issues.
Resolving bugs.
Ensuring interactions behaved correctly.
Matching the implementation to the intended user experience.
One principle carried over from the previous day’s work:
Light, but right.
An MVP shouldn’t contain unnecessary features, but everything that is present should behave correctly and predictably.
10:00 PM — Review
With a working deployment complete, we shifted into reflection.
The biggest insight of the day was that we had optimized around the wrong problem.
Originally we believed the value came from building an arena that could objectively prove which skills were best.
By the end of implementation we realized something much simpler.
Most people don’t ask:
“Can mathematics prove this is the best skill?”
They ask:
“Can you help me with this?”
In practice, people often trust the creator of a skill more than they trust a benchmark.
That realization suggested a significantly simpler product direction.
Instead of investing heavily in benchmarking infrastructure, we could focus on:
Sharing skills.
Making them easy to discover.
Keeping them automatically updated as creators improve them.
Ensuring everyone using a shared skill always benefits from its latest improvements.
That direction felt substantially more valuable while being dramatically simpler to build.
11:00 PM — Close
We intentionally ended on schedule.
Rather than continuing to add features, we stopped, documented what we had learned, and left with a clearer understanding of where the product should go next.
Primary Lessons
Explore broadly before committing.
Aggressively reduce optionality once a direction is chosen.
Pick a single customer before designing features.
Don’t mistake technical sophistication for customer value.
A hackathon is for discovering reality through building, not predicting every outcome beforehand.
“Light but right” is a better definition of an MVP than simply “minimum.”