Internode Hackathon Day 01.
Day one of a one-week hackathon, and the lesson we should have learned two years ago.
This week we’re building a new product every day. Start in the morning, ship by midnight, then put it down and start over.
Not a prototype. Not a demo. Each day has to end with something a real person can install and actually use, with a name, a brand, and a website around it. If nobody can touch it, it doesn’t count.
The rules we set for ourselves:
One day per product. Nothing carries over to tomorrow.
The problem comes from a real user interview, not from a whiteboard and not from something we thought was technically interesting.
Cut until it hurts. Then ship whatever survived.
End to end, or it didn’t happen.
We’re also livestreaming all of it, and that wasn’t for an audience. It was for us. When people are watching, you can’t quietly let the deadline slip to tomorrow, and you can’t spend four hours polishing a thing nobody asked for. The camera is a forcing function.
As for why: we spent a long time building in exactly the opposite direction. A technological window would open and we’d move on it, then go looking for the user scenario that justified what we’d already made. What we got out of it was a large backend and a very advanced stack that made a lot of features possible and not one of them good. Every pivot after that was slow, because we were dragging a very large suitcase behind us.
So this week is the correction. Start with the user. Build the smallest thing that delivers value. Cut everything else. Find out you’re wrong early enough that being wrong is cheap.
This is day one.
The problem we picked
It came out of a user interview, not a whiteboard.
Founders and investors don’t want to collaborate in tools. That’s the whole insight. They aren’t living in Notion, Slack, and Linear. They’ll use the minimum number of products they can get away with, which usually means email and WhatsApp and nothing else. They’re not doing the day-to-day administrative or product work. They’re making decisions and maintaining relationships: investors, advisors, media, valuable connections, candidates.
Their real workspace is their inbox. And their inbox is a mess.
So: something that lives inside Gmail, reads across your threads, individual and group, and tells you which conversations actually need you today and what changed since you last looked. That’s it. No platform. No migration. No new place to log in.
You can start using Klear here.
Day one, hour by hour
9:00. The plan. An hour of ideation, then build.
10:00. The actual start. Setting up the livestream ate the first hour. We decided to stream the whole day, not just to document it, but to put ourselves somewhere uncomfortable. If people are watching, you finish.
10:00 to 11:30. Vision. We deliberately built something too big first, on the theory that it’s easier to cut than to expand. Notes went up on the walls and the windows. That became the backbone.
11:30 to 1:00. Break. Lunch. Sean went to the gym. Coming back fresh was part of the plan, not a break from it.
1:00. Sync. Hours allocated per task. Everyone aligned on the vision and the shape of the day.
1:00 to 2:00. The cut. Vision down to MVP. What is the one thing that delivers value end to end today? Not the product we want in six months. The product we can hand someone tonight. Our goal was never just a working app. We wanted the solution, the branding, and the site, packaged.
2:00 to 3:00. User flow and mockups. Before writing anything, we walked through the actual steps a person takes. Half on the windows, half starting to go digital. Visualizing the flow first makes it dramatically easier to hand off to an agent later, for design and for code.
3:00 to 3:30. Digitizing. Into Figma Make. We described the main pages and how they should behave, and we deliberately kept everything black and white. No color, no typography, no icons, no images. Wireframe only. UI goes on top later; it’s the cheapest layer to add and the most expensive place to get stuck.
3:30 to 4:00. Working prototype, shared between us, then pulled back into Figma proper.
4:00. Split. Sean took the product: frontend, backend, the extension itself. Balazs took branding, the website, and everything a user sees before they ever install anything. Hourly syncs from here on, so neither of us could drift.
6:00. Ping pong. Six hours in, and we were also running cameras and B-roll on top of the build. Documenting the process is real work. Treat it like work.
6:30. The name. More on this below.
7:30 to 8:00. Our planned deploy window. We missed it. This surprised nobody.
8:00 to 9:00. Basic version of the site and the product both standing up.
9:00 to 11:30. The unglamorous part. Bug fixing, optimizing the site, applying the brand: logo, color, packaging. We’re shipping an installable Chrome extension, so there’s a whole packaging step that doesn’t exist for a web app. We’d budgeted zero hours for this. It took two and a half.
11:30. End to end. Someone can install it and use it. Submitted to the Chrome Web Store, which takes weeks to a month, so for now people install it from a ZIP.
Is a ZIP install something a normal user will happily do? No. But this is a validation, not a launch. The question we’re answering tonight isn’t “is this the perfect interaction.” It’s “was the thing we heard in that interview real.”
About the name
We tried to get AI to name it. AI was terrible at naming it.
What worked was switching from utility to feeling. Not “email CRM.” Not what it does, but what it gives you. What we’re actually offering is clarity in a place that has none. So we started circling clear, spelled with a K, and got lucky: klear.work was available for three dollars.
Balazs turned the K into a logo, reversed, and doubling as two tracks converging into one line crossing a finish.
Here’s the part that still gets me. Our codename for the project all day was “Special K,” after the last initial of the person we interviewed to find the problem in the first place. We landed on K for Clear independently. The interview, the codename, the brand, and the URL all converged by accident.
Right, but light
Sean wrote a post a while back called Keep It Right-But-Light, and it’s the standard we were holding ourselves to all day.
You don’t want to be so minimal that nobody can see the value. You don’t want to go so deep into the value that you never ship a solution. Twelve hours, and we think we hit the balance, which is a sentence I could not have written about anything we built in the previous two years.
What we do next
If we come back to Klear, the order is fixed:
Go back to the original interviewee. The person with the overloaded inbox who described this problem to us. Do they want it?
Interview more power users in the same profile. Small teams, under ten and often under five, where everyone is squeezing every unit of productivity out of every hour.
Then, and only then, build. The candidates: writing email in the user’s own voice, richer contact and company context, pulling meeting transcripts into the interaction history, real design instead of wireframes, and getting through Chrome Web Store review.
Every item on that list is something we already know we can build. That’s exactly why it goes after the interviews and not before. Knowing you can build something is the most expensive reason in the world to build it.
What day one actually taught us
We spent two years asking what the technology could do. We spent twelve hours asking what a person needed. The second question produced something usable by midnight.
Nobody has ever opened a product and admired the backend. Users don’t care what’s underneath. They care what they get. The technology is a cost you pay to deliver value, and any part of it that isn’t delivering value is a suitcase you’ll be dragging behind you the next time you need to move quickly.
Build the thing someone asked for. Cut everything else. Find out you’re wrong by Tuesday instead of next year.
Day one is done. Six to go.
What’s the last thing you built because the technology made it possible?
You can start using Klear here.