Before the train
gets home.

There is a boy on a suburban train somewhere right now with a phone full of net footage, one bar of signal, and no data left for the month. He faced maybe forty balls. Six of them were worth showing someone.

He has two options, and they fail him in opposite directions.

There are genuinely good video editors that run offline on the phone he already owns. They will cut, trim, slow down and caption anything he likes, on a train, with the radio off. What they will not do is find anything. Finding is his job — scrub the hour, spot the six, mark each one by hand. That is an evening's work, and the honest reason most net footage is never watched again is not that the tools are bad. It is that nobody does an evening's work twice a week.

The tools that will do the finding want the hour uploaded first. That is a forty-minute wait he will not take, over a connection he does not have, at a data cost he cannot justify, to a server that now has video of a child. Four separate reasons the answer is no, and only one of them is technical.

So the useful thing to build was neither of those, but the gap between them: do the finding for him, on the phone. Not privacy bolted onto a cloud product, and not another manual timeline — the two halves that each existing answer was missing, in one place. That single decision is responsible for most of what is interesting in this post, including the parts that went wrong.

What it actually does

You give it a video — a net session, a match, a throwdown session in a car park. It listens to the footage and watches it, works out where bat met ball, and builds a reel of just those moments. A DSP detection engine does the acoustic work, fused with a small on-device neural voice-activity model (Silero VAD) that tells a real crack apart from a shout, a footstep, or the net in the lane beside you. Optionally, a pose pass watches the batter as well.

Then it gets out of the way. You see the shots as cards, sorted best-first, and you keep or drop them with a tap. You set how long each clip runs and how long the whole reel should be. TokTok mode cuts everything to one-second stabs on the moment of impact, for the people whose reels live on a vertical feed.

The thing I would most like you to notice is what you are not asked to do. You do not scrub a timeline. You do not describe what you want in a prompt box and hope. The unit of collaboration is a single measurement — when and where the ball was struck — and if the app gets one wrong, you correct that one thing with one gesture and every clip, every effect and every caption downstream moves with it. I wrote a whole post about why that is the right unit: the anchor is the interface.

Why the phone, specifically

Cricket's centre of gravity is not in places with cheap unmetered bandwidth. It is in Mumbai and Multan and Colombo and Kampala, in school nets and maidans and turf wickets booked by the hour, on phones that are two generations old and plans that are counted in gigabytes per month. A tool that needs to upload an hour of 4K before it can be useful has quietly selected its audience, and it is not that audience.

A kid heading home from nets, on a train, with no data left, should be able to cut his own highlights before he gets off. If the architecture cannot do that, the architecture is wrong.

Holding that line has consequences all the way down. The models have to be small enough to ship in the app — under 8 MB of them, in a 74 MB download. The analysis has to be fast enough that nobody would have preferred the server queue. The rendering has to be cheap enough to run on a mid-range phone without cooking it. And the app has to be genuinely useful with the radio off, which is a much harder test than "works offline" usually implies.

Three things fall out of it for free, and they are the three that people care about most:

• Privacy is structural, not promised. Import, detection, selection, trimming and export all happen locally. Your footage and your reels are never transmitted to us, because there is no path in the code that would transmit them. That is a different kind of guarantee from a policy document. (The full privacy policy is honest about what does leave — an account if you make one, a feedback message if you send one, crash diagnostics. Never video.)
• It is free, and not in a way that has a catch waiting. A reel costs us nothing to produce, because your phone produced it. There is no GPU bill that has to be recovered from you later.
• It works where cricket is played. Basement nets, a ground with no bars, a train tunnel, a flight home from an away game.

The longer argument for why this is where computing is going — and why small specialised models beat one enormous general one for jobs like this — is in why the future of AI is small models on the edge and many small models working together.

The animations, and who they are really for

On top of the cutting engine there is an effects layer: twelve animated backdrop scenes, dozens of impact effects, sound, slow-mo, replays, a zoom that pushes into the batter. It is the part people screenshot. It is also the part most likely to be misread as decoration, so let me split it in two, because it genuinely serves two different people.

The bridge between the two columns is the point. A junior who plays a genuinely good cover drive in a suburban net has no natural route to anyone who might notice — no broadcast, no analyst, no clip desk. A reel that looks like it was cut by someone with equipment is not vanity; it is the difference between a shot that existed and a shot that was seen.

Why the animation work had to be testable first

Here is the engineering opinion the animation layer is built on, and it cost something to hold.

