Call a bank’s customer support number today and something strange happens.

The smartphone in your hand can display maps, stream video, authenticate payments, translate languages and run sophisticated apps.

But the moment you make a customer-support call, it effectively turns into a telephone from the 1990s.

“For credit cards, press 1.”
“For savings accounts, press 2.”
“For loans, press 3.”

You listen.
You wait.
You try to remember which number corresponded to which option.
You press one.
Then another invisible menu begins.

There is no screen showing you where you are. No navigation tree. No way to scan the available options. No obvious way to know whether the thing you’re looking for is one level deeper or buried somewhere in another branch.

Thirty years after Interactive Voice Response systems became commonplace, we’re still navigating them largely the same way.

The problem isn’t the IVR.

It’s that the IVR is still invisible.

IVRs Actually Solve A Useful Problem

Large companies receive enormous numbers of customer calls.

A bank can’t send someone calling about a fraudulent credit-card transaction to the same queue as someone asking about a home loan. A telecom company needs different specialists for billing, connectivity, prepaid accounts and enterprise customers.

IVRs solve that routing problem.

They gather information about why you’re calling and place you into the appropriate queue.

The problem is the interface we’ve chosen for doing it.

The company already has an information architecture that might look something like this:

Banking
→ Credit Cards
→ Savings Accounts
→ Loans
→ Investments

Choose Credit Cards:
→ New Card
→ Existing Card
→ Lost or Stolen Card
→ Payments
→ Rewards

Choose Payments:
→ Payment Failed
→ Payment Not Reflected
→ Billing Question
→ Speak To An Agent

That’s a perfectly reasonable menu.

But instead of showing it to you, we convert the menu into speech and reveal it one item at a time.

Which is a remarkably inefficient way to navigate information.

Imagine If Every Interface Worked Like An IVR

Imagine opening a shopping website and instead of seeing its navigation menu, hearing:
“For electronics, press 1.”
(pause)
“For clothing, press 2.”
(pause)
“For home and kitchen, press 3.”

And after choosing Electronics, hearing:
“For televisions, press 1.”
(pause)
“For mobile phones, press 2.”

Nobody would tolerate it.

Visual interfaces work because humans can scan information.

We can look at five options simultaneously, identify the relevant one and tap it almost instantly.

Audio interfaces force information to arrive sequentially.

You can’t hear option 5 until options 1 through 4 have finished playing.

And because the menu is invisible, you don’t know what lies underneath each choice until you enter it.

So navigating an IVR becomes a peculiar exercise in patience and memory.

India Makes The Mismatch Particularly Obvious

India is a useful place to see how outdated this interaction has become.

The country had 1.348 billion telecom subscribers as of June 2026.

And voice isn’t disappearing simply because digital channels have grown.

A 2026 Truecaller–Tata Tele Business Services study conducted by Kantar across 17 Indian cities found that 76% of consumers preferred speaking with businesses over the phone rather than relying entirely on digital channels.

At the same time, India is overwhelmingly becoming a smartphone country.

Government data published in 2025 found that 85.5% of Indian households had at least one smartphone.

Put those facts together and you get a strange technological contradiction -

Millions of people are calling businesses from touchscreen computers capable of displaying extraordinarily rich interfaces, yet the customer-support system behaves as though they’re calling from landlines.

We have put a screen in almost everyone’s hand and then designed the phone call as though the screen doesn’t exist.

The IVR Should Simply Appear On The Screen

Nothing about the underlying customer-support operation needs to disappear.

The customer still calls the same phone number.
The call still travels over the regular mobile network.
The company can keep the same IVR logic.
The same queues can exist.
The same customer service agents can answer them.

But when the call connects, the IVR appears on the phone screen.

Instead of hearing:
“For credit cards, press 1. For savings accounts, press 2...”
you see:
How can we help?
→ Credit Cards
→ Savings Accounts
→ Loans
→ Investments
→ Other
Tap Credit Cards. Immediately:
Credit Cards
→ New Card
→ Existing Card
→ Lost / Stolen Card
→ Payments
→ Rewards
Tap Payments. Immediately:
Payments
→ Payment Failed
→ Payment Not Reflected
→ Billing Question
→ Speak To An Agent

Three taps.
Five seconds.
You’re in the right queue.

The audio IVR can still exist for people using feature phones or anyone who prefers it.

But the smartphone gets an interface designed for a smartphone.

And You Should Always Know Where You Are

Making the menu visual solves another problem that we’ve become so accustomed to that we barely notice it.

IVRs have no geography.

Once you’re three levels deep, you usually have little idea where you are within the system.

A visual IVR could simply show:
Home → Credit Cards → Payments → Payment Not Reflected
Want to go back?
Tap Payments.
Want to return to the beginning?
Tap Home.
Want to explore another branch?
Go there.

The information architecture already exists.

We’re simply allowing the customer to see it.

The Waiting Room Should Become Visual Too

Reaching the right queue only begins the second archaic part of the customer-support experience.

Waiting.

Today you usually hear some combination of:
“Your call is important to us.”
“All our representatives are currently assisting other customers.”
“Your estimated waiting time is approximately seven minutes.”
Perhaps, occasionally:
“You are number three in the queue.”

Then the music starts again.

A visual call interface could instead continuously display:
Credit Card Payments
Queue position: 3
Estimated wait: 7 min

Suddenly you know exactly what’s happening.

As agents become available:
Queue position: 2
Estimated wait: 4 min

Then:
Queue position: 1
Estimated wait: 2 min

The customer no longer has to rely on occasional verbal announcements to understand the state of something the contact center already knows.

And Nobody Should Have To Stay On Hold

Once the contact center knows that your expected wait is seven minutes, there is another obvious question.

Why does the call need to remain connected for those seven minutes?

The screen could simply offer:
Estimated wait: 7 minutes
1 → Stay On Call
or
2 → Call Me When It’s My Turn

Choose the second option and the inbound call ends.
Your position in the queue doesn’t.
The screen now says:
Status → You’re still in the queue.
Estimated callback: 9:42 PM

Use your phone normally.

When your position reaches the front of the queue, the contact center system places an outbound call to you and connects you to the appropriate agent.

From the customer’s perspective, the conversation starts roughly when it would have started had they spent seven minutes listening to hold music.

Except they didn’t have to spend seven minutes listening to hold music.

None Of This Is Science Fiction

The interesting thing is that almost every component of this experience already exists.

Google’s Direct My Call on Pixel phones already converts automated phone menus into tappable choices on the screen. On supported businesses, Google can sometimes display menu options before they’ve even been spoken.

Google also offers Hold for Me, which can monitor a call while you’re on hold and alert you when a human returns.

Apple introduced a similar Hold Assist capability on iPhone in 2026.

Meanwhile, major contact center platforms already support virtual queues and automated callbacks.

Systems from companies such as NICE and Genesys can let customers disconnect while preserving their position in the queue, then automatically initiate an outbound call when an agent becomes available.

And an entire category of products already calls itself Visual IVR, although many implementations take the customer out of the call and into a web interface delivered through an SMS link.

So this isn’t primarily a technology problem.

It’s an integration and standardization problem.

In Fact, We’re Already Doing Something Slightly Absurd

Google’s Direct My Call illustrates this beautifully.

A company’s contact center already knows its IVR structure.
It knows that pressing 1 leads to Credit Cards.
It knows the options underneath Credit Cards.
It knows which queues those choices eventually lead to.

But because the phone network doesn’t expose that structure visually, the company converts the information into speech.

The speech travels through the telephone network.

Then Google’s software listens to that speech and attempts to reconstruct the menu so that it can display the information visually again.

Think about that pipeline.

We are turning structured data into audio so that another computer can turn the audio back into structured data.

The cleaner architecture is obvious.

Send the structured information alongside the call.

India Could Be A Great Market To Build This For

There’s another reason this could be particularly useful in India.

Language.

The RBI Ombudsman’s contact center received 927,598 calls in FY2024–25, up nearly 29% from the previous year. More than 60% were handled through IVR. But only about 7% of those calls were in English. The overwhelming majority were in Hindi or regional languages.

Think about the difference a visual interface could make.

At the beginning of the call:
Choose your language
English
हिंदी
ಕನ್ನಡ
தமிழ்
తెలుగు
मराठी
বাংলা
...

Choose Kannada and the entire IVR tree appears in Kannada.

The caller can read the options at their own pace instead of listening carefully for the relevant choice in a sequence of spoken announcements.

In a country with hundreds of millions of smartphone users and enormous linguistic diversity, that isn’t merely a convenience.

It’s better interface design.

Don’t Replace The Phone Call. Upgrade It.

There is a temptation whenever we encounter an old interface to replace the entire system:
→ Move customer support into the app.
→ Move everything to chat.
→ Move voice onto the internet.

But sometimes the better product isn’t a replacement.
It’s a layer.

India has repeatedly demonstrated how powerful that approach can be:
→ Cash didn’t have to disappear before digital payments could become dramatically better.
→ Bank branches didn’t have to disappear before mobile banking transformed banking.
→ And telephone calls don’t have to disappear before customer-support calls become digital.

Keep the phone number.
Keep the cellular call.
Keep the contact center.
Keep the IVR routing.
Keep the agents.
Just let the screen participate.

Because in 2026, the strangest thing about calling customer support isn’t that we’re still using the telephone.

It’s that we’re using a smartphone as though it doesn’t have a screen.

Make The Call Screen Smarter

To telecom operators, smartphone makers, operating-system developers and contact-center platforms:

All the pieces we need to build this already exist.

Build a common standard that lets businesses send their IVR menus, navigation paths, live queue information and callback options directly to the screen during a regular phone call.

Don’t replace the call.

Make it visible.

Build This Next.

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

Every driver knows this feeling:
Google Maps says “11 hours”… and then gives you one long blue line.

No sense of velocity.
No sense of progress.
No sense of where you’ll be after 1 hour, 3 hours, 7 hours.

Just… blue.

Google Maps solved navigation.
But it still hasn’t solved something more basic:
situational awareness while moving through time.

So here are two simple toggles that should already exist inside Google Maps.

1. Color by Average Speed (Not Just Traffic)

A new map layer: speed heatmaps

Today’s traffic colors (blue / orange / red) tell you congestion.
But congestion is not the same as actual movement.

Two roads may both be “red”, but on one you crawl at 6 km/h and on the other you still manage 35 km/h.

That difference matters.

The missing toggle

“Color route by average speed per segment.”

Instead of vague traffic density, Maps would show precise movement patterns:

• 0–10 km/h → dark red (near gridlock)

• 10–30 km/h → orange

• 30–60 km/h → yellow

• 60+ km/h → green/blue (free-flowing)

Two modes:

A) Live Average Speed

Based on what cars are actually doing right now.

B) Historical Average Speed

Based on time-of-day + day-of-week patterns
(“Fridays at 6 pm”, “early morning on weekdays”, etc.)

This turns your route into a speed heatmap, not just a traffic mood ring.

You immediately know:

• Where you’ll crawl

• Where you’ll cruise

• Where you need alternate routes

• Where to mentally prepare for pain

A tiny toggle.
A massive clarity upgrade.

2. Split Long Trips Into Time Segments

If Maps says 11 hours, show me those 11 hours.

If your drive is long, Maps currently shows it like a single monolithic journey.

But planning a long trip is actually about understanding time.

You want answers to simple questions:

• “Where will I be after 2 hours?”

• “What’s the half-way town?”

• “Where will sunset hit me?”

• “Where do I plan fuel, food, and breaks?”

Today, you do all this manually, mentally approximating based on the blue line.

That shouldn’t be necessary.

The missing toggle

“Split route into hourly segments.”

If the trip takes 11 hours, Maps would auto-split your path into:
Hour 1 → Hour 2 → … → Hour 11

Like chapters of a journey.

Each with a small label:

• 1h

• 2h

• 3h

• …

• 11h

Even better: show ETA at each marker.

“ETA here: 10:40 am”
“ETA here: 12:05 pm”
“ETA here: 3:20 pm”

Dynamic too — if traffic improves or worsens, the hour-markers shift automatically.

What this gives drivers

• Instant clarity on break planning

• Much better night driving decisions

• A real sense of progress on long drives

• Better coordination with co-travelers

• Realistic expectations for families with kids, elderly, or pets

