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.

This is a huge step forward — ensuring that every digital payment, whether through UPI, cards, or wallets, has at least two distinct layers of security, one of which must be dynamic (unique per transaction). RBI has also said that issuers could be liable to compensate customers if they fail to comply, and that cross-border “card-not-present” transactions must follow by October 2026.

Strong regulation. Necessary guardrails. A safer system.
But here’s the catch: technology alone is not enough.

The Problem of Mixed Messages

Back in October 2021, I wrote about how our use of OTPs confuses the very people we’re trying to protect.

• We tell our parents, relatives, and friends: “Never share your OTP with anyone.”

• At the same time, courier deliveries, service providers, and platforms ask for an OTP to confirm identity.

This inconsistency makes it harder for people to know which OTP is dangerous to share and which is harmless. For a digitally savvy user, it may be a minor inconvenience. For the vulnerable, it can be catastrophic.

The 2021 Proposal: Differentiate OTP Formats

My suggestion then was simple: change the format of OTPs depending on the transaction type.

• Financial transactions (outgoing payment): Keep OTPs numerical, ideally 6 digits (e.g., 873249).

• Non-financial transactions (identity confirmation, deliveries, etc.): Shift OTPs to alphabetical codes, 4–6 letters (e.g., SHYZ or KDYSHT).

That way, the mental model becomes obvious:

• Numbers = money moves 💸

• Letters = identity proof 📦

No second-guessing. No mixed signals. Just clarity.

Why RBI’s New Directions Make This Urgent

RBI’s 2FA mandate ensures better protection — but as OTPs become more deeply embedded in every transaction, the design of OTPs matters as much as the regulation.

• A dynamic factor could mean tokens, app-based prompts, or new forms of OTPs.

• But without clear differentiation, users will still be at risk of scams.

• Regulators and PSPs should now seize this moment to build a dual OTP standard — not just secure, but understandable.

The Way Forward

It’s time for banks, fintechs, e-commerce players, and regulators to:

1. Adopt dual-format OTPs (numeric vs. alphabetical).

2. Communicate clearly and consistently with consumers.

3. Measure success not only in fraud reduction, but in user confidence.

Because security isn’t just about systems.
It’s about making safety obvious to everyone.

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 visa apps stop at eligibility. But real travel decisions aren’t just about whether you can get in — they’re about cost, flight time, weather, and comfort. Imagine if apps like Atlys helped you filter destinations by all of that, not just paperwork.

Today, most travel/visa apps focus only on documents and processing. They help you get the visa, but they don’t help you decide where to go in a way that matches your personal travel preferences. What if they also let you filter destinations by real-world travel factors like:

• Visa cost

• Flight duration (min / max)

• Travel timing (months)

• Temperature (min / max)

• Language commonly spoken

That way, instead of just knowing “yes/no” on visa eligibility, you’d get recommendations tailored to your budget, schedule, and comfort.

Before: Current Filter Page

Right now, the filters are very basic — mostly around residence country.

After: Smarter Filters

With smarter filters, the app could evolve from a visa helper to a travel planner.

You’d be able to answer questions like:

• “Where can I go this December that’s under 6 hours flight time, costs less than ₹5K for the visa, and has mild weather?”

• “Which countries allow multiple-entry visas and are warm in March?”

Why This Matters

Travel decisions are rarely just about can I get the visa?. They’re about time, money, and experience. Adding these filters would bridge the gap between bureaucratic eligibility and meaningful travel choices.

If travel apps integrated this, they’d go from being a transactional tool to a trusted travel companion.

If someone at Atlys 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 have spent over a decade and a half jotting down ideas on what the world needs — either as improvements to products that already exist, or brand-new products that deserve to be brought to life. This is my space to share those ideas openly and freely, to help communicate concepts that might spark action or collaboration.

What you’ll find here

A collection of ideas on how the world around us can be improved — with a bias toward digital-first concepts, though physical-world ideas will appear too.

Ideal outcome

Ideally, those who own the existing products take it upon themselves to build the improvements I’m suggesting. And where those products don’t exist, I hope there are people who choose to bring them to life.

Note

Feel free to reach out and engage me in an advisory capacity if seeking more hands-on involvement — especially since I have thought through some of these product concepts in great detail.

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.