A renderer that draws into a canvas can only be checked by a human looking at a screen. A renderer that returns a picture — a flat array of pixels, a value you can hold — can be checked by a machine, thousands of times, across every framing, in a second, with no device attached. So eleven of the twelve scenes compute their own pixels in plain Kotlin rather than calling the graphics library, which by any graphics engineer's measure is the worse tool. The full argument, including where it is genuinely a bad trade, is in values, not side effects.

What that buys is the ability to ask questions no screenshot can answer. The one that matters most in this product is a safety question, and it is asked on every build:

Across every plausible batter position, height and framing — does any scene ever paint over the batter?

That is a property, not a picture, and properties can be swept. The suite now runs 1,043 tests across 109 files, and a large share of them are geometry sweeps of exactly that shape: hundreds of poses against hundreds of heights, per scene, asserting that the opening the batter plays inside never closes on them. None of it needs a phone.

And the honest limit of all that

Scene thirteen was a graffiti tiger's face on an orange wall under a sunrise. It was built, it was wired, it passed every geometry sweep, and it compiled clean. Then I put it on a phone and looked at it.

It looked like a mole.

Every layer was individually correct and obeying its own stated rule. Several marks had withdrawn for individually good reasons — and they happened to be exactly the marks that say tiger rather than small grey animal. The scene is parked. It is not in the app you can download, and it will not be until it survives the one instrument that had anything useful to say about it: a person, looking.

A constant is a hypothesis

Somewhere in this codebase is a number that decides how long a speed line is drawn. Somewhere else is the one that decides how much footage sits either side of a contact. There are hundreds of these, and every one of them is a claim about real cricket footage that could be wrong.

The tempting way to set them is to nudge one, rebuild, squint at the phone, nudge again. That is a two-minute build per squint, it does not scale past about four attempts, and — worse — it optimises the constant for the one clip you happened to be looking at.

So the constants get calibrated instead of chosen. The raw material is human-curated reference sets: real sessions where a person went through and said keep, drop, this window is wrong, this is the exact frame the ball was struck. That is ground truth, and once you have it, a constant stops being a matter of taste. You can sweep its whole range offline, score every value against what the human actually wanted, and read off which region is defensible — or discover that none of it is, and that the idea was wrong.

That last outcome is the common one, and it is the reason the method earns its keep. The colours on the speed lines are a small example: where one band ends and the next begins was set against human-curated footage, not chosen by eye — and the obvious way of measuring the same thing, the one I would have shipped on intuition, was refuted on that footage before a line of production code was written. The project keeps a graveyard file of these. Several things that sound excellent — and that I was personally sure about — are in it.

I am deliberately not walking through the signals themselves or what each sweep returned. Some of it is the part of this that took the longest to learn, and it can stay ours. The method is the part worth giving away.

Three workflows that made this possible for one person

This is a solo project. Roughly 165,000 lines of Kotlin and 391 commits since the end of May, built with AI agents doing most of the typing. Three loops are doing the real work.

1. Prototype in a browser, not in a build

Every scene exists first as a standalone HTML page with the geometry and animation in JavaScript. Iterating on a design in a browser costs a keystroke; iterating in a mobile build costs two minutes and a device. Get the composition right where it is cheap, then port. The prototypes are still in the repository beside their implementation notes — and one of the standing rules is that a prototype's numbers are evidence, never truth, because the rig and the phone disagree in ways that have burned us more than once.

2. Offline harnesses that render art without a device

Because the scenes return pixel arrays, a small Node harness can rasterise any scene at any framing and write out an image — no emulator, no phone, no Gradle. It also does something a render cannot: it counts. Every layer reports what it drew, so the harness can catch the failure mode a screenshot is blind to — a layer that drew nothing at all, which otherwise looks exactly like a layer that is behaving beautifully.

3. A different model for each step

Scene authoring runs as a pipeline, and the useful discovery was that no single model is the right tool for all of it. Each step goes to whichever model is best — and cheapest — for that specific job.

The step people skip is number three — asking a model to describe, in words, the image another model just made. It feels redundant. It is the step that makes the whole chain work, because a picture cannot be argued with and a description can: it is where "the wall is behind the batter and the opening is the tiger's muzzle" becomes a stated constraint rather than something everyone assumed.

Step five is where the cost discipline lives. The most capable model writes an implementation brief — the geometry, the invariants, the traps found in previous scenes — and a cheaper model then writes Kotlin against that brief. Doing the reasoning once, in prose, and reusing it is dramatically cheaper than paying a frontier model to re-derive the same geometry inside every code change. It is also better code, for the unglamorous reason that a specification someone can read is a thing a reviewer can disagree with.