This is the kind of feature that feels obvious in hindsight.

From Routes to Journeys

Both features rely entirely on data Google already has:

• Speed telemetry

• Historical traffic patterns

• Route segmentation

• ETA calculations

No new sensors.
No new hardware.
Just better organization and visualization.

These two toggles would transform long drives from:

“A single 11-hour blob”
to
“A clear, time-aware, speed-aware journey map.”

Google Maps changed how we navigate.
Now it’s time to change how we understand our movement through space and time.

If someone at Google sees this:

Build This Next.

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

I was reading the plot summary of a movie on Wikipedia recently.

A few paragraphs in, I realized I was spending more effort remembering who everyone was than understanding what was happening.

“Michael betrays David, who had earlier warned Sarah about Alex, while Emma discovers...”

Wait.
Who is Michael again?
Was David the police officer?
Or the brother?
And who was Sarah?

At that point, I wasn’t reading a plot summary anymore.

I was solving a memory puzzle.

The problem is that Wikipedia assumes readers can keep a mental map of every character name while reading.

In reality, most of us don’t remember characters by name.
We remember faces.
We remember actors.
We remember visual cues.

We think:

“Oh, that’s the guy from the poster.”

“That’s the actress who played the sister.”

“That’s the villain.”

Not:

“Ah yes, that’s Inspector David Smith, son of Robert Smith and brother of Sarah Smith.”

Wikipedia already has all the information needed to solve this problem.

Every movie page contains the cast list.

Every actor already has a profile page.

Most actors already have photos.

Yet the plot section remains a wall of text.

The fix is surprisingly simple

Instead of forcing readers to use character names, Wikipedia could let them choose how they want people to be represented.

Imagine a simple toggle at the top of every plot summary:

Characters | Actors | Faces

The plot itself never changes.

Only the representation does.

In Characters mode, you would see:

Michael betrays David, who had earlier warned Sarah about Alex, while Emma discovers...

In Actors mode, you would see:

Harrison Ford betrays Tom Hanks, who had earlier warned Emma Stone about Matt Damon, while Anne Hathaway discovers...

And in Faces mode, the names would simply be replaced by small headshots embedded directly within the sentence.

The story remains identical.

The cognitive load changes dramatically.

You no longer need to keep scrolling back to the cast section.

You no longer need to open multiple tabs.

You no longer need to remember six names introduced ten paragraphs earlier.

The plot becomes easier to follow because humans are fundamentally visual creatures.

The goal isn’t to add information. It’s to reduce the effort required to process information.

Even better: use actor photos instead of character names

Here’s the counterintuitive part.

In many movies, I know the actor far better than the character.

I may not remember Dr. Richard Kimble.
But I definitely remember Harrison Ford.

I may not remember Captain Miller.
But I definitely remember Tom Hanks.

For many readers, the actor’s face is actually a stronger memory anchor than the character’s name.

That’s why the toggle matters.

Different people remember different things.
Some remember characters.
Some remember actors.
Some remember faces.

A good interface should accommodate all three.

A small headshot often communicates more information than the text beside it.

This doesn’t stop with movies

The same problem exists everywhere.

TV series.
Anime.
Books.
Historical events.
Political timelines.
Corporate histories.

Whenever an article contains multiple people, readers are forced to build a mental lookup table of names.

Visual references dramatically reduce that cognitive load.

Imagine reading the history of a company acquisition and switching between:
Names | Job Titles | Photos

Or reading a political scandal and switching between:
Politicians | Parties | Faces

The article becomes easier to understand without becoming longer.

Why this matters

Most product improvements don’t come from adding information.

They come from reducing friction.

Wikipedia has spent decades solving the problem of information availability.

But there’s still a huge opportunity to improve information usability.

Because sometimes the difference between understanding a story and abandoning it halfway isn’t the quality of the writing.

It’s simply being able to remember who’s who.

And for humans, faces are often a far better index than names.

Maybe the future version of Wikipedia won’t just tell us what happened.

It will help us keep track of the people it happened to.

The Opportunity

Wikipedia already knows who every character is.

It already knows which actor played them.

It often already has a photo.

The missing piece isn’t information.

It’s presentation.

A simple toggle between Characters, Actors, and Faces could save millions of readers from repeatedly jumping between the plot section and the cast list.

And sometimes, that’s all great product design is:

Making information easier for humans to understand.

If someone at Wikipedia sees this:

Build This Next.

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

A few days ago, I took a photo of my car.

The photo looked great.

The lighting was right. The angle was right. The background was right.

There was just one problem.

My license plate was visible.

Now I had a choice:

• Share the photo and expose a personal identifier.

• Open another app and manually blur it.

• Draw a black rectangle over it like it was 2007.

• Or simply not share the photo.

For something so common, the workflow feels surprisingly primitive.

And that’s strange because Google Photos already understands almost everything else in the image.

It can identify faces.
It can identify pets.
It can identify locations.
It can identify objects.
It can identify text.
It can even suggest edits automatically.

Yet one of the most obvious pieces of personally identifiable information in a photograph is still treated as if it doesn’t exist.

Every car owner has the same problem

Cars have become increasingly personal.

People photograph them when they’re new.
They photograph them after modifications.
They photograph them during road trips.
They photograph them after detailing sessions.
They photograph them when selling them.
They photograph them because they’re proud of them.

But almost every one of those photos contains a license plate.
And unlike a random tree in the background, a license plate is directly tied to a specific vehicle.

Many people are uncomfortable sharing it publicly.
Not because they’re paranoid.
Because they prefer a little privacy.

The same way people often blur house numbers.
Or hide phone numbers.
Or crop out sensitive documents.

The intent isn’t secrecy.
It’s simply reducing unnecessary exposure.

The current solutions are terrible

Today, if you want to hide a license plate, your options are surprisingly limited.

You can:

• Manually scribble over it.

• Use a third-party editing app.

• Open Photoshop.

• Use an AI editor.

• Export and re-import the image.

All of these introduce friction.
And friction matters.

Most people don’t skip privacy because they don’t care.
They skip privacy because it requires effort.

The best privacy features are invisible.
They work with a single tap.
Or better yet, they work automatically.

Google Photos already knows how to do this

The interesting part is that the technical problem is largely solved.

Modern computer vision systems can identify:

• Faces

• Text

• Cars

• Traffic signs

• Buildings

• Animals

License plate detection has existed for years.
Parking lots use it.
Toll booths use it.
Law enforcement uses it.
Security systems use it.

The challenge isn’t detection.
The challenge is product design.

Imagine this workflow

You take a photo of your car.

Google Photos processes the image.

A suggestion appears:

Hide license plate?

Tap once.
Done.
That’s it.

No cropping.
No exporting.
No editing.
No learning curve.
Just a simple privacy enhancement.

Users could choose:

• Blur

• Pixelate

• Solid mask

• Replace with a generic plate

The original photo remains untouched.

A copy is created for sharing.

Exactly the same way many editing workflows already operate.

Better yet, make it part of sharing

The smartest implementation might not even live inside the editor.

It could live inside the sharing flow.

Imagine opening the Share menu and seeing a new section called Privacy Controls:

• Hide faces

• Hide license plates

• Remove location information

The user doesn’t have to remember.

The product remembers for them.

Suddenly privacy becomes proactive instead of reactive.

This isn’t really about cars

The deeper lesson here has nothing to do with vehicles.

For decades, software has focused on helping us create and share more content.

We’re now entering an era where software also needs to help us share more thoughtfully.

The next generation of product design won’t just ask:

How do we make sharing easier?

It will ask:

How do we make sharing safer?

Because the internet has changed.

The volume of content has changed.

The permanence of content has changed.

And our expectations around privacy have changed with it.

Google Photos already helps us improve photos.

Perhaps the next step is helping us protect ourselves inside them.

The future of photography may not be better cameras.

It may be smarter decisions about what gets shared in the first place.

If someone at Google sees this:

Build This Next.

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

I was browsing Playo recently.

Like many sports apps, it does a good job helping you find venues, players, trainers, and games nearby.

You can filter by skill level.

You can sort by distance.

You can sort by ratings.

And that’s useful.

But after a point, those aren’t the questions most people are actually trying to answer.

The real question isn’t:

“Which badminton court is closest to me?”

The real question is:

“Which badminton court is right for me?”

And those are very different problems.

Imagine You’re Looking For A Badminton Court

You find three venues within 5 km.

All have good ratings.

All have available slots.

Which one do you choose?

You still don’t know:

• Is it air-conditioned?

• Is it indoor or outdoor?

• Does it have 2 courts or 12?

• Is parking available?

• Can you buy water there?

• Do they rent racquets?

• Are non-marking shoes mandatory?

• Do they have changing rooms?

• Is coaching available?

• Can you get there by metro?

• Is the crowd casual or highly competitive?

The information that actually determines your decision is often missing.

Sports Venues Are Not Commodities

Two badminton courts are not the same.

Two football turfs are not the same.

Two gyms are not the same.

Yet many sports platforms treat venues as interchangeable inventory.

They optimize for:

• Distance

• Ratings

• Availability

But players optimize for convenience.

And convenience is multidimensional.

Different Players Care About Different Things

A parent enrolling their child in coaching wants:

• Qualified trainers

• Safe facilities

• Weekend batches

• Parking

• Waiting areas

A corporate employee playing after work wants:

• Evening availability

• Indoor courts

• Showers

• Easy parking

• Nearby food options

A serious amateur player wants:

• High-quality flooring

• Competitive players

• Coaching availability

• Multiple courts

• Tournament activity

A beginner might simply want:

• Equipment rentals

• Friendly crowd

• No membership requirements

• Flexible booking

The same venue can be perfect for one person and completely wrong for another.

The Missing Layer: Venue Intelligence

Imagine being able to filter venues based on the things that actually influence your decision.

Not just skill level, ratings, and distance.

But infrastructure, scheduling, equipment rentals, parking, amenities, coaching, community, accessibility, venue policies, and dozens of other practical considerations.

The exact interface might look something like this:

An example of what a richer sports venue discovery experience could look like.

The Filter Nobody Thinks About Until It’s Too Late

One surprisingly important category deserves its own section:

Mandatory Requirements

Because nobody wants to discover these at the venue entrance.

Imagine knowing beforehand:

• Non-marking shoes required

• Regular shoes allowed

• Sports attire mandatory

• Membership-only venue

• ID required for entry

• Minimum age restrictions

• Walk-ins allowed or not

Every regular player has experienced this.

You arrive excited to play.

And then discover you can’t.

Not because the court is unavailable.

But because nobody told you the rules.

This Benefits Venues Too

Better filtering isn’t only useful for players.

It helps venues attract the right customers.

A premium indoor facility with AC, coaching, and showers shouldn’t compete solely on distance.

A community-focused beginner venue shouldn’t be judged by the same criteria as a tournament-focused academy.

Better filters allow venues to differentiate themselves on the dimensions they actually invest in.

Discovery Was The First Layer

Sports discovery platforms solved location.

The next challenge is context.

The future of sports marketplaces isn’t helping users answer:

“What venues exist near me?”

It’s helping them answer:

“Which one matches exactly what I’m looking for?”

Because finding a court isn’t the hard part.

Finding the right court is.

Build This Next.

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

Walk into a bookstore and look around.

Thousands of books sit on shelves waiting to be discovered.

Most will never be picked up.

And most of the ones that are picked up will eventually be put back.

Not because they’re bad books.

Because they’re bad at introducing themselves.

Today, discovering a book is surprisingly primitive.

A potential reader typically has to:

• Notice the book on a shelf

• Like the cover

• Read the title

• Read the back-cover description

• Guess whether it’s worth their time

• Decide whether to buy it

For something that may require 10, 20, or even 50 hours of commitment, that’s remarkably little information.

Compare that to almost every other form of media.

Movies have trailers.

Podcasts have clips.

Courses have introductory videos.

Apps have demos.

Music has previews.

Books mostly have covers.

The Problem Isn’t Reading

The problem is discovery.

Most readers aren’t afraid of reading a good book.

They’re afraid of spending time on the wrong one.

A book may contain exactly the ideas someone is looking for.

But unless that person happens to find it, the book remains invisible.

In a world where attention is scarce, books are still relying on discovery mechanisms from decades ago.

