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.

Subscriptions are the only true ongoing signal I get that this work is valuable to others.

And if this sparked an idea, take a few seconds to share it — it might change how someone else builds or sees products too.

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.

Subscriptions are the only true ongoing signal I get that this work is valuable to others.

And if this sparked an idea, take a few seconds to share it — it might change how someone else builds or sees products too.

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.

Subscriptions are the only true ongoing signal I get that this work is valuable to others.

And if this sparked an idea, take a few seconds to share it — it might change how someone else builds or sees products too.

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.

Subscriptions are the only true ongoing signal I get that this work is valuable to others.

And if this sparked an idea, take a few seconds to share it — it might change how someone else builds or sees products too.

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.

Subscriptions are the only true ongoing signal I get that this work is valuable to others.

And if this sparked an idea, take a few seconds to share it — it might change how someone else builds or sees products too.

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.

Subscriptions are the only true ongoing signal I get that this work is valuable to others.

And if this sparked an idea, take a few seconds to share it — it might change how someone else builds or sees products too.

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.

If someone at Whatsapp 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.

Subscriptions are the only true ongoing signal I get that this work is valuable to others.

And if this sparked an idea, take a few seconds to share it — it might change how someone else builds or sees products too.

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.

Subscriptions are the only true ongoing signal I get that this work is valuable to others.

And if this sparked an idea, take a few seconds to share it — it might change how someone else builds or sees products too.

• 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.

Subscriptions are the only true ongoing signal I get that this work is valuable to others.

And if this sparked an idea, take a few seconds to share it — it might change how someone else builds or sees products too.

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.

Subscriptions are the only true ongoing signal I get that this work is valuable to others.

And if this sparked an idea, take a few seconds to share it — it might change how someone else builds or sees products too.

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.

Subscriptions are the only true ongoing signal I get that this work is valuable to others.

And if this sparked an idea, take a few seconds to share it — it might change how someone else builds or sees products too.

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.

Subscriptions are the only true ongoing signal I get that this work is valuable to others.

And if this sparked an idea, take a few seconds to share it — it might change how someone else builds or sees products too.

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.

Subscriptions are the only true ongoing signal I get that this work is valuable to others.

And if this sparked an idea, take a few seconds to share it — it might change how someone else builds or sees products too.