The longer, messier account of building this way — including which agent wrote what, and the parts where they were confidently wrong — is in build with a genius, ship a machine and the ball doesn't read the docs.

You don't need a video to open the app

This started as a hedge and turned into one of my favourite parts of the product. Most people who download a cricket app do not have an hour of net footage sitting on their phone that evening. So there is a whole side of CricCuts that never touches a camera, and it works offline like everything else.

If you have ever wanted to actually understand the game rather than just watch it, that section is worth the download on its own. It is free and there is nothing in it trying to convert you.

Now please go and play

An app that edits cricket videos has an obvious incentive to want you looking at a screen. I would rather be straight about the ordering: the footage is only worth anything because somebody went and batted.

The case for playing is not really about cricket, and it is unusually well established. Sustained aerobic activity changes the brain's chemistry in ways that favour learning and mood — the effects on executive function in children and adolescents are among the more robust findings in the field, and they show up in attention and self-regulation, not just on a fitness test.

Cricket then adds things a treadmill cannot. It is an interceptive sport: a hard ball arrives in under half a second and you must predict where it will be, not react to where it is — the skill expert batters are measurably better at is reading the bowler's body before release. It is spatial: you are solving angles, gaps and field geometry continuously, in a three-dimensional problem that changes every ball. And it is one of the few games built entirely out of distinct roles — opener, spinner, keeper, the fielder at deep midwicket who touches the ball twice in an hour and has to stay switched on anyway. Learning to hold a role inside a team that needs you intermittently is a genuinely useful thing to have practised by the age of fifteen.

Pick up a bat. Pick up a ball. Find four people and a wall. The app will still be here when you get back, and it will have something to work with.

And when you do come back with footage, there is a real mechanism behind why watching it helps. Watching an action engages much of the machinery of performing it; your brain learns from the gap between what it predicted and what actually happened; and seeing your own body do the thing is a stronger signal than being told about it afterwards. That is the subject of an earlier post — the neuroscience of learning from watching yourself — which also has an honest section on which mistakes video actually fixes and which ones it does not.

What all of this is for

Every section above is really one decision, and put side by side they are the same four commitments. They are the reason CricCuts exists, and they matter more than any single feature in this beta.

• Technology for everyone. It is why the finding happens on the phone, why it needs no data plan, and why it is free. The boy on the train is the user this was designed around, not an edge case it happens to cover.
• Talent that gets seen. Good players are everywhere; the people who could notice them are not. A reel that looks like it was cut with equipment is how a good cover drive in a suburban net gets the recognition, and the feedback, it deserves.
• Coaches who reach further. An hour of footage reduced to the balls that matter, frozen on the frame that matters, gives a coach back the time to make a positive difference to many more budding players than an evening of scrubbing ever allowed.
• Sport in more lives. Which is why a video app just asked you to go and play.

Further out, the vision is bigger than an editor. We want CricCuts to become a new-age sports media platform, starting with cricket: one that empowers athletes and content creators to build a real livelihood through brand sponsorship, and that helps brands communicate effectively with the audiences they want to reach, through the players and creators those audiences already follow. Sponsorship in cricket mostly flows to the very top of the game. Someone whose game people genuinely want to watch should be able to earn from that too.

None of that is in this beta, and none of it will change the first promise: your footage is analysed on your phone, and what you share, and with whom, stays your call. The longer version is on the about page.

What "beta" means here, and what would help

The build is finished software, not a preview. "Beta" means it ships from this website while the Google Play listing goes through review — you are getting it early and directly, and you will need to allow installs from your browser the first time, which is standard for anything outside the Play Store.

• The cutting engine is the mature part. Months of measurement against real sessions. Start here.
• The effects layer is the young part. Twelve scenes, dozens of effects, and a hard job — landing on the right frame on footage it has never seen. Treat it as experimental and turn off anything that misbehaves.
• What is most useful to send: a shot it missed, a moment it picked that was not a shot, or an effect that landed on the wrong frame. Send it in from the app's feedback form and it carries the build and device details automatically. Every one of those becomes a test case.

Recordings from unusual angles are especially welcome. Nearly everything here was taught by footage that did not behave — a camera at the bowler's end, a net in the way, a phone that changed orientation halfway through. The failure you send me this week is what the next person's reel is built on.

Related reading: the anchor is the interface, values, not side effects, the neuroscience of learning from watching yourself, and how a phone watches cricket and cuts the highlights itself. More on the CricCuts blog.