Start With A Better Summary

Imagine every book had a concise, high-quality, AI-generated summary.

Not a plot spoiler.

Not marketing copy.

Not a generic description.

A genuine answer to the question:

“What will I learn, understand, feel, or see differently after reading this book?”

Perhaps 50 words.

Perhaps 100.

Just enough for someone to quickly understand whether the book is relevant to them.

That alone would dramatically improve discoverability.

Then Turn It Into A Trailer

Now take that summary and convert it into a 30-second video.

Not a cinematic trailer.

An idea trailer.

A short visual explanation of:

• What the book is about

• Who it is for

• Why it matters

• What makes it interesting

Imagine walking through a bookstore and being able to instantly watch a 30-second explanation of any book you’re holding.

The same way you might watch a movie trailer before deciding whether to spend two hours watching it.

The Bookstore Interface

Here’s where it gets interesting.

Instead of requiring QR codes, apps, or additional setup, every shelf could have a small screen, a camera, and a button.

You pick up a book.

You press the button.

You hold the book in front of the camera.

Within seconds:

• The book is identified.

• A concise summary appears.

• A 30-second explainer video starts playing.

No app.
No account.
No search.
No friction.

Just curiosity answered instantly.

Libraries Could Benefit Even More

Libraries aren’t trying to maximize sales.

They’re trying to maximize discovery.

Which makes them an even better fit for this idea.

Imagine walking through a library and being able to explore dozens of books in minutes.

A student researching a topic could rapidly understand which books are relevant.

A casual reader could discover authors they would never have considered.

A visitor could leave with books they genuinely want to read rather than books they merely guessed might be useful.

A Channel Dedicated To Books

Take the idea one step further.

Imagine a platform dedicated entirely to book trailers.

Every book gets a standardized 30-second explanation.

Users can browse:

• History

• Economics

• Psychology

• Fiction

• Philosophy

• Science

Not by title.

Not by cover.

By ideas.

The result would be closer to discovering videos on YouTube than wandering through a bookstore hoping something catches your eye.

The Bigger Opportunity

The most interesting part of this idea isn’t the technology.

It’s the shift in perspective.

For centuries, books have been passive objects.

They sit on shelves waiting for someone to find them.

But books are really containers of ideas.

And ideas shouldn’t have to sit quietly hoping to be discovered.

They should be able to introduce themselves.

The Real Opportunity

Books are not becoming less valuable.

They’re becoming harder to discover.

The next innovation in reading may not be a better book.

It may be a better interface between readers and the ideas those books contain.

The future bookstore might not just display books.

It might help every book explain why it deserves your attention.

Build This Next.

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

There was a time when sharing photos from a trip meant chasing people across WhatsApp, email threads, and pen drives.

Then shared albums happened.

Today, for almost every trip or get-together, there’s a simple pattern:
One person creates a Google Photos album.
Everyone uploads their photos.
Everything gets auto-arranged by timestamp.

It just works.

And in many ways, Google Photos solved this problem beautifully.

The problem starts after sharing works

When multiple people contribute to the same album, something predictable happens:

Not all photos are equal.

• Some are great

• Some are duplicates

• Some are blurry

• And some… are just not flattering for the people in them

The problem is simple:

The person in the photo has no control over the photo.

Only the uploader does.

The current workaround is broken

In my circles, we’ve created a workaround:

If you want a photo removed, just “like” it.

Which is… completely backwards.

• A “like” is supposed to mean this is a good photo

• Instead, it becomes please delete this

Even worse:

• You can’t delete a photo from within the album

• You can only remove it from the album

• To actually delete it, you have to go find it in your library

And if there are multiple similar photos?
Good luck picking the right one.

The only slightly better workaround is to archive the photo first — so it moves out of your main library — and then go into the archive to delete it.

Which means:
You’re now using a storage management feature
to solve a social curation problem.

That’s usually a sign something fundamental is missing.

The missing layer: consent-based curation

Shared albums today are optimized for aggregation, not consent.

But once photos include people, this becomes a social system — not just a storage system.

What’s missing is simple:

The ability for subjects of a photo to signal whether they are okay with it being there.

The missing feature

A lightweight layer that sits on top of shared albums:

1. “Flag for Review” (not Delete)

• Any person in the album can flag a photo

• The flag is private (not publicly visible)

2. Subject-aware signals

• If multiple people in the same photo flag it → higher priority

• If the uploader flags it themselves → instant action

3. Smart uploader nudges

The uploader gets a clean prompt:

“2 people requested changes on this photo”

With quick actions:

• Remove from album

• Delete permanently

• Ignore

4. Album-level hygiene

Optional filters:

• “Show flagged photos”

• “Pending review”

Why this matters

This isn’t just about UX.

It’s about social comfort in shared digital spaces.

Right now:

• Sharing is frictionless

• Control is asymmetric

And that asymmetry creates silent friction:
People hesitate to upload
People feel awkward asking for deletions
People live with photos they don’t like

The shift

Google Photos solved:

“How do we put everyone’s photos in one place?”

The next problem is:

“How do we make everyone comfortable with what’s in that place?”

One small toggle

Sometimes the biggest UX gaps are not about new features.

They’re about missing permissions.

A simple “flag for review” toggle could turn shared albums
from crowdsourced dumping grounds
into socially aware memory spaces

If someone at Google sees this:

Build This Next.

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

We are racing into a future no one is prepared for.

There are now more dead people on Facebook than living users. Millions of Gmail inboxes belong to people who will never log in again. Crypto assets worth billions are permanently lost every year because the person who held the keys is gone - and with them, access to everything they ever owned.

Family members are locked out of memories.
Children are locked out of assets.
Friends are locked out of last conversations.

And the internet keeps pretending death isn’t part of the user lifecycle.

We’ve solved onboarding.
We’ve optimized engagement.
We’ve automated customer retention.

But we’ve ignored a simple truth:

Every user journey ends in death. And there is no system for what happens after.

Digital Death Is the Next Big Failure in Product Design

Every major product company has been sleepwalking through this problem.

Apple has “Legacy Contact.”
Google has “Inactive Account Manager.”
Facebook has “Memorialization.”
Crypto wallets offer “seed phrases.”
Banks still insist on “contact the branch with a legal successor certificate.”

These are weak band-aids.

They assume:

• The user will remember to hand over access details before they die.

• They will have the time to do it.

• They will trust someone with full access while still alive.

• They will follow manual processes their families even know exist.

• Their heirs will know passwords, find documents, understand probate, navigate bureaucracy, and guess which platforms the deceased even used.

Almost always, none of this happens.

And when it doesn’t, grief turns into chaos.

• Bank accounts stay frozen.

• Photos and messages disappear into corporate servers.

• Investments are lost.

• Crypto is unrecoverable.

• Ongoing businesses tied to one person’s logins simply die.

• Legal and financial abuse becomes easy.

We haven’t hit the peak of this crisis yet - but it’s coming. Fast.

The first true internet generation - millennials - will start dying in large numbers in the next few decades.

They are the first generation to live fully digital lives.

Social.
Financial.
Intellectual.
Creative.
Professional.
Emotional.

All online.

And unless we fix this now, we are walking into the largest silent digital collapse in history.

The Internet Needs an Inheritance Layer

The solution isn’t a “reset password when dead” button.

It can’t depend on customer support.
It can’t depend on government paperwork alone.
It can’t depend on a bank manager.
It can’t depend on your spouse knowing your passwords.

And it cannot depend on the account holder doing anything after they die - because by definition, they can’t.

Any solution worth building must be established while the user is alive, activate automatically after death, resist fraud, preserve privacy, work across platforms, comply with legal frameworks, and place as little burden as possible on grieving families.

Most importantly, it cannot depend on hope.

A Blueprint for Digital Inheritance

Here’s what a real solution looks like.

A user sets up a Digital Legacy Plan once in their life - a universal profile that securely defines who inherits access to their accounts.

Not passwords - access.

They choose what each person gets:

• Financial accounts

• Social accounts

• Business tools

• Notion, Drive, Dropbox

• Crypto and digital property

• Emails, messages, photos, notes, voice memories

• AI agents and their personal instruction history (this becomes crucial soon)

Then they define a release policy:

• Trigger: legal death record OR group attestation + inactivity

• Delay period: 0–180 days

• Scope: full access, partial, or archive export only

• Privacy rules: what gets deleted before handover

When death is verified, the inheritance triggers automatically.

No begging Apple or Meta.
No browser hacking.
No detective work.
No lawsuits.

The heir is notified.
Access is transferred.
The human experience continues - with dignity.

No platform offers this today.

Not even close.

Why This Matters More Than People Realize

If we don’t solve this now, we’re heading into three disasters.

1. The Great Lockout

Trillions in value - financial, intellectual, and emotional - will be sealed away forever.

2. A Broken History

We are the first civilization to create permanent digital memories.

If we can’t preserve and pass them on, our era will become a fragmented historical black hole.

3. The AI Identity Crisis

Within five years, most people will have AI agents trained on their messages, writing style, voice, and decisions.

When a person dies, who owns that AI?

Who controls it?

That question alone will trigger lawsuits we aren’t ready for.

Death Is Not an Edge Case - It’s a Design Requirement

Every product team today thinks about onboarding flows, referral loops, churn curves, and LTV/CAC ratios.

How many think about account succession?
Estate transfers?
Data rights after death?

Almost none.

This isn’t a feature.

It’s a missing layer of digital civilization.

The internet has authentication, payment, identity, and messaging - but no protocol for mortality.

The company that solves this - cleanly, securely, globally - will define a new category.

It’s bigger than fintech.
Bigger than crypto custody.
Bigger than identity.
It’s bigger than social.
It’s the infrastructure of trust for a world where lives are digital.

This isn’t optional anymore.

Someone has to build it.

Build This Next.

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

I was recently browsing FIFA+ on Zee5 during the 2026 World Cup and was struck by how familiar the experience felt.

A grid of videos.
A collection of highlights.
A digital version of a television archive.

Nothing was broken.

But nothing felt native to the internet either.

Sports streaming has come a long way from simply putting live television online.

Platforms like Zee5 now offer highlights, themed collections, historical matches, player features and editorial programming that go well beyond a simple list of live broadcasts.

That’s real progress.

But the underlying product philosophy still feels rooted in television.

Most experiences are still organized around content that publishers want to surface, rather than around the interests, journeys and curiosity of individual fans.

• Matches

• Broadcast schedules

• Single camera feeds

• Passive viewers

The technology has evolved.
The product hasn’t.

Sports streaming learned how to display videos.
It never learned how to help people discover them.

Television organized sports around broadcasts.
The internet should organize sports around curiosity.

The future of sports streaming isn’t better video quality.
It’s better information architecture.

Fans Don’t Follow Matches. They Follow Stories.

Most sports platforms organize content around individual matches.

France vs Iraq.
Belgium vs Iran.
Japan vs Tunisia.

That made sense when matches were the primary unit of distribution.

But fans don’t think in matches.

They think in stories.

A French supporter isn’t following France vs Iraq.
They’re following France.
They’re following a journey.

The platform should reflect that.

Imagine selecting France and instantly seeing:

• Every match

• Every result

• Every goal

• Every save

• Every highlight

• Group standings

• Upcoming fixtures

• Key players

• Tournament progress

Some platforms have already started moving in this direction by creating team hubs and curated collections.

But they’re still largely collections of videos.

What I’m describing is something different.

A country shouldn’t be another playlist.

It should be a living object inside the product.

The World Cup is fundamentally a narrative.

Most sports platforms still present it as a collection of disconnected broadcasts.

Stop Optimizing For Existing Fans

One thing building my World Cup prediction engine taught me is how many countries I didn’t know much about.

The tournament helped me learn.
The interface didn’t.

Sports products are often optimized for people who already know sports.

Take team abbreviations:
FRA vs IRQ
BEL vs IRN
TUN vs JPN

Sports fans instantly decode these.
Casual fans don’t.
New fans definitely don’t.

Why make people perform translation work before they can decide whether they’re interested?

Why not simply write:
France vs Iraq
Belgium vs Iran
Tunisia vs Japan

Instead of helping people discover stories, many sports interfaces quietly assume people already know them.

Good product design reduces friction.
It doesn’t test for prior knowledge.

The same philosophy applies throughout the experience.

