---
title: "LookFlow IV: A JamBau Hackathon That Became a Product"
slug: lookflow-iv-jambau-hackathon
summary: "This weekend, I worked on LookFlow during a hackathon at JamBau Oy. I retraced the journey through Codex and Claude records, Git history and physical tests: from a pointer moving between screens to an app people can buy, and the work that still needs a human."
tags: LookFlow, JamBau Oy, hackathon, AI-assisted development, macOS
ai_model: Codex; Claude consulted for historical research
published_at: 2026-09-14T05:34:23.866+00:00
canonical_url: https://jarkkolietolahti.com/articles/lookflow-iv-jambau-hackathon
markdown_url: https://cemecdwfdvdbvpvowuln.supabase.co/functions/v1/content-md?slug=lookflow-iv-jambau-hackathon
---

This weekend, I worked on LookFlow during a hackathon at my company, JamBau Oy. I wanted the mouse pointer to move to the screen I was looking at. I built it with Codex and Claude, and kept going until there was a native Mac app, a website and a working purchase path.

For this fourth article, I went back through the agent conversations, their saved memories, Git history and the notes from physical tests. The record captures a substantial amount of activity, but it is not a timesheet for the company hackathon.

The interesting part is how the work changed once moving the pointer was no longer the only problem.

## The first request had a useful limit

The first saved request already contained ideas for choosing applications and focusing the window I would probably use next. It also contained a smaller instruction: “MVP move cursor from monitor to monitor”.

That limit gave the experiment something concrete to do. I had a MacBook Air, an external Dell display above it, and glasses. The app needed to distinguish those two destinations using the camera. Moving to a particular word or button could remain my job with the mouse.

I also suggested “glance and nod?” as a possible confirmation gesture. It was a reasonable thing to try at a desk. It immediately raised practical questions: when should the destination be selected, and could the nod itself change the estimate? The design latched the destination before the nod began.

Even this small interaction contained a product decision. Looking somewhere and intending to act there are different events. A useful app needed a way to manage that difference, and a convenient way back when it got it wrong.

## The calibration instructions became part of the bug

One of the earliest problems came from the interface around the measurement. The app asked me to look at a target while also giving me text to read elsewhere. Moving the text beside the target improved the layout, but I still found myself reading it instead of looking where the calibration expected.

I asked for arrows between targets and quiet periods during sampling. The next version also improved continuity when the face detector produced confusing results. A later calibration classified all 164 monitor-validation frames correctly, while a separate head-still check still kept movement disabled. That score described one calibration, not everyday accuracy.

This was a useful hackathon lesson because it was so ordinary. A result that looked like a camera or estimation problem also involved where the instructions sat and what I did while reading them. I could not get that information by asking an agent to inspect another function.

The following morning produced a different failure. The camera preview showed my face, but tracking remained stuck without a selected face. The app had kept the previous face rectangle indefinitely. Returning in a different position could leave me outside the area where it was willing to look for me.

The fix preserved continuity during a short interruption and allowed stable reacquisition after a longer loss. Recorded geometry made the failure reproducible in a test. Sitting back down at the desk had supplied the case that the first implementation was missing.

## Claude's UX work led back into development

I asked Claude to review the running app as a UX designer and provide concrete changes. Its saved record begins with that work: reorganising setup, making Pause persistently visible, clarifying live status, and moving detailed diagnostics out of the main path.

Before the large rewrite, I asked for a Git commit. That became the repository's first commit. The earlier prototype work was already inside it.

The subsequent review was more useful than a general verdict that the interface looked better. Some actions were truncated. Diagnostics could exceed the screen. A speed control displayed a selected delay without making the additional learned delay equally clear. I pasted the other reviewer's findings into Claude's session, where they became concrete fixes. At that point, I was also the link between two agents reviewing the same native window.

Preparing the App Store preview videos found another bug. I asked for a recording showing both screens, with enough visual context to make the monitor changes understandable. While watching the usage video, I noticed that the progress bar appearing during a countdown made the layout jump.

That had passed earlier inspections. Recording an explanation of the product exposed it. The fix reserved space for the countdown instead of moving the cards below it whenever progress appeared.

The preview video was supposed to be a release asset. It became another test of the app.

