Not Quite My Tempo
‘Deploy’
As I deployed the launch-ready commit of Commute Impact Calculator, I felt a strange calmness. For months, I was burning the midnight oil (tokens too), spending all the weekends day & night building the tool. It’s weird because I underestimated the effort it takes even when building this fully with AI tools. Partly because I have learnt not to trust what’s in the frontend. I used to sit all night and watch Opus on Max implement a large plan in inline execution, so that I can keep seeing the stream of changes it makes in code because I can understand code.
Even after deciding ‘GO’, I had so much self-doubt, fear of judgement that I kept doing code reviews, security reviews and methodology reviews for weeks. I just wanted some assurance.
Once the tool was launched, a new fear took over. It’s the fear of breaking things that are not broken. I now have a baseline. And I can’t afford to ruin this. So I got ten times picky with backlog prioritization. I slowed down the TEMPO of building. It was at this point I also wanted to go back to a normal sleep schedule.
By now, I already have identified the most common recurring tasks. So I thought how would a small startup run the OPs and I wrote the first principles and JDs for the roles I would have if I had a team with me. Then I gave it to Claude and I asked it to create them as agents and wire them together for weekly sprints workflow. Every week I run /sprint once and we are good for a deployment on Sunday.
Meet my team. In the actual code they’re just roles with briefs. No personalities, no movie references. But there’s one with a real personality and he gets his own section.
The board advisor (my Alfred Pennyworth). I wish I was Batman. SIGH. Board advisor agent is responsible for stopping me before I rush things and take bad bets due to temporary emotions. When I get excited about a shiny new feature, or a fourth city before the third has earned its place, he is the one asking whether I have actually thought it through. He never touches the product itself; his job is to question my judgment about it.
The co-founder (Han Solo). A counterpoint to the board advisor above. He is the one who looks at any small idea and immediately sees it running in ten cities and paying for itself (cries in tokens…). He makes the big, slightly reckless bets and waves off the risks (”never tell me the odds”), and that’s exactly why the board advisor sits in the next room.
The growth PM (Gollum). He has one job, whether people come back and share their commute scorecard, and he guards it like his one true possession. Anything that does not move that number, he treats as a distraction from the precious. He is also responsible for prioritization. But TBH, I keep overruling him most of the time.
The SEO lead (Saul Goodman). He owns the reason most people find us at all. When someone types “Bengaluru traffic today” into Google at nine in the morning, we want to be the first honest answer they get. Better call Saul. He is currently updating his LinkedIn profile with AEO, GEO, LLMEO etc.
The design head (Miranda Priestly). She guards the look and feel, so that your result is something you might actually screenshot and send to the family group. Her standards are withering and entirely non-negotiable, and there are a few things (design tokens, certain colours, certain shapes) you simply do not bring into her office. I mean context window :-)
The engineer (Q). The one who actually builds the thing, quietly assembling the working kit the rest of us depend on. Like Q handing Bond his gadgets, he expects all of it to come back in one piece, and he will tell you plainly when something is not ready to ship. (Where’s my Aston Martin, Q?)
The methodology steward (Hermione Granger). She has done the reading so the rest of us do not get caught out. If a number sits on our public methodology page, she can tell you exactly where it came from. Rules are rules.
The tester (Dwight Schrute). The man himself. The gate. Nothing reaches the live site without his sign-off, and he seems to enjoy withholding it. He treats a clean build as a drill he gets to run on the rest of us.
The release engineer (Winston Wolfe). He shows up when production is on fire, stays calm, and puts it out. More often than I would like, the fire is one I started while dealing with multiple PRs.
The project manager (Nick Fury). He assembles the team and keeps the single backlog everyone actually trusts, the only one allowed to write in it. When it is time to decide what we build this week, he is the one who calls everyone in and gets the whole group pointed in the same direction. /sprint gives him anxiety.
The city builder (Indiana Jones). When I get excited about adding a new city, he does the digging it needs and runs the whole launch to the same standard as the last one. Yet to test this agent. Dubai next?
Terence Fletcher. The journalist we hired to embarrass (whiplash?) us before a real one could. He gets his own section in a moment, which is exactly how he would want it.
In my initial launch post(linked below), I mentioned that eleven agents were working on the upcoming releases for Commute Impact Calculator. But I have now hired someone new too. He is the one I am excited to write about.
Chennai drives alone. The calculator goes global.
This tool deals with massive amounts of numbers, constants, and variables. The problem? I suck at math. While building this, my only defense mechanism was psychological warfare: I kept threatening and manipulating Claude, warning it that journalists and governments would someday spawn in to audit everything it built.
The code itself is private. The public numbers and the methodology behind them are the only things anyone outside can actually check. If a feature has a visual bug, I can quietly fix it by Tuesday and most people will never notice. But if a single calculation turns out to be invented? The trust is gone. And that does not come back.
This anxiety was constantly looping in the back of my mind until I stumbled upon a Terence Fletcher meme. It struck me immediately that I could build a journalist agent, but bake Fletcher’s terrifying, ruthless psyche directly into its prompt.
He has zero tolerance for “good enough.” If the engineer’s work or content delivery doesn’t match his exact internal standards, he will recommend stopping the entire release until it is perfectly on his tempo. So, before a real journalist shows up and ruins us, I hired him to do it first behind closed doors.
A typical ‘Fletcher’ run looks like this. Some new line is about to go up on a city page. Before it ships, Fletcher reads it the way a hostile reporter would and writes the takedown, claim by claim. This sentence says X; where does X come from; does the source it points to actually say X, or just something close enough to sit next to it. Every claim gets a plain verdict of defensible, misleading, or unsupported. After that it is less a debate than a rule: either an agent or I can defend the number with a real, public source, or the number changes before anyone outside ever sees it. Fletcher cannot stop a release, that part is Dwight’s job, but he makes sure that whatever I do ship is something I can say out loud and stand behind. He is adversarial in the way a good editor is, the kind who improves your piece by trying to pull it apart, instead of the kind hunting for a reason to look clever at your expense.
Once Fletcher was in, Sprint meetings got better and interesting. Once a week, the project manager opens the backlog, gathers input from other agents and shapes a plan small enough that I can actually ship it over a single weekend. I either approve it or I do not, and from there the work moves through the team until the tester signs off and the release is clean. One week, one deploy, one gate, and it looks like I can now finally get a good sleep.
I should be honest here I think. The reason why I am doing all this is simply to learn how to work with AI agents. My own product is probably the safe place for me to do so too. The agents are just weeks old and I have a feeling all of this will look naïve or dumb to me in a few months. Some things might definitely break. I might burn too many tokens. (For example, never run deep research skill in Opus 4.8 without guardrails. It will happily spawn 100s of agents with web search via Dynamic Workflow and eat up all your session limits.)
One last confession. Fletcher read this post before you did, and flagged exactly one line as unsupported: that I can finally get some good sleep. His evidence was my own writing. The sprint gives my project manager anxiety. The fires Winston puts out are usually ones I started. And a few lines down, I admit I will probably burn too many tokens and break things I cannot yet picture. The verdict was fair. I am publishing it anyway, because I want to keep believing the part about the sleep for a little longer. There is something humbling about hiring your own worst critic and losing to him inside your own post.
The Commute Impact Calculator is live at commuteimpact.com, now for Chennai, Bengaluru and Metro Manila. Go measure your own commute, and tell me what you think.