Don’t make me remember which match contained the goal.
Let me start with the player.
Or the country.
Or the tournament.
Or even the moment.

The interface should adapt to how people think — not ask people to adapt to how the database is organized.

Stop Making Sports Streaming Feel Like A File Browser

Sports streaming platforms still behave as though the main job is to show users a chronological archive.

Match by match.
Date by date.
Three-letter acronym by three-letter acronym.

The industry has already started moving beyond this.

Platforms like Zee5 now surface highlights, themed collections, player features and editorial categories that make discovery significantly better than it was just a few years ago.

But those improvements still largely organize videos.

They don’t organize interests.

There’s still no meaningful filtering around what I actually care about.

No public ranking.
No view counts.
No clue what has already been watched.
No way to browse the tournament the way I browse the rest of the internet.

This is not how people discover content anymore.

Give us menus.
Give us sub-menus.
Give us filters.
Give us sorting.
Give us view counts.
Give us trending clips.
Give us country journeys.
Give us player feeds.
Give us top goals.
Top saves.
Top assists.
Top controversies.
Top reactions.

Let me follow penalty shootouts.
Or underdog stories.
Or bicycle kicks.
Or goalkeeping.
Or counterattacks.
Or just everything related to Argentina.

Curiosity is personal.

The interface should be too.

Make the TV experience feel closer to an app or a video game.
Let me use my remote.
Let me use my phone as the controller.
Let me open a companion app if that is easier.

Millions of people already navigate sophisticated interfaces on their TVs every day.
YouTube has already trained people to browse, sort, search and discover.
Video games have already trained people to use layered menus without panicking.

We got this.

Today’s sports platforms are still largely asking:

“Which video do you want to watch?”

They should be asking:

“What are you interested in today?”

What we don’t need is another page of match cards auto-sorted by date, forcing us to guess whether we’ve already seen a match between two teams represented by acronyms we may not even recognize.

The platform knows the content.
The platform knows the user.
The platform knows what is popular.
The platform knows what has been watched.
The interface should act like it knows.

Stop Hiding Information From People Who Already Know It

One of the strangest conventions in sports media is hiding scores to avoid spoilers.

That makes sense before you’ve watched a match.

It makes no sense after you’ve watched it.

If I’ve already seen France vs Iraq, don’t show me a generic thumbnail.

Show me: France 3 – 1 Iraq

Alongside:

• Goals

• Assists

• Cards

• Possession

• Player of the Match

• View count

• Trending rank

Better yet, let me choose how much information I want.

Some fans hate spoilers.

Others use the scoreline to decide which matches are worth watching.

Let us choose.

The thumbnail should evolve from navigation into information.

Streaming platforms know exactly what I’ve already watched.

The interface should become smarter as that knowledge accumulates.

Let Me Choose My Camera

Television had a legitimate limitation.

One feed.
One director.
One viewing experience.

Streaming doesn’t.

Modern sports productions already capture multiple perspectives:

• Broadcast camera

• Tactical camera

• Goal-line camera

• Behind-goal camera

• Spidercam

• Crowd camera

The broadcast director chooses one.

Everyone else inherits the decision.

But why?

A casual fan may want the traditional view.
A coach may prefer the tactical view.
A creator may want cinematic angles.
A goalkeeper may want goal-line footage.

Streaming finally gives us the ability to personalize perspective itself.

Every sport has experts looking for different things.

Coaches.
Players.
Analysts.
Creators.
Casual fans.

They’re all watching the same match.

But they’re not watching it the same way.

We should stop pretending there is only one correct perspective.

Highlights Should Become A Product

Many fans don’t want ninety minutes.

They want significance.

Goals.
Saves.
Red cards.
Penalties.
VAR decisions.
Near misses.

Today those moments are scattered across dozens of videos.

Instead, they should become personalized feeds.

Follow Argentina and automatically receive:

• Every Argentina goal

• Every Argentina save

• Every Argentina assist

• Every Argentina attacking move

Or follow:

• Every long-range goal

• Every bicycle kick

• Every last-minute winner

• Every penalty shootout

• Every goalkeeper save

Sports isn’t just organized around teams.
It’s organized around moments.

As the tournament progresses, the story updates itself.
The content already exists.
The platform simply needs to organize it differently.

Let Great Moments Breathe

Most highlight packages still inherit the pacing of television.

Goal.
Replay (angle 1)
Replay (angle 2)
Replay (angle 3)
Move on.

But streaming isn’t constrained by broadcast schedules.

If I clicked on a goal, it’s because I want to experience that goal.

Show me:

• Broadcast angle

• Tactical angle

• Behind-goal angle

• Goalkeeper angle

• Spidercam angle

• Crowd reaction

• Bench reaction

And then give me a one-click option to watch all of them in sequence.

The best moments in sports are often more enjoyable on the second, third and fourth viewing than the first.

That’s why slow-motion replays exist in the first place.

In fact, I explored this idea in more detail in The One-Click Slow-Motion Replay Button Every Sports Streaming App Is Missing, where I argue that replay itself deserves to become a first-class product experience.

Yet most streaming platforms still treat replays as something to get through quickly before returning to the rest of the program.

They should treat them as experiences.

The replay isn’t an interruption.
For many fans, it’s the destination.

A great goal isn’t one moment.
It’s a collection of moments viewed from multiple perspectives.

The internet doesn’t force us to choose a single angle anymore.

So why are we still behaving as though it does?

Let Creators Participate

For decades, broadcasters protected distribution.

That made sense when distribution was scarce.

Today, distribution is abundant.

Attention is scarce.

Sports organizations still spend enormous energy trying to control clips, reactions and redistribution.

The better strategy may be the opposite.

Provide official clips.
Provide official goals.
Watermarked.
Easy to share.
Easy to remix.

Let creators react, analyze, celebrate, criticize and explain.

Every creator becomes a distribution channel.
Every reaction becomes marketing.
Every remix becomes discovery.

The goal shouldn’t be to stop people talking about your sport.

The goal should be to make talking about your sport effortless.

Reels Are Not The Enemy

Many broadcasters seem to believe that reels and short-form video are stealing attention from full matches.

I think they’re looking at the relationship backwards.

Reels are not the competitor.
Reels are the funnel.

A fan might discover a player through a clip.
Watch a highlight package.
Watch an extended recap.
Watch a full match.
Become a tournament follower.

These formats are not competing with one another.
They are different stages of engagement.

The best sports platforms will treat short-form and long-form content as different entry points into the same experience.

Reels create curiosity.
Streaming satisfies it.

One shouldn’t compete with the other.
They should feed each other.

Sports Streaming’s Real Competitor

Sports streaming companies still think their competitors are other sports streaming companies.

They aren’t.

Their competitors are YouTube, TikTok, Instagram and every platform that has taught users to expect discovery, personalization, participation and control.

Sports streaming has already started borrowing some of YouTube’s language.

Better thumbnails.
Editorial collections.
Highlights.
Shorts.
Team pages.

That’s progress.

But YouTube’s real innovation was never the thumbnail.

It was building an experience around curiosity.

It asks:

What are you interested in today?

Sports streaming still mostly asks:

Which video would you like to watch?

Those are fundamentally different questions.

The question is no longer:

Can people watch the match online?

That problem was solved years ago.

The question now is:

Can people navigate sports content the way they navigate the rest of the internet?

And right now, the answer is largely no.

Rethinking sports broadcasting from first principles

If I were rebuilding sports streaming from scratch today, I wouldn’t start with matches.

I’d start with stories.

Follow a country.
Follow a player.
Follow a tournament.
Follow a narrative.
Or follow a moment.
Or a rivalry.
Or a style of play.

Let every fan define their own journey through the tournament.
Let users choose the moments they care about.
Let them choose the perspective they watch from.
Let them sort, filter and discover.
Let them see what the rest of the world is watching.
Let them experience great moments from every angle.
Let creators amplify those moments across the internet.
And let streaming and social media work together instead of competing for the same attention.

Television optimized for channels.
Streaming optimized for on-demand viewing.
The next generation of sports platforms should optimize for curiosity.

Because curiosity leads to discovery.
Discovery creates stories.
And stories are what fans remember.

The future of sports streaming isn’t Netflix for sports.

It’s YouTube for sports.

Not because people want shorter videos.

Because they want to follow their curiosity, not your broadcast schedule.

And every year the industry fails to realize this, YouTube gets one step closer to becoming the place where sports ultimately belong.

Television perfected broadcasting.
The internet will perfect discovery.
The company that brings those two worlds together won’t just build a better sports streaming platform.
It will redefine how fans experience sport.

If anyone at FIFA+, YouTube, Zee5, JioHotstar, Netflix or Amazon is reading this:

Build This Next.

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

The technical build story — how Claude constructed the model, the simulation engine, and what bracket resolution actually involves — is on Promptcraft: Building a Live FIFA 2026 World Cup Probability Engine with Claude.

In 2014, I was at Dell as part of their Global Analytics team. We were trying to encourage teams across the organisation to actually use predictive analytics in their work — not just know it existed, but reach for it when solving real problems.

The honest assessment at the time: it wasn’t taking off the way we hoped.

So I proposed an experiment. Instead of pushing it through work projects, why not make it fun? Run an internal prediction competition around the FIFA 2014 World Cup. Get people excited about a problem they already cared about, and let predictive analytics be the vehicle.

It worked. People engaged. It became a small catalyst for applied analytics within the org — which was exactly the point.

But here’s what that effort actually involved: teams pulling data manually from wherever they could find it. Models that took significant time and technical skill to build. Results that were hard to explain to anyone who hadn’t built them. A process that required real expertise, real effort, and a lot of trial and error — just to get something rough and functional.

That was 2014. Three World Cups ago. Ancient history, in technology terms.

Cut to 2026.

One person. One Claude subscription. A day or two of directed effort.

The result: a live configurable prediction engine that uses peer-reviewed statistical models, pulls live match data automatically, runs tens of thousands of simulated tournaments in the background, and sits online — updating itself — without any ongoing intervention.

No team.
No server.
No data engineering.
No specialist required.

The gap between those two things is twelve years. Well within most of our living memories. And it is one of the clearest illustrations I’ve seen of how completely the tooling around data and AI has shifted. What required a team and weeks in 2014 is now an afternoon for one person with the right AI.

That’s not a comment about effort or intelligence. The Dell teams who ran those 2014 models were talented people doing serious work. It’s a comment about leverage — how much the tools themselves have changed what’s possible, and how quickly.

Back to present day

Every four years, the same thing happens regardless: a pundit on TV tells you Spain are favourites, the betting site gives you odds you don’t know how to interpret, and your group chat argues about whether England will bottle it.

Everyone has opinions.

Nobody has a model.

Now there’s one available — and you can adjust its assumptions to match yours.

Live at: buildthisnextonline.github.io/FIFA-2026-WC

What the tracker does

The FIFA World Cup 2026 Probability Tracker does two things simultaneously.

Current mode shows you the state of the tournament right now — actual results, group standings, who’s qualified and who’s out. Updated from live match data as games are played.

Prediction mode shows you what the model thinks happens next — win probabilities for every remaining match, expected scores, who finishes where in each group, and a full knockout bracket all the way to the champion.

Both views sit in the same interface.

One click switches between them.

The tracker covers all 104 matches across 48 teams, grouped A through L. As matches are played, the prediction window shrinks — by the time you reach the Final, there’s only one match left to call.

Why this is more useful than odds

Betting odds tell you what the market thinks. That’s useful — but it’s not the same as a model with a theory.

The tracker is built on a football statistics technique called Poisson modelling — essentially, a mathematical way of estimating how many goals each team is likely to score, based on how strong they are relative to each other.

It’s seeded from Elo ratings (the same system used in chess) which give every national team a baseline strength score. From there, the model applies real-world adjustments that matter in a World Cup:

• Home ground: Mexico, USA, and Canada get a boost on home soil

• Rest between matches: teams with more recovery days tend to score more

• Extra time fatigue: if a team just played 120 minutes, the next game is harder

You can change all of those assumptions. That’s the point.

The five sliders that make this yours

The parameters panel in the header isn’t decoration. It’s where you put in your own read on the tournament.

Home advantage — How much does playing in North America boost the host nations? The default is +20%. Set it to zero if you think home crowds don’t matter. Crank it up if you think they’ll be decisive.

