What building an app with AI changed about how I lead in this era

For a while now, three friends and I have played fantasy cricket against each other for two rupees a point. Not the public contests with a fifty-rupee entry and a crore at the top, just the three of us in a group, settling up after every match by the margin between first and second. It sounds like nothing. It made me care about Virat Kohli's last five innings against Pakistan more than I have cared about most product roadmaps.

Two rupees a point

Winning a private game like that is not luck. You have to know who is in form and who is going through a rough patch, how a batter does against this opposition and at this venue, what the pitch is doing, whether the team bats first or chases, and where in the order each player walks in. Then there is the decision that settles most games: the captain and the vice-captain, whose points count double and one and a half times. Pick the right captain and you are first. Pick the wrong one and you are somewhere in the middle with everyone else. The person who wins is the person who did the homework.

The boring idea

My first product idea was the obvious one. Build a place where a model does the homework, reads the form and the conditions, and generates the team for you. I rejected it in an afternoon. If the model picks, every friend gets the same team, and the game dies the moment it is played.

The insight came from watching what people actually do when they build a team. They are not running a spreadsheet. They carry a story about the match. Kohli is in form, it is against Pakistan, he has two centuries in his last five, he is going to score big. The all-rounder will get overs because the pitch is slow. The keeper bats at four for this side. The team is the story, written out as eleven names and a captain.

So that is what Banter does. It captures your story about the match, then uses the data to pick the players who fit it, and it lets you test your story against your friends' stories once the match is done. I checked that the need was real before I built any of it. On YouTube there are whole channels where someone hosts a show before every match and tells you who to pick and why, with the form tables up on screen. Cricket already has its stock analysts. The homework was being done; it just had nowhere to live.

Built in the margins

Banter took seven months: a backend that ingests the data and scores the players, and an app that carries the story, the fixtures and the predictions. It is on TestFlight with a handful of friends. I built it around a demanding day job and a two-and-a-half-year-old, which is to say in the hours that used to go to sketching, and seven months is a long time to build anything now. I am telling you the shape of it so you can weigh what follows.

The loop that made it possible looks like this. I think about the problem hard, the way I always have. Then I let an agent grill me on it: the wayfinder and grill-with-docs skills in Claude Code take whatever context I give them and ask me question after question until I have either answered or admitted I do not know. By the end I have internalised the problem, not just described it. Then I ask Claude Code for a Figma mock as a starting point, refine it by hand in Figma, ask for a working prototype, take what I learn from the prototype back into Figma, and go round again. When I have no idea at all, I give it a little context and take whatever comes back as something to react to: keep it, take a direction from it, or throw it away.

The two Claude skills on this site came out of the same months, for the same reason: when a way of working is written down, an agent can hold you to it on the days you would not hold yourself.

What did not change

For most of my career I thought on paper. I would write the same idea five different ways until I latched onto it, sketch, and then go to Figma one screen at a time, hunting for the pattern that would make an interaction feel right. It was slow, and I assumed the slowness was the thinking.

It was not. The slowness was the translating. The thinking is the same as it ever was, and it is now the whole cost, because everything after it is close to free. A mock takes minutes. A prototype takes an afternoon. What you cannot buy is the insight that the model picking the team kills the game, or that people are already telling themselves a story about the match. That comes from caring about a problem enough to notice the hacks people use, the habits they keep, and what makes the good ones good. Depth on the problem matters more now, not less, because it is the only part the tools cannot do for you.

Depth needs a mechanism

That is the lesson for the team, and it does not survive on good intentions. I have written elsewhere about the quarterly intake and the kickoff that give my teams at Pine Labs and Setu a predictable shape (Six mechanisms that made a design team predictable). What is new is what has to happen between them.

Before any design starts, the designer runs a 5WH session with the product manager and the tech lead. Who is the customer? Why are they doing this? What is in it for the company? What are the constraints and the assumptions? What is the scope, and what platform is it on? It is a real exchange, not a form, and by the end of it the brief is ready and the scope is scoped. It is required. If it were optional it would happen on a good week and vanish in a crunch, and a crunch is exactly when a shallow brief costs the most.

Then, still before any design, the designer takes that context to an agent and lets it grill them on it, the same way I do. This is partly economy: a designer who has internalised the problem spends far fewer tokens later. Mostly it is depth. You cannot give an agent the right context until you have understood the problem yourself, and the grilling is how you find out whether you have.

Many directions, then one prototype

Once the problem is understood, the work opens up in a way it never could before. The designer makes one core screen in Figma and refines it by hand, because the hand is where taste lives. Then they ask for more: more mocks, more workflows, more directions than we ever had time to explore when every screen was drawn from scratch. Exploration used to be the first thing cut in a crunch. Now it is the cheap part.

When a direction has earned it, they build a high-fidelity prototype. At Setu the prototype has gone straight to the frontend team more than once, and the whole workflow has come back built from it. The prototype is the spec.

Try it

Banter is on TestFlight with a handful of friends, and if you like cricket and have an opinion about who should captain, I would like it to be in your hands too. Write to me at akashsoti@gmail.com and I will add you to the beta. Then tell me where the story breaks. It is a beta, so it will.

Shipping it was never the point. The point was finding out what the job is when the starting point is free, and it turns out to be the part I always liked: being obsessed enough with a problem to notice the story people are already telling themselves, and then building the kind of team where that noticing happens on a Tuesday, in a crunch, not only when someone has a good week.