---
title: "Building LookFlow: From a Moving Cursor to a Real Purchase"
slug: building-lookflow-first-real-purchase
summary: "LookFlow is now available to buy through Stripe. Building it with AI assistance took me from gaze calibration and a sandboxed Mac edition to signed downloads, trials, offline licensing and a real purchase. This is the website-launch story; the App Store release will get its own part."
tags: AI-assisted development, macOS, LookFlow, Mac App Store, Stripe, independent software
ai_model: Codex
published_at: 2026-09-13T20:29:17.495+00:00
canonical_url: https://jarkkolietolahti.com/articles/building-lookflow-first-real-purchase
markdown_url: https://cemecdwfdvdbvpvowuln.supabase.co/functions/v1/content-md?slug=building-lookflow-first-real-purchase
---

I wanted the mouse pointer to follow me when I looked from one screen to another. That became LookFlow, a native Mac app I am building with AI assistance. On 13 September 2026, I opened website sales through Stripe after making a real purchase and activating the delivered license. The Mac App Store route is still in preparation.

Getting there changed what I had to build. The repository now contains camera handling and calibration alongside payment verification, license delivery, download protection and refund handling. A small desktop utility has acquired a server because a successful payment needs to turn into something the app can trust.

## The first difficulty was knowing what the camera had understood

LookFlow uses the Mac's camera to estimate which monitor I am looking at, processing the images locally. After my gaze settles, it moves the pointer to that screen. I still use the mouse to reach a particular button or word.

I started with a MacBook Air M4, glasses, and a Dell display above the laptop. Calibration had to work with that arrangement and the way I actually sat at my desk.

On 9 September, the calibration instructions themselves were getting in the way. Reading text away from the target pulled my attention elsewhere. Moving it beside the target helped the layout, but it still distracted me. I replaced it with arrows between targets and quiet periods while samples were collected.

One later calibration classified all 164 collected monitor-validation frames correctly, yet movement stayed disabled because the separate head-still check failed.

The model relied enough on head pitch that an eyes-only glance downward did not reliably identify the laptop screen. On 13 September, I made that check diagnostic in Automatic mode instead of letting it block calibration. The gate needed to match how the app worked.