Draw correction — The model naturally predicts slightly too few draws. This slider corrects for that. The default adds a modest nudge toward 1-1 and 0-0 results.

Rest advantage — Teams with more recovery days perform better. Default is +5% per significant rest gap.

Extra time fatigue — Did a team just play 120 gruelling minutes? The default applies a −10% penalty to their next match.

Simulations — The model runs thousands of complete simulated tournaments to estimate probabilities. 1,000 runs is fast and rough. 50,000 is slow and precise. The default is 10,000 — a good balance.

Change any slider. Hit Apply. Every fixture, every table, the full bracket — everything updates to your assumptions in seconds.

Two views worth spending time in

Stage Probabilities strips away all the bracket narrative and shows you the raw numbers. All 48 teams, side by side, with their probability of reaching each round — Qualify, Round of 16, Quarter-final, Semi-final, Final, Champion. No punditry. No storylines. Just: here is what the model thinks, for every team.

Tournament Draw is the bracket. It shows you the single most-likely path — actual results where matches have been played, model predictions for everything still to come. You can see who the model has lifting the trophy, and who they’d have beaten to get there.

There’s also a fan mode — because not everyone wants to trust the model.

Select any of the 48 teams from the “Root for” dropdown above the Tournament Draw. That team’s matches light up in orange through the bracket. Click any of their matches to lock in a win — overriding the model’s prediction. The bracket rebuilds forward from that result: if you’ve decided Netherlands are beating Spain in the Final, the whole path recalculates to show what that would look like. Click again to release any lock and restore the model’s pick.

Locks are sequential. You can only lock a Semi-final if you’ve locked the Quarter-final that got your team there. And if you go back and unlock that Quarter-final, the Semi-final and Final locks disappear automatically — because without the QF win, your team was never in those matches to begin with.

Stage Probabilities stays untouched. It still shows you the model’s honest assessment of every team’s actual chances. Fan mode is purely a Tournament Draw feature — a “what would have to happen” view, not a revision of the underlying numbers.

These two views will sometimes show different teams in the quarter-finals. That’s not a bug.

Stage Probabilities runs 10,000 simulated tournaments where groups can turn out differently in each run. A team can have a 25% QF chance overall because they reach the quarters across many different simulated paths — sometimes with an easy draw, sometimes not.

Tournament Draw shows one specific predicted path. It anchors on the most likely group outcomes and predicts match by match from there.

Both are correct. They answer different questions. The tracker says so, right there on the page.

It gets more interesting as the tournament goes on

This is a live tracker, not a pre-tournament prediction frozen in amber.

When USA beat Paraguay 4-1, that result locks in. The model doesn’t second-guess it. It takes the actual scoreline, updates the group table, and predicts forward from there.

By the quarter-finals, half the bracket is real. By the semis, almost everything is anchored in actual results. The model is only filling in the gaps.

This is where the tracker is most useful — not at the very start when everything is hypothetical, but mid-tournament, when you have real results to anchor to and real stakes on every remaining match.

Where things are headed

Twelve years ago, building this took a team, weeks, and significant expertise.
Today it took one person and a couple of days.

That's not an edge case.
That's the new baseline.

And it's only getting wider.

The question is what you do with it.

Build This Next.

Build This Next is about tools that fill real gaps — built fast, built properly, and put in front of people who need them.

Want to know how it was actually built? The full technical story — model, simulator, and the bracket problem that didn’t have a clean answer — is on Promptcraft: Building a Live FIFA 2026 World Cup Probability Engine with Claude.

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

We don’t have a content problem.

We have a coordination problem.

Every group viewing session starts the same way:

“What do you want to watch?”
“Anything.”
“You pick.”
“Not that.”
“I’ve seen that.”

Fifteen minutes later, no one has pressed play.

Netflix has perfected personalization for individuals.

But most viewing doesn’t happen alone.

It happens with:

• Partners

• Roommates

• Families

• Friends

• Watch parties

The product optimizes for me.

The real-world use case is often us.

That gap is worth building into.

The Feature: Group Match

Add one button:

Watching Together?

Tap it.
Select profiles (same household).
Or send an invite link for remote viewers.

Netflix returns:

Movies and series that none of you have watched — ranked by how much you’re likely to enjoy them together.

Not individually.

Together.

The Algorithm Isn’t About Excitement

If you average preferences, you get bad picks.

Group failure happens when:

• One person loves it

• One person hates it

The correct optimization isn’t maximum enthusiasm.

It’s minimum disappointment.

The best group choice is the one nobody regrets.

How It Works (Using Data Netflix Already Has)

Netflix already tracks:

• Completion rates

• Drop-offs

• Rewatches

• Genre affinity

• Pacing tolerance

• Maturity comfort

• Time-of-day viewing

Step 1: Remove anything watched by anyone in the group.
Step 2: Build taste vectors for each user.
Step 3: Rank titles by lowest expected dissatisfaction.

Maximize shared satisfaction.
Minimize polarization.

Make It Transparent

Under each recommendation:

92% Group Match

Why?

• All 3 of you finish slow-burn thrillers.

• None of you completed this.

• Similar groups finished it fully.

Trust increases when recommendations explain themselves.

Add Context Layers

Before generating results, ask:

What’s the vibe?

• Light & Funny

• Intense

• Emotional

• Comfort

• Background-friendly

Add time filters:

• Under 45 minutes

• Under 2 hours

• Pilot only

• Binge-worthy

This turns the engine from reactive to intelligent.

Why This Is Strategically Important

This isn’t a UX tweak.

It shifts Netflix from:

Personal recommendation engine

to

Social coordination engine

The real friction isn’t discovering content.

It’s aligning humans.

If Netflix reduces time from app open → play, completion rates rise.

Completion drives retention.

Retention drives lifetime value.

The Second-Order Effects

• Faster session starts

• Higher group satisfaction

• Lower churn in shared households

• Stronger perception of intelligence

• New data layer: how preferences interact socially

Netflix would no longer just understand what you like.

It would understand how your taste behaves in a group.

That’s a new dimension of personalization.

Why It Probably Doesn’t Exist Yet

• Privacy sensitivities

• Account sharing politics

• Cross-region catalog complexity

• Non-trivial optimization math

But technically? Very feasible.

Culturally? Inevitable.

Discovery is Hard. Agreement is Harder.

Finding something good to watch is hard.

Finding something good that everyone wants to watch is harder.

Netflix already knows what each of us likes.

The next opportunity is helping us discover what we like together.

Because the challenge isn’t just recommendation.

It’s coordination.

The future of streaming isn’t just answering: “What should I watch?”

It’s answering: “What should we watch?”

And the platform that solves that problem first won’t just have a better recommendation engine.

It will have a better understanding of how people make decisions together.

If someone at Netflix sees this:

Build This Next.

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

The full technical build story - architecture, data pipeline, validation workflow - is on Promptcraft: CheckMyLounge: Building a Data Product with Claude

The argument is simple.

India has over 110 million credit and debit cards in circulation. A significant chunk of them include airport lounge access as a benefit.

Most cardholders find out whether their card works by walking up to the lounge counter and trying it.

The staff member swipes.
A pause.
A shake of the head.

“Sorry sir, this card is not eligible.”

You walk back out, find a chair near Gate 14, and sit there for the next hour wondering what went wrong.

This happens every single day across every airport in India.

The Problem Is Information, Not Access

The lounge access landscape in India is genuinely complicated.

Some cards need a minimum quarterly spend to unlock visits. Some give you 2 per quarter, some give you 8 per year, some give you unlimited. Some work via Visa, some via DreamFolks, some via Priority Pass. Some lounges accept Visa but not Mastercard. Two lounges in the same terminal can have completely different access rules.

Banks update these terms quietly and without announcement. Several major banks changed their lounge eligibility rules in 2024 and 2025 - HDFC, ICICI, Yes Bank, among others - moving from simple card-swipe access to quarterly spend thresholds and voucher-based systems. With little fanfare. The information itself is buried five levels deep in a PDF that was last updated sometime in 2023.

So most people do what everyone does: they walk up to the lounge and try their luck.

That’s not a discovery problem. That’s a design problem.

What I Built

CheckMyLounge is a free, single-page tool that answers one question:

Will my card get me into the lounge at this airport?

Link: buildthisnextonline.github.io/check-my-lounge

You add your cards to a wallet, pick your airport, hit Check Eligibility. That’s it.

🟢 Eligible — walk in, no conditions
🟡 Conditional — spend threshold or voucher required
🔴 No Access — this card has no lounge benefit

No login. No app to download. No ads. Just the answer.

For each card you can expand the details: visit limits, spend conditions, the access program (DreamFolks, Priority Pass, LoungeKey, Mastercard India), and card-specific notes. The tool also shows which lounges are at your airport, which terminal they’re in, and which networks each one accepts.

Your wallet persists across sessions. Add your cards once and they’re there the next time you open the tool.

What It Covers

16 issuers - HDFC, SBI, ICICI, Axis, Kotak, IndusInd, IDFC FIRST, Yes Bank, AU Small Finance, RBL, BOBCARD, American Express, Priority Pass, Standard Chartered, Federal Bank, and HSBC.

129 cards - both credit and debit. Every card in the dropdown has a verified eligibility entry. No gaps. Entry-level cards that have no lounge access are explicitly marked No Access — not omitted. This matters because it stops you guessing whether your SimplySAVE, Flipkart card, or standard savings account debit card might work somewhere.

18 airports - India’s top destinations by passenger traffic: Delhi, Mumbai, Bengaluru, Hyderabad, Chennai, Kolkata, Ahmedabad, Kochi, Pune, Goa, Thiruvananthapuram, Jaipur, Lucknow, Guwahati, Chandigarh, Nagpur, Bhubaneswar, and Visakhapatnam.

29 lounges - with specific terminal locations and the exact networks each one accepts. Because Lounge A and Lounge B at the same airport can have completely different access rules, and that distinction matters when you’re standing 10 minutes before boarding.

A few things worth knowing:

• Cards with quarterly spend conditions are marked Conditional regardless of how generous the visit cap is. A card that gives 24 visits per year but requires ₹1 lakh spend in the previous quarter is still conditional - and the tool tells you that.

• International lounge access is tracked separately from domestic. The access program often differs: DreamFolks handles most domestic, Priority Pass or LoungeKey handles most international.

• Priority Pass works differently from bank cards - no card type, no Visa/Mastercard network. The tool handles this cleanly: select Priority Pass and the Type and Network fields automatically clear.

• Debit card access works differently from credit cards. Most debit lounge access runs directly through Visa, Mastercard, or RuPay network programs - not DreamFolks. HDFC moved to a voucher-based system in January 2026, requiring ₹10,000 spend in the previous quarter to unlock a digital voucher. The tool tracks these distinctions per card.

Why This Problem Hasn’t Been Solved Yet

Lounges did try. A couple of years ago, eligibility-checking kiosks appeared at lounge entrances - scan your card, find out if you qualify before joining the queue. A sensible idea. It didn’t take off.

Because even with a kiosk right there, people still walk up to the counter and try their luck.

Why wouldn’t they? There’s no cost to trying. You swipe, it fails, you shrug and walk away. Nothing lost except 90 seconds and a little dignity.

The problem is that when everyone does this - and at a busy airport, everyone does - it comes at everyone else’s expense. You’re standing in a queue watching person after person pull out card after card, each one getting declined, the lounge staff patiently swiping through a wallet’s worth of plastic.

Here’s a different idea:

Charge for failed attempts.

Every card presented at the counter that doesn’t clear - automatic ₹50 charge. Small enough that it’s not punitive. Large enough that it makes you think twice before handing over a card you’re not sure about.

Pair it with CheckMyLounge. Tell people upfront: you can try your luck, but every failed attempt costs you. Suddenly, checking your eligibility before you arrive becomes worth doing.

It makes people responsible for wasting others’ time. It also gives them an easy way to avoid the charge. The queue moves faster for everyone.

We should be spending more time inside the lounge than queueing outside it.

The Bigger Observation

The lounge access problem exists because the information is fragmented across dozens of bank websites, each with their own terminology, their own update cadence, and their own incentive to make upgrades sound more attractive than the fine print allows.