## Parallel agents needed explicit boundaries

As release work progressed, the work split into parallel tracks. Claude was working on the interface, Store builds and presentation material. A separate Codex session was building the website and direct sales path. Codex had also handled the earlier prototype work, physical-test investigations and specialist reviews.

The split helped, but both agents could touch the same repository. I told Claude that another session was working on the website so unfamiliar edits would have an explanation. Its saved memory records that instruction.

A shared checkout makes coordination visible in mundane ways. An unexpected diff may be another agent's unfinished work. A release note may describe a newer build than the one a different session has open. Taking a baseline commit before a rewrite and recording which track owns which work became practical ways to avoid undoing progress.

The distribution work also changed the shape of the product. The narrower Cursor edition moves the pointer between displays. Direct adds window activation and remembered focus. Those became separate capabilities within a shared application, with Cursor prepared for both the Store and the website.

I covered the payment and licensing implementation in [the website-launch article](https://jarkkolietolahti.com/articles/building-lookflow-first-real-purchase). From the hackathon perspective, the significant change was the growing list of things a buyer would need: a download, installation instructions, a trial, a license, recovery and support information.

The cursor movement was now one part of that list.

## The records show activity, not person-hours

I asked Claude for its own evidence-based account and compared it with the saved transcripts and Git. I also counted the local agent usage records, stopping immediately before the request to write this retrospective.

| Recorded activity | Count |
| --- | ---: |
| Git commits, including the initial baseline | 57 |
| Codex sessions | 5 main sessions and 9 specialist sessions |
| Claude sessions | 3 |
| Agent input tokens | 391.6 million |
| Agent output tokens | 1.18 million |
| Share of input tokens served from cache | 97.6% |

These are records attached to the LookFlow working directory. They include development, testing, release work, reviews and writing about the project. Work recorded elsewhere is outside this count.

The token total needs some explanation. Agents repeatedly receive earlier conversation and working context. Most of the recorded input here came from cache. The output count is much smaller, and output includes reasoning, prose and tool calls as well as code. Hundreds of millions of tokens do not mean hundreds of millions of tokens of new software.

The calculation also avoids counting the same usage repeatedly: Codex provides cumulative session counters, while Claude can repeat one response's usage across several transcript entries. I took the final cumulative count for each Codex session and deduplicated Claude responses by message ID.

I would not turn this table into a claim about human hours, a productivity multiplier or an invoice. Git begins too late to describe the early prototype work, agents can run in parallel, and a conversation can remain open while I am doing something else. What I can reconstruct is the sequence of work and the points where my intervention changed it.

## My work kept moving toward decisions and physical feedback

The records contain plenty of implementation, but the recurring human contribution is more specific: deciding what should happen and trying it at the desk.

I reported that calibration text distracted me. I noticed that switching in one direction felt different from switching in the other. I wanted a quick return that did not teach the app that every return meant a mistake, so Go back and learning Undo became separate actions. I watched the preview video and caught the moving layout.

Later, the decisions became commercial. For an activated paid license, I wanted continued offline use through a server outage. That meant accepting the tradeoff that an offline copy could also keep working after a refund until it received a signed revocation. An agent could implement either policy; choosing the one I was willing to offer customers was my responsibility.

This is the part of the journey I want to remember at JamBau. The agents made it possible to pursue implementation, review and release work across several tracks. I still needed to supply observations they could not obtain from source code and make decisions that a successful build could not settle.

## Opening checkout changed the next question

By the end of the weekend, website sales were open. My own real-money purchase had already travelled through payment, license delivery, activation and a restart of the app. That established the purchase path; it was not evidence of independent demand. The App Store release remains a separate part of the story.

Work continued after checkout opened. The same evening brought a website release with single-window navigation and permission-recovery improvements, followed by work on signed updates. A shipped app immediately gives you an installed version to maintain.

There is another job now: finding people who want it. A working checkout makes a sale possible. It does not explain who has this problem often enough to pay, how to reach them, or whether they keep using the app after trying it.

Marketing, ads and actual buyer discovery deserve their own follow-up, with results. For this retrospective, I can say that a JamBau hackathon project reached the point where someone could buy it. The next part of the journey needs people outside the build process.