I explored the earlier development and measurement problems in [my Finnish article about the valley between an AI demo and a usable app](https://jarkkolietolahti.com/articles/ai-sovelluskehityksen-kuoleman-laakso). This article follows the next stretch: turning that app into something I can sell.

## The Store edition began with a small physical experiment

The fuller LookFlow app can also activate windows and remember window focus. Those features raised a distribution question. Apple's [macOS distribution comparison](https://developer.apple.com/macos/distribution/) lists App Sandbox as required for the Mac App Store, and distinguishes that route from distributing software with Developer ID.

I made a small sandboxed probe before committing to the Store version. It waited in the background, moved the pointer to the other display, and moved it back. A separate observer checked the actual coordinates. The active application remained iTerm. The probe also checked that sandbox restrictions were really active.

The successful experiment on 12 September gave me a practical feature split: a Cursor edition without the fuller app's window-control features.

Dragging was the next concern. The app must leave the pointer alone while I hold a mouse button. During a physical left-button hold lasting about 4.45 seconds, the app's final movement guard blocked 19 attempted moves and detected the release.

In the next short camera-driven trial, I calibrated the app and watched it make ten automatic moves, five to each display. It felt like the pieces were starting to work together.

## Two editions became three release configurations

The feature split is now Cursor and Direct. Cursor moves the pointer between monitors. Direct adds window activation, remembered focus and focus follows mouse.

Purchase channel is a separate choice. The source builds three configurations: Cursor for the planned App Store release, Cursor for the website, and Direct for the website. They share the Swift application and its core library. Build conditions remove window-control code from Cursor rather than leaving those controls hidden in its interface.

Licensing uses the same distinction. Each grant identifies its edition and purchase channel, and shared access rules decide which features it unlocks. The website verifies signed license documents; the StoreKit design feeds Apple's verified purchase evidence into those rules. Separate trusted keys keep sandbox and production website licenses apart.

## LookFlow Cursor reached TestFlight build 7

The App Store record is called LookFlow Cursor because the bare LookFlow name was unavailable. I needed a dedicated provisioning profile and installer signing identity to get the first manual export through.

Apple processed build 4 and I attached it to a private internal TestFlight group. By 13 September, I had uploaded version 0.1.0, build 7, along with screenshots and preview videos.

One of those updates addressed a modest UI problem: a countdown kept changing the height of the live status area, moving the cards below it. Reserving space for the progress bar and text made the layout stable while a move was counting down.

## Stripe confirmed a payment; LookFlow still had to deliver the app

The website work started in a separate Stripe sandbox. A test Payment Link used a one-time EUR 14.99 price with Managed Payments. That transaction used simulated funds. I later chose the same EUR 14.99 price for Direct and EUR 9.99 for Cursor in the live website offer.

Stripe's [fulfillment guidance](https://docs.stripe.com/checkout/fulfillment) calls for checking payment status on the server and handling repeated fulfillment calls. A customer's browser reaching a confirmation page cannot be the only evidence that a license should be issued.

The LookFlow service runs in a Cloudflare Worker. It verifies the Stripe event, checks the expected purchase, and records the order and delivery task together in D1. It then creates a signed license that the Swift app can verify. Duplicate events must leave one purchase with one grant. A delayed payment must wait for success.

The first complete sandbox run connected payment, Stripe webhook, database record, protected license download and Swift verification. A full sandbox refund then revoked the order and blocked another download with the original code.

Refunds raised another question: what happens to a license already saved on an offline Mac? Blocking another download would not reach that copy. I added automatic signed checks, then had to decide what a failed check should mean for someone who had paid.

## Delivery exposed problems that payment tests could not

The license email needs to get the customer to the correct app and explain activation. The sandbox flow used a separate activation code on a protected download page, with the server choosing the package from the license's edition. The public launch also makes trial downloads available; the installed app verifies the license before granting paid use.

I signed and notarized the website packages and checked the downloaded copies with Gatekeeper. The early builds used sandbox licenses; production needed its own packages and trust key.

The first hosted download check found an ordinary integration bug: the asset service returned a streamed response without a Content-Length header. The handler had assumed that header would be present. I fixed the handler and added a regression test. The correct ZIP had been sitting on disk all along; the delivery code was what failed.

Email delivery took the work beyond the download endpoint. I needed the message to arrive in an inbox with usable installation and activation instructions. An emailed test code worked; the next step was to put a real purchase through the whole path.

## A paid license should survive a server outage

I wanted trials and automatic license checks in place before opening sales. I also wanted to be able to give a previous trial user another attempt while preserving the earlier trial's history. Both became part of the licensing implementation.

The free website trial lasts 14 days and includes Direct features. It starts when the user explicitly chooses Start trial after email verification. It needs no payment card and never charges automatically. Recovery and reinstallation keep the original expiry; an operator-granted second attempt is a separate allowance.

Paid offline use prompted a more important change. An earlier proposal would have required a successful online validation within 30 days. I asked what would happen if the licensing server was unavailable. A person who had bought the app could eventually lose access because my service was down.

I chose indefinite offline use for activated paid licenses instead. The app still checks online periodically, but a timeout or server failure leaves access intact. Only a valid signed revocation for that license removes it. First activation and lost-code recovery still need the service, and trials retain their original expiry.

This has a deliberate consequence: a refunded copy that remains offline can continue working until it receives the signed revocation. I accepted that tradeoff to keep outages from locking paying users out. It changed both the app's access rules and the signed validation protocol, followed by another signed and notarized release build.

The published [purchase details](https://lookflow.jarkkolietolahti.com/purchase/) now describe that behavior. A licensing policy becomes meaningful when the software and the offer agree about what happens on a bad day.

## I bought Cursor before opening the shop

The production release was version 0.1.0, build 108, for Apple Silicon and macOS 14 or later. I signed and notarized both editions and checked the downloaded archives against their release hashes.

Before public launch, I made a real EUR 9.99 Cursor purchase through Stripe Managed Payments. The signed webhook created the production license grant. The activation email arrived in my inbox with the download link. I activated that license in the production Cursor app, restarted it, and checked that the license remained unlocked and its automatic startup check succeeded.

For Direct, I used a production gift license to check activation and window-control access, then checked its public checkout route.

My Cursor purchase checked the sales machinery. It was not an independent customer sale.

## Website sales opened on Sunday evening

At about 21:45 Helsinki time on 13 September, I enabled both payment links and published the Buy buttons at [lookflow.jarkkolietolahti.com](https://lookflow.jarkkolietolahti.com/).

The website offer is EUR 9.99 once for Cursor and EUR 14.99 once for Direct, with tax included in those euro prices. Direct includes the cursor features and adds window control. Both checkout routes were opened from the public site and showed the expected edition and price. Customers can download the app and try it on their own desk before buying.

Country settings took longer. I initially wanted to restrict sales to Stripe Managed Payments' tax-coverage list, but the proposed rule was unavailable with Standard Radar and the payment-method scope needed clarification. I sent the question to Stripe Support and chose to launch while awaiting its response. The country restriction remained unenforced.

I will reconcile fees and proceeds when the separately aggregated Managed Payments charges arrive.

## Now I need to find buyers

The shop is open. Now I need to find out who experiences enough friction moving between screens to try LookFlow and pay for it.

My first audience hypothesis is people who repeatedly switch between Mac displays, including those who already use a cursor shortcut. Their current workaround gives me something concrete to compare against. Calibration, camera use and everyday reliability have to earn their place in that workflow.

The App Store release is still in preparation and will get its own short third part. Marketing, advertising and customer results will follow as I do that work. For now, [LookFlow is available to try and buy](https://lookflow.jarkkolietolahti.com/). I have taken the app from moving a pointer on my desk to accepting a payment and delivering a working license. The next question belongs to the buyer: is it useful enough to keep?