Banks have no incentive to surface the full picture — especially the “your card doesn’t work here” answer. A neutral tool does.

This is exactly the kind of problem a small, focused tool can solve better than any bank portal ever will.

No stakeholder alignment needed. No product roadmap. No quarterly review.

Just identify the friction, build the thing, ship it.

Build This Next

If you want to take this further, here’s what one could build next:

1. Crowdsourced updates — the data is open source and contribution guidelines are already on GitHub. Banks update lounge terms quietly and without notice - if you spot something outdated, the instructions for submitting a correction are there.

2. Spend tracker — if your card has a quarterly spend condition, track how close you are to unlocking your visits. Conditional cards now make up the majority of the mid-tier market.

3. Trip mode — enter your flight and airport, get a pre-trip eligibility summary. Integrates neatly with an itinerary.

4. Multi-leg — you’re flying DEL→BOM→LKO. What can you access at each stop?

5. Search by card name — the dataset is now large enough that hierarchical dropdowns are starting to feel slow for people who know exactly which card they hold. A search-first UI would make the tool faster for power users.

The tool exists.
The data is maintained.
The infrastructure is in place.

Build This Next.

CheckMyLounge is free and open source. Try it at buildthisnextonline.github.io/check-my-lounge. Data compiled from public bank disclosures, DreamFolks, Priority Pass, and card network program pages — last updated April 2026. Verify with your bank before travel — lounge terms change frequently and without notice.

The full technical build story is on Promptcraft: CheckMyLounge: Building a Data Product with Claude

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

I had a logo.

Beige background. Needed it blue.

I use AI to generate images fairly regularly. They’re not always perfect — and for most small fixes, I use Microsoft Paint. Resizing. Moving artefacts around. Basic stuff.

But Paint is terrible at color replacement. It works pixel by pixel, in contiguous blocks only. The moment the color you want to replace appears in multiple disconnected areas — which is almost always — you’re hunting for every instance manually and filling them one by one.

So I looked for other tools.

Some wanted me to adjust hue and saturation. Not what I wanted. All I wanted was a specific source hex code replaced with a specific target hex code. Precise input, precise output. No approximation.

Others wanted me to describe what I was trying to do in plain English — to an AI — for a task that has a perfectly precise technical answer.

The rest wanted me to sign up.

And here’s the thing about signing up for a tool you’ve never used, built by a company you’ve never heard of, for a task you need to do exactly once:

You have no idea if it’s even going to work.
And you’re now on a mailing list forever.

So I built it myself.

The Problem Is Hiding in Plain Sight

Color replacement sounds like a solved problem.

It’s not — and the reason is subtle.

Every tool that exists approaches this wrong -

• Paint’s contiguous fill misses disconnected regions.

• Hue/saturation tools operate on the feel of a color, not its value — a blunt instrument when you want a scalpel.

• GIMP has the right feature but buries it in a workflow that’s genuinely hard to navigate for this specific use case.

• Online tools solve the UX but add a layer of friction — servers your file gets uploaded to, accounts you’ll forget you created, AI interfaces for a task that needs no AI.

And underneath all of it, the actual operation is simple:

Find pixels that match a color. Replace them with another color.

No server needed. No account needed. No upload needed. The browser can do this entirely on its own, in memory, without sending a single byte anywhere.

What SwapAnyColor Does

SwapAnyColor is a single HTML file.

Hosted at buildthisnextonline.github.io/swap-any-color/

Open it in a browser. Done. No install.

You upload an image — PNG, JPG, or WebP. Pick the color you want to replace. Pick the color you want instead. Click Replace.

Download the result as a lossless PNG at the original resolution.

Your image never leaves your machine. There’s no server. No account. No ads. The entire tool is ~950 lines of HTML, CSS, and JavaScript.

The Part That Took Actual Thinking

Building the tool quickly surfaced something I hadn’t considered at the start.

I assumed I wanted to replace a single hex code — one precise source color — with another.

That’s not how the real world works.

Even in a logo with what looks like a flat beige background, the actual pixel values are rarely identical across the entire area. Rendering, anti-aliasing, compression — all of these introduce variation. The background that looks uniformly beige is actually dozens of slightly different beiges. #E8DCC8 sitting next to #E5D9C4 sitting next to #EAE0CB. The human eye sees one color. The computer sees many.

This is true for JPGs especially. JPEG compression doesn’t preserve flat colors cleanly. What looks like a solid background is a mosaic of near-identical shades.

If you replace only the exact source hex at zero tolerance, you’ll miss everything adjacent to it. The result looks patchy. Or nothing changes at all.

This is what led to the Region Analyzer.

Drag a selection box over any part of the image. The tool samples every pixel in that region, computes the average color and the maximum spread between pixels, and recommends a tolerance value that covers the full range — with a 20% buffer.

One click to apply. Then replace.

The math behind it:

RGB color has three channels — Red, Green, Blue — each ranging from 0 to 255. Color distance is calculated as 3D Euclidean distance:

√((R₁−R₂)² + (G₁−G₂)² + (B₁−B₂)²)

The maximum possible distance is between pure black (0,0,0) and pure white (255,255,255):

√(255² + 255² + 255²) ≈ 441

So 441 is the furthest apart any two colors in RGB space can be. The tolerance slider maps 0–100 to that full range. Tolerance 100 covers the entire color space. Tolerance 5 catches only a very narrow band of nearly identical shades. The region analyzer measures the actual spread in your selected pixels and suggests the minimum value needed to catch all of them — with that 20% buffer.

It’s the difference between a tool that works in a demo and a tool that works in practice.

What the Tool Actually Looks Like

The interface has two main areas — a sidebar and a canvas.

Sidebar — everything you configure:

• Upload zone

• Sampling mode (Region Analyzer recommended, Single Pixel for lossless images)

• Source color and target color, side by side, with hex input and a color picker

• Tolerance slider (0–100)

• Feather edges toggle — blends boundary pixels gradually instead of hard-cutting, for smoother results on complex edges

• Replace color button

• Download PNG button

• Reset button — takes you back to the original if you don’t like the result

Canvas — the image itself, with:

• Zoom (scroll wheel) and pan (Space + drag)

• FIT button to fit the image to the available space

• Before/After toggle that appears after your first replacement — press B to flip between the original and the result

• Image info in the toolbar: dimensions, total pixels, and megapixels

There’s a 25MP warning for large images — not a block, just a heads-up that peak RAM usage at that size approaches ~400MB.

The One-Session Constraint

This tool does one replacement per session.

One source color → one target color.

If you want to replace multiple colors in the same image:
- replace the first
- download the result
- reload the file
- replace the next

It’s intentional — not a limitation I’m trying to hide. The tool does one thing cleanly. Keeping it stateless keeps it simple.

Why a Single HTML File

I’ve been thinking about this more lately.

There’s a class of tools that are so simple — so computationally cheap, so privacy-sensitive, so single-purpose — that wrapping them in a web app with a backend, authentication, and cloud storage is genuinely the wrong call.

Color replacement is one of them.

A static file you can open in any browser, that runs entirely locally, that you can save to your desktop and use offline forever, is actually the better product for this use case.

No maintenance burden. No server costs. No user data to protect. No GDPR headaches.

Just a file that does a thing.

Build This Next

If you’re building image tools — especially simple, single-purpose ones — ask yourself whether you actually need a backend.

The Canvas API is powerful. Browsers are powerful. Local compute is free.

The number of tools that could be a static HTML file, but aren’t, is larger than you’d think.

Sometimes the right architecture is no architecture at all.

Try SwapAnyColor — and if it solves the problem you had, share it with someone who’s been hunting through Paint trying to find every instance of a color by eye.

Build This Next.

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

This one shows the product story - what got built, what works, what doesn’t.

Companion article deep-diving into the story of what building with Claude entails can be found here - BookMyShow: Building Date-First Discovery with Claude.

The argument was simple.

Most people don’t open BookMyShow knowing what category they want.

They know when they’re free.
They know where they want to be.
They want to see everything happening — and then decide.

But BookMyShow makes you pick a category first.

Movies. Events. Plays. Sports. Activities.
Only then do you get to filter.

That’s the wrong order.

The Show Board

Currently live on buildthisnextonline.github.io/bms-showboard

The Bengaluru Show Board scrapes BookMyShow’s listings directly - movies, events, plays, sports, activities - curates them using Claude, and publishes a single browsable page every week.

1,700+ events. No login. No app. Just open the URL.

What good event discovery actually feels like

Finding something worth doing on a weekend is a three-stage process.

You start with a longlist.
You create a shortlist.
Then you finalize.

The existing BMS site makes this almost impossible. There’s no way to see everything at once. And there’s no way to bookmark anything for later - the “Interested” toggle is for notifications, not planning. So you either make a mental note, or you book right then and there. Neither is how people actually make decisions.

The Show Board changes that. It takes 15-20 minutes of toggling filters, starring events, and going through the Favourites list to get to a shortlist. That’s not fast. But it’s a fundamentally better process than going into Comedy, selecting a date, looking at listings, then going into Music, selecting a date, looking at listings, then going into Workshops - and having no way to hold anything across those searches.

The Show Board lets you see everything at once. And it lets you save what catches your eye.

That’s the starting point for how good event discovery should feel.

What got built - and what didn’t

The original proposal had four filters.

Event Type → ✅ Built

Two levels. Pick a broad group - Experiences & Tours, Live Arts, Sports & Fitness - then narrow to a specific type - Trekking, Concert, Comedy, Kayaking.
Filters work in both directions: selecting an area updates category counts, selecting a category updates area counts.

Location Areas → ✅ Built

Two levels. Pick a zone — South, North, East, Central, West — then narrow to a neighbourhood — HSR Layout, Indiranagar, Whitefield.
About 40% of events have no area data from BMS listing cards, so they appear under Unknown. Still discoverable. Just not geographically placed.

Shortlist → ✅ Built

A Favourites feature lets you save events across sessions. Saved events persist in your browser. If an event disappears from the next digest, it moves to a Past Favourites section — so nothing is lost between weeks.
The experience is exactly what the original proposal intended, just called Favourites instead of Shortlist.

Dates → ⚑ Partially built

This is the one that matters most, and it’s the piece that required a workaround.

BMS listing cards don’t always show specific dates. The scraper handles this by passing a 7-day window to Claude — today through today+7 — and asking it to only include events that fall within that window. Where dates are visible on the listing card, this works. Events outside the window get filtered out.

Where it breaks down: touring shows, multi-city events, comedy specials. These list the event name and venue but bury the actual dates inside a second-level page — one per city, one per date. The scraper doesn’t go that deep. So Claude sees no date, defaults to including the event, and it ends up in the digest regardless of whether it’s actually happening this week.

The result: date filtering works for events that surface their dates upfront. It doesn’t work for events that don’t. Which is a meaningful chunk of the listings.

Social visibility. ✗ Not attempted.

The opt-in social layer from the original proposal - seeing which friends are attending the same event - wasn’t attempted.
That requires user accounts, a social graph, and a backend.
None of which exist here.

What it costs to run

Building it →
$23.60/month (~₹2,360/month) for a Claude Pro subscription (including 18% GST).

Running it →
~$1.40 (~₹140) of API credits estimated per run - most recent run cost $3.42 (~₹342), reason unknown.
API credits are also subject to 18% GST, so $10 (~₹1,000) of credits costs $11.80 (~₹1,180).

Everything else →
Free — GitHub Pages, Python, Playwright, Chrome

At $3.42/run (~₹342/run) - plus GST on top - weekly automation would cost well over $200/year (~₹20,000/year) on top of the subscription. Not feasible. So it runs occasionally - when there’s a reason to.

An open offer to BookMyShow

This was built because what the original article argued for didn’t exist anywhere.

Not trying to compete with BookMyShow. Not trying to replace it.

Just trying to show what’s possible.

If someone at BookMyShow is reading this - the hypothesis has been tested, the prototype exists, and there’s a lot more to explore. Date-first discovery, shortlist-driven planning, the social layer - none of it is rocket science. It just needs someone willing to think it through properly.

That’s the kind of product building I love to do. If you’d like to talk, I’m available for Product Consulting.

The hypothesis that started this is BookMyShow: The Case for Date-First Event Discovery.

This is the product story behind this build.

