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.

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.

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.

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.

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

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.

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.

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