The full technical build story is on Promptcraft: BookMyShow: Building Date-First Discovery with Claude.

Source code: github.com/BuildThisNextOnline/bms-showboard-code

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

Substack is one of the best platforms I’ve used to publish long-form writing.

It’s clean.
It’s intuitive.
It removes noise.

And most importantly - it lets you focus on writing.

Over time, it has helped me build multiple newsletters across different themes, each with its own cadence, audience, and intent.

I like the control it gives me - over formatting, scheduling, and publishing.

But as I started taking publishing more seriously - not just writing occasionally, but building a pipeline of content - I started running into some very real limitations.

And the more I worked around them, the more one thing became clear:

Substack is designed for writers.
Not for publishers.

The shift most people don’t notice

If you write once in a while, Substack works perfectly.

You write → you publish → you move on.

But the moment you start thinking like this:

• I want to publish every Monday at 11:30 AM

• I have 20+ articles ready or in progress

• I want to control sequencing and timing

• I want to reorder based on what I write next

You’re no longer just writing.

You’re running a system.

And that’s where things start breaking.

Gap #1 - No tables = no structured thinking

This might sound like a small feature gap, but it’s not.

Substack has no native way to create even a basic table.

If you want to present structured information - comparisons, frameworks, breakdowns - you can’t.

The only workaround?

• Build a table in Excel

• Export or screenshot it

• Paste it as an image

This is inefficient, inflexible, and breaks the reading experience.

But more importantly:

Tables are not formatting.
Tables are thinking tools.

They allow you to:

• Compare ideas side-by-side

• Build frameworks

• Present layered concepts clearly

• Scale complex ideas into simple grids

If you can’t structure information, you can’t scale ideas.

Gap #2 - Scheduling UX is fundamentally broken

This is where things go from inconvenient → painful.

Let me show you what it actually takes to change the schedule of a single post.

Phase 1 - Finding the edit option

You start on the Scheduled posts page.

You can see the date — but not the time.
There is no inline edit option.

So you click the three dots.

You click into Edit.

Phase 2 - Breaking the existing schedule

Then into another Edit.

Then into another modal.
And then you see this:

To change the schedule…

You first have to un-schedule the post.

This is like changing a meeting by cancelling it first — every single time.

Phase 3 - Rebuilding it from scratch

Now you start over.

• Click on Continue

• Re-enable scheduling

• Open the calendar

• Select the date

• Scroll through hours

• Scroll through minutes

• Confirm again

There is:

• No quick edit

• No inline change

• No direct input

• No keyboard entry

Just scrolling.

The math makes it worse

To reschedule a single post:

• 12–14 clicks

• ~20+ scroll interactions

• Multiple context switches

• Zero inline editing

Now multiply that by 13 posts in a pipeline.
That’s roughly 150–180 clicks and 250+ scroll interactions
just to insert a single post ahead of everything else.

You’re not managing a schedule anymore.

You’re doing manual labor.

The deeper problem (this is not just UX)

What makes this worse is that this isn’t just a UI issue.

It’s a system design issue.

Substack treats scheduling as a one-time action - not a persistent, editable state.

That’s why:

• You can’t edit directly

• You must “unschedule” first

• You must rebuild every time

The system behaves as if scheduling is something you do once -
not something you manage continuously.

The missing piece: a content pipeline

Both of these problems - tables and scheduling - point to the same gap.

Substack treats posts as documents.

But serious users treat them as objects in a system.

What’s missing is a true publishing pipeline:

• A calendar view of all posts

• Visibility into both date and time

• Drag-and-drop rescheduling

• Bulk shifting (move all posts by +1 week)

• Queue management (what goes out when)

• Recurring slots (every Monday, 11:30 AM)

Right now, none of this exists.

So users build hacks.

The workaround is the signal

Here’s what I currently do:

• Schedule posts at incorrect dates/times

• Stack multiple posts on the same day

• Use non-publishing days as placeholders

• Gradually fix them as the 3-month window rolls forward

This is not a feature.

This is a workaround.

And it reveals something important:

The moment users start building systems outside your product,
they are telling you exactly what your product should become.

The 3-month window problem

There’s another constraint that quietly breaks serious usage.

Substack only allows scheduling up to 3 months in advance.

Which sounds reasonable — until you actually try to run a publishing pipeline.

If you publish once a week, that’s ~13 posts.

I already have more than that ready or in progress.
And if you’re serious about building a body of work, you will too.

The workaround?

You start gaming the system:

• Scheduling posts on the wrong days

• Stacking multiple posts on the same date

• Using placeholder times

• Constantly revisiting and fixing the schedule as the window rolls forward

In other words, you stop planning — and start maintaining.

But the deeper issue isn’t the workaround.

It’s what this constraint implies.

A 3-month rolling window assumes that publishing is short-term.

That creators think in weeks or months.

But serious publishing doesn’t work like that.

You’re building:

• A backlog

• A pipeline

• A body of work

• An audience over years - even decades

And my understanding is that Substack wants to be exactly that platform:

The place where long-term thinkers publish consistently and audiences build trust over time.

But a system that only lets you see 3 months ahead forces you to operate short-term.

Which creates a mismatch:

Long-term ambition
vs
Short-term tooling

You can’t build a long-term publishing system on top of a 3-month planning window.

This isn’t about adding features

Substack doesn’t need to become complicated.

But it does need to evolve.

Because publishing is no longer:

Write → Send

It’s now:

Plan → Sequence → Optimize → Publish

The bottom line

Substack is one of the best tools for writing on the internet.

But the moment you take publishing seriously -
when you move from writing occasionally to running a system -
you start working around the tool instead of with it.

And that’s the signal.

If someone at Substack sees this:

Build This Next.

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

Most people don’t wake up thinking:

“I want to watch comedy tonight.”

They think something more like this:

“I’m free on Saturday evening.
What’s happening nearby that might be fun?”

But most event discovery apps - including BookMyShow - are built backwards.

They assume the user already knows what type of event they want.

Comedy.
Music.
Workshops.
Plays.
Sports.

Only after picking a category do you get the option to filter by date.

This is the wrong mental model.

The Problem with Category-First Discovery

Today, if you open BookMyShow and want to explore events, the flow roughly looks like this:

1. Pick a category (Comedy / Music / Workshops / etc.)

2. Browse a long list of events

3. Filter by date later

4. Manually scan venues and locations

5. Try to remember events you liked

If you want to browse all events happening this Saturday, the platform doesn’t make that easy.

You have to repeat the same search across multiple categories.

This leads to three major problems.

1. Discovery becomes fragmented

Events are siloed by category.

You might miss:

• a pottery workshop

• a music gig

• a theatre performance

…simply because you started inside the wrong category.

2. Planning is hard

People plan their social lives around:

• time

• location

• who they’re going with

Not around event taxonomy.

3. There is no shortlisting workflow

If you browse 200 events and want to narrow them down to 5 options for later consideration, there is no bookmark workspace.

You either:

• mark yourself “Interested” (which triggers notifications)

• or forget about the event entirely

That’s a poor planning experience.

A Better Model: Four Primary Filters

Instead of category-first discovery, event apps should revolve around four primary filters, all available at once.

1️⃣ Dates
When are you free?

2️⃣ Location Areas
Where are you willing to travel?

3️⃣ Event Types / Themes
What kind of experience are you in the mood for?

4️⃣ Shortlisted Events
Which ones are you considering?

These filters should work independently and interchangeably.

A date-first discovery flow lets users start with when they’re free instead of what category they want.

The Discovery Interface

Users should be able to start anywhere.

For example:

Date-first discovery

Saturday evening → HSR / Indiranagar → Comedy + Music

Area-first discovery

HSR Layout → this weekend → any interesting events

Theme-first discovery

Workshops → Saturday afternoon → nearby venues

Shortlist-first discovery

Review saved events → narrow down by date and location

The key idea:

Filters should be orthogonal, not hierarchical.

Discovery should revolve around four independent filters: date, location, event type, and shortlist.

Shortlisting: The Missing Feature

Today BookMyShow only offers an “Interested” toggle.

But that feature is designed for notifications, not planning.

What users actually need is something closer to an e-commerce workflow:

• Browse events

• Bookmark interesting ones

• Review them later

• Narrow down the final choice

Think of it like a shopping wishlist.

Or a travel shortlist on Airbnb.

This simple feature dramatically improves decision-making.

Event discovery should allow users to quickly shortlist interesting events before deciding what to book.

The Ideal Event Discovery Interface

Putting this together leads to a very simple interface.

At the top of the event list:

Dates | Location Areas | Event Types | Shortlist

Each filter can be toggled independently.

Users can explore events however they want — by time, by place, by theme, or by saved shortlist.

The result:

• faster discovery

• less scrolling

• better decision-making

A unified event discovery interface combining date, location, and event-type filtering.

A Social Layer: Who Else Is Going?

There’s one more feature that could make event discovery much more powerful.

People often attend events because their friends are going.

But today, BookMyShow has no meaningful social layer.

A better approach would be:

After booking an event, the app asks:

“Would you like to make your attendance visible to friends who also book this event?”

If both people opt in, the event card could show:

2 friends attending: Rahul, Neha

This allows:

• organic group discovery

• social proof

• easier coordination

Importantly, it preserves privacy.

Visibility only activates if:

• both people booked the event

• both opted into sharing attendance.

An opt-in social layer that lets friends see when they’re attending the same event.

What This Changes

This redesign shifts the product from:

A ticket catalog

to

A citywide experience discovery engine

Instead of asking:

“What category do you want?”

The product starts asking:

“What are you doing this weekend?”

That small shift unlocks a much better experience.

Users can explore events the way they actually plan their lives:

• around time

• around place

• around people

Not around product categories.

Build This Next

If I were building the next version of event discovery apps, I would start with four principles:

1. Date-first discovery

2. Flexible multi-dimension filtering

3. Shortlist-driven planning

4. Opt-in social visibility

Small interface changes.

Massive improvements in how people discover experiences.

If someone at BookMyShow sees this:

Build This Next.

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

WhatsApp has quietly become the world’s default coordination tool.

Trips are planned there.
Apartment issues are discussed there.
Office side-projects happen there.
Friends decide where to meet there.

And yet most WhatsApp groups suffer from the same problem:

Participation asymmetry.

One person sends messages.
Someone creates a poll.
Someone tags people for answers.

And everyone else…

…reads the message and does nothing.

Not because they don’t care.

Mostly because there is no feedback loop.

The Tools Exist. Participation Doesn’t.

WhatsApp already supports a wide range of interaction tools across mobile and web - media sharing, documents, location, polls, events, payments, and even AI-generated images.

In other words:

The mechanics for interaction already exist.

What’s missing is participation design.

The Problem

If you’ve ever tried to organize something in a WhatsApp group, the pattern is familiar.

You ask a question.

You tag a few people.

You create a poll.

And then…

“Seen by 12.”

No responses.
One vote.
Silence.

The tools exist, but the system offers no gentle push to participate.

Feature 1: Tag Response Nudges

If someone is tagged and doesn’t respond, WhatsApp could send a gentle reminder.

Group setting options:

• Remind after 2 hours

• Remind after 8 hours

• Remind after 24 hours

• Off

Example notification:

“You were tagged in Goa Trip Planning but haven’t replied yet.”

This alone would solve a surprisingly large share of group coordination friction.

Feature 2: Poll Participation Nudges

Polls often fail simply because people forget to vote.

WhatsApp could notify non-voters.

Example:

“You haven’t voted in the poll: Friday or Saturday dinner?”

Possible settings:

• Remind after 8 hours

• Remind after 24 hours

• Remind until poll closes

• Off

Feature 3: Poll Frequency Limits

Polls become noise when they’re overused.

Admins could optionally set limits such as:

• 1 poll per day

• 3 polls per week

This keeps polls meaningful rather than spammy.

Feature 4: Personal Participation Stats

WhatsApp could introduce private participation stats visible only to each user.

Example metrics:

Poll participation

You voted in 12 of 18 polls (67%) in the last 30 days.

Tag responsiveness

You replied to 7 of 10 tags (70%)

Missed tags

You missed replying to 3 tagged messages last week.

Average response time

3 hours

The goal isn’t pressure.

Just awareness.

People often don’t realize how unresponsive they’ve become.

Feature 5: Group Participation Heatmap

Admins could see a simple group engagement overview.

Example:

Or a simple activity heatmap showing when the group is most responsive.

This helps admins understand when decisions should be asked.

Feature 6: Decision Mode

Sometimes groups temporarily need high participation.

Planning a trip.
Booking tickets.
Choosing a restaurant.

Admins could enable Decision Mode for a short period.

Decision Mode enabled for 24 hours.

During this period:

• Poll reminders activate

• Tag reminders activate

• Poll limits apply

Once the decision is made, the group returns to normal.

Why Nudges Work

People usually don’t ignore messages intentionally.

They just:

• postpone replying

• forget to vote

• assume someone else will respond

Small nudges fix this.

We’ve seen the same effect everywhere:

• Step counters increase walking

• Duolingo streaks increase learning

• GitHub activity graphs increase coding

Visibility changes behavior.

The Bigger Opportunity

WhatsApp today is:

The world’s messaging layer.

But increasingly, it is also becoming:

The world’s coordination layer.

Trips, meetings, apartment management, school groups, events — all of it runs through WhatsApp.

Yet the product still behaves like a chat stream, not a coordination system.

Participation nudges could change that.

Turning WhatsApp groups from:

message streams

into

decision spaces.

An open offer to Whatsapp

This is just one of my ideas to show what’s possible.

This was built because Whatsapp has the highest stickiness of any app for most of its 3.3 billion monthly active users globally.

And the gap between what it is and what it can be is massive.

If someone at Whatsapp is reading this - there’s a lot more to explore. It just needs someone willing to think it through properly. That’s the kind of product building I love to do. If you’d like to talk, I’m available for Product Consulting.

And if someone at Whatsapp sees this post:

Build This Next.

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

You pick:

• 1st

• 2nd

• 3rd

• …

• Up to 5 such dates

And that’s how your SIP runs.

If the market is closed, it runs the next day.

This works — but only in the most primitive sense.

It completely ignores how people actually think about recurring actions.

And it is the only part of an otherwise beautifully designed platform that hasn’t evolved in years.

What Zerodha SIPs Look Like Today

Everything is based on:

• A fixed date

• Repeated monthly

• With no understanding of patterns, weeks, or behaviour cycles

Weekly SIPs require hacks like:

• Picking 1st, 8th, 15th, 22nd, 29th

• Or picking 1st, 2nd, 3rd, 4th, 5th to simulate “every weekday”

This isn’t intuitive.
This isn’t elegant.
And it isn’t how modern software thinks about recurrence

What Outlook (and Google Calendar) Already Solved Years Ago

Look at how recurrence works in Outlook — arguably the best designed recurrence engine ever created.

You can choose:

✔ Daily

Every day, or every X days.

✔ Weekly

Every week, or every X weeks.
And you can choose specific days:

• Every Friday

• Every Tuesday & Thursday

✔ Monthly

Two modes:

Date-based:

• 5th of every month

Weekday-pattern-based:

• First Friday of every month

✔ Yearly

• Specific date (5 Dec)

• Specific weekday pattern (first Friday of Dec)

✔ End Conditions

• End after X occurrences

• End on a specific date

• Or never end

This is what users already understand.
This is what feels natural.
This is what makes recurrence comprehensible.

Kite SIPs Should Work Like This

Here is a crisp, minimal feature spec Zerodha could implement.

1. Choose Frequency

• Daily

• Weekly

• Monthly

• Yearly

2. Configure Based on Frequency

A. If Daily

• Every day

• Every X days

Great for systematic accumulation strategies.

B. If Weekly

Show weekday checkboxes:

☑ Mon
☑ Tue
☑ Wed
☑ Thu
☑ Fri

This instantly creates:

• “Every Friday SIP”

• “Every Tue & Thu SIP”

No hacks needed.

C. If Monthly

Two modes:

1. Date-based

1st, 2nd, 3rd, etc.

2. Pattern-based

First Friday
Second Monday
Last Wednesday

Much closer to how real-world patterns work.

D. If Yearly

Two options:

• On date (e.g., 5 Dec)

• On pattern (e.g., first Friday of December)

3. End Conditions

Just like Outlook:

• Ends on a date

• Ends after X cycles

• Or never ends

A missing piece in Kite today.

4. Summary Preview

Outlook-style:

“Occurs every Tuesday and Friday at 09:30 until May 2026.
If the market is closed, it will trigger on the next trading day.”

This reduces cognitive load and removes ambiguity.

Why This Matters

For Users

• Real weekly SIPs become effortless

• No need for manual hacks

• Investing behaviour matches mental models

• Adds flexibility without complexity

For Zerodha

• Higher ETF SIP activation

• Stronger user stickiness

• Clear differentiation from other brokers

• Very small engineering lift for very large UX gain

This is a classic high-impact, low-effort product win.

A Simple Upgrade With Outsized Impact

Kite is one of the best investing UIs in the world.

But this is one place where the recurrence model feels frozen in time.

People don’t think in dates.
People think in patterns.

Calendar apps already solved this.
Investing platforms simply haven’t adopted it yet.

This is an opportunity hiding in plain sight.

If someone at Zerodha sees this:

Build This Next.

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

• Play / Pause

• Rewind 10/15/30 seconds

• Forward 10/15/30 seconds

And that’s fine for movies, TV shows, and documentaries.

But for sports, it’s nowhere close to enough.

Sports is the only category of video where you constantly want to rewatch the same moment immediately — and in slow motion.

A perfect cover drive.
A stunning diving catch.
A cross-court winner.
A deflection off the pad.
A last-second block.

These aren’t moments you want to simply rewind and rewatch at regular speed.
They’re moments you want to study — the angle, the timing, the contact, the arc, the footwork.

Yet doing this today requires multiple steps:

1. Rewind

2. Tap play

3. Open speed controls

4. Choose 0.5× or 0.25×

5. Watch

6. Reset speed back to normal

Six inputs for something sports fans instinctively do multiple times per match.

The friction isn’t technical — the player UI simply hasn’t been reimagined around how sports is actually consumed.

The Missing Feature: A One-Tap Slow-Motion Replay Button

What sports streaming apps need is a Replay button that:

1. Instantly jumps back a few seconds

2. Automatically plays that segment in slow motion

Just one tap.
No menus.
No fiddling with settings.
No losing your place in the stream.

This is the fastest way to experience the best moments as they were meant to be experienced.

Let Viewers Choose: Duration and Speed

But the feature becomes dramatically better when viewers get simple, intuitive control over:

How far back to replay

• 15 seconds

• 30 seconds

• 60 seconds

At what speed

• 0.25×

• 0.5×

These should be presented as clean, pill-shaped options where:

• Only one duration can be selected at a time

• Only one speed can be selected at a time

Clear, minimal, unambiguous.

A small floating panel - like a compact settings pop-up - is all it takes.

Replay Mode: What Happens After the User Confirms

Once the viewer taps Replay:

1. The player immediately jumps back the selected duration

2. Playback begins at the selected slow-motion speed

3. A small toast overlay appears with a message such as: “Replaying last 30s at 0.5×”

4. The rest of the UI stays clean and unobtrusive

5. After that segment completes, the player automatically returns to normal speed

Zero effort.
Zero confusion.
Maximum clarity and enjoyment.

Why This Is a No-Brainer for Sports Platforms

Because this is already how fans behave.

They manually rewind.
They manually adjust speed.
They manually reset it.
All to recreate the same interaction a Replay button could do instantly.

This feature:

• Increases engagement

• Increases session time

• Increases delight

• Increases platform preference

• Requires no new underlying technology

It is a pure UX upgrade sitting in plain sight.

Why No Major OTT Platform Has Built It Yet

Because their video players were designed for general content, not sports.

Sports has unique viewing behaviours:

• High-impact moments happen suddenly

• Fans want to inspect details

• Slow motion is essential

• Replays are frequent

• Viewers jump back short distances repeatedly

A generic player cannot serve this need well.
A sports-first player can - and should.

Build This Next: The Slow-Motion Replay Button

It’s simple.
It’s intuitive.
It’s already technically feasible.
And it fills one of the most obvious UX gaps in sports streaming today.

The first platform to ship this will instantly differentiate itself - not through expensive rights, but through experience.

A small feature.
A huge upgrade.
A delight multiplier.

The kind of product idea that feels obvious in hindsight.

Build This Next.

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.

Finding the setting you need when you actually need it.

Everything is buried behind five layers of menus, inconsistent labels, and search boxes that only work if you “guess the keyword” some engineer used internally.

We don’t need more toggles.
We need more intelligence.

It’s time for the next obvious step:
Put an LLM inside the Settings app — or better, make the LLM the Settings app.

The Problem: We’ve Hit Menu Complexity Peak

If you’ve ever tried to fix:

• Why your Bluetooth earbuds sound soft

• Why your screen turns off while reading

• Why your battery dies overnight

• Why WhatsApp photos keep saving

• Why your hotspot disconnects

• Why only one display works on your dock

…then you know the problem isn’t lack of features.
It’s lack of discoverability.

Modern phones have thousands of configuration points.
Most users know twelve.

We’re at the point where you need to know the solution before you can search for the solution.
That’s not how technology should work.

The Breakthrough: Explain What You Want, Not What to Toggle

A well-designed on-device LLM should let you say:

“My Bluetooth earbuds are quiet even at full volume.”

And the phone should:

• infer “absolute volume”

• find the setting

• change it

• test it

• confirm the fix

No more chasing settings.
No more guessing the vocabulary.

Instead of:

“Go to Settings → Display → Lock Screen → Screen Timeout → Reading Mode (hidden under Advanced).”

You simply say:

“Keep my screen awake while I’m reading PDFs.”

And it’s done.

This Is Not a Future Idea — This Is Inevitable

Apple, Google, and Samsung are already embedding LLMs directly into silicon:

• Apple is building intent-based OS interactions for iOS.

• Google Pixel ships with Gemini Nano, designed for on-device actions.

• Samsung has Gauss, an OS-level assistant stack.

They all know the same thing:
Settings menus don’t scale. Intent does.

The next OS war won’t be about camera megapixels.
It will be about who builds the best agentic settings engine.

The Future: Settings Become Behaviors, Not Buttons

Instead of rows of toggles, you’ll have goals:

• “Maximise battery life”

• “Reduce distractions”

• “Privacy first”

• “Performance mode”

• “Kid-safe mode”

• “Travel mode”

• “No dumb questions — just fix it mode”

The OS will configure itself dynamically.

You’ll speak human.
Your phone will speak system.

Why This Must Live Inside the OS, Not as an App

An LLM needs:

• full settings map

• permission to make changes

• real-time validation

• contextual understanding, on-device

• private inference

Apps can’t do this.
Only the OS can.

This is why Siri and Google Assistant have always felt limited — they sit outside settings, not inside it.

The next leap is embedding the intelligence directly in the configuration layer.

What This Unlocks

1. One sentence → multiple coordinated changes
   “Make my phone quiet except calls from Mom.”

2. Inferred cause diagnosis
   “My battery dies by evening” → finds rogue apps, disables background sync, optimizes radios.

3. Proactive recommendations
   “You’re switching time zones often — turn on adaptive alarms?”

4. Natural language explanation of settings
   “What does ‘Private Compute Services’ actually do?”

5. Zero-learning-curve technology
   Anyone can master every feature, instantly.

Why This Matters

We’ve accepted the idea that:

• phones are complicated

• settings are confusing

• menus have to get deeper

• search only works if you know the terms

But it’s all artificial complexity.

The real user interface of a smartphone should be your intent.

Not your memory.
Not your menu navigation.
Not your ability to reverse-engineer UX decisions.

Right now, the OS expects you to adapt to it.
With an LLM-driven settings layer, the OS adapts to you.

Build This Next

We don’t need bigger screens.
We don’t need more icons.
We don’t need more toggles.

We need the simplest idea in all of software:

“Tell me what you want. I’ll figure out the rest.”

If you’re building tools for the next decade:

Build This Next.

I write about how products can be better — fixing what’s broken and imagining what’s missing.

If this made you notice something broken or missing, you can subscribe to Build This Next to receive future essays directly.

Every subscription is a vote for building better products.

And if this sparked an idea, take a few seconds to share it — it might help someone else build or see products differently.