Over the past few years, I’ve been deeply curious about marketing not just learning it but understanding how to drive real outcomes. I wanted to work on something measurable something that could directly impact how a company grows.

Sage gave me that opportunity. What started as an experiment eventually grew into a channel that now generates over 100 demo requests every quarter.

We call it warm outbound and here’s exactly how I built it, so you can too.

Finding the Opportunity

When I started working on this, one thing stood out almost immediately.

We were already driving strong traffic through paid and organic channels and demo requests were coming in consistently. But a large portion of visitors, people who had already gained context by visiting our website, were dropping off without any follow-up.

Once they left, there was no structured way to act on that intent. That gap felt like an opportunity.

Introducing Warm Outbound

The idea is simple.

When someone visits your website, they’re already exploring a solution, they have context, they know what you do, they’re just not ready to raise their hand yet.

Warm outbound is about reaching out to those people while that interest is still fresh, rather than waiting for them to come back on their own.

It’s not cold outreach. It’s acting on existing demand.

Building the First Version

I started small.

The initial process was mostly manual - identifying website drop-offs, enriching them with relevant data and filtering for Ideal Customer Profile fit before reaching out via email.

Even at a small scale, the results were encouraging. People responded. Conversations started. That’s when it became clear this wasn’t just an experiment, there was a real opportunity to build a channel here.

But to make this work consistently, I needed to move beyond one-off efforts.

The focus shifted to building something that was:

• Repeatable

• Scalable

• Predictable

Turning It into a Workflow

Manually identifying, enriching and reaching out to every lead wasn’t sustainable. So we built automated workflows using tools like Clay and n8n to handle the entire process end-to-end.

Here’s how the four-step system works and how you can replicate it:

1. Capture - Rather than tracking visitors across every page on our website, we narrowed our focus to high-intent pages only. This kept our pipeline defined and ensured we were only acting on companies who were genuinely exploring a solution, captured with the help of AI-powered visitor identification tools.

These tools work by matching anonymous website sessions to company data, surfacing which businesses are actively browsing your site even when no form is filled.

2. Enrich & Filter - Once we know which companies were browsing, we enrich that data into actual business contacts but only for people who match our Ideal Customer Profile.

💡 Before any outreach, leads are also run against a suppression list to automatically exclude existing customers and active opportunities. This is a deliberate step: enriching and filtering selectively means we’re not wasting credits on irrelevant contacts or embarrassing ourselves by reaching out to someone we’re already in conversation with.

3. Segment - Those filtered contacts are then segmented based on context and intent - job title, company size and the specific pages they visited. This ensures each person is routed to the most relevant campaign rather than receiving a generic message that won’t resonate.

4. Trigger - Leads then flow into targeted email campaigns, each matched to a specific segment and use case. The outreach feels personal because it’s built on actual intent, not guesswork.

In simple terms, the system worked like this:

In short: Capture → Enrich & Filter → Segment → Trigger outreach. That four-step system is what moved warm outbound from experiment to scalable channel.

Where We Are Today

Today, warm outbound generates over 100 demo requests per quarter, consistently.

It works alongside our existing paid and organic channels, helping capture demand that would otherwise be lost entirely.

Instead of relying only on form fills, we’re able to engage with potential buyers earlier in their journey, while intent is still fresh.

And this is still early. There’s significant room to scale further.

What’s Next - And What You Should Try

I’m continuing to build on this foundation.

The focus now is on increasing volume, sharpening targeting and expanding outreach beyond email to make the system even more robust.

If you’re running demand gen and you’re not acting on high-intent website traffic, that’s the first place to start. You don’t need a perfect system on day one. Start manual, prove the concept, then automate.

For us, warm outbound is no longer just an experiment.

It’s becoming a core part of how we capture demand.

Not all demand needs to be created. Sometimes it already exists. The real question is whether you’re able to act on it at the right time.

If you’ve read my prior migration posts: Projects API Migration (single-endpoint refactor) and Corporate Credit Cards API Migration (wide-scope migration across payment flows), you know how and why we are migrating APIs. As a developer, for me, each API migration comes with something new. And with every migration, I learned new things and thought I had a decent mental model of what these things looked like. For every other aspect, Dwolla API Migration follows the same disciplined process, but with one important twist: the Dwolla migration required learning payment-domain concepts (ACH, micro-deposits, beneficial owners) to get the frontend behavior correct.

Why am I Writing This? ✏️

Here’s my honest answer: every time I’ve written one of these kinds of blogs, it has forced me to reflect on what actually made that initiative hard. Not the surface-level “we changed endpoints …” kind of hard, but the what did I not know going in kind. And looking back, the Dwolla migration had more of those moments than any I’ve done before.

The Projects API migration was my introduction to the world of API migration as an intern, involving a single GET API, response transformation, and a couple of personas. The CCC migration was more extensive in scope, involving 10+ APIs, card and transaction workflows, and a complex export feature; however, the domain was something I could reason about fairly quickly. Credit card transactions, assignments, and statements, the words made sense.

Dwolla was different. The moment I opened the PRD (Product Requirements Document), I was staring at words I didn’t know: ACH, micro-deposit verification, beneficial owner, Dwolla customer, funding source. It felt less like an API migration and more like being handed a map in a language I hadn’t learned yet.

And that’s why I’m writing this. Not just because the technical work was interesting (though it was), but because this migration taught me something I hadn’t expected: that understanding the domain is the real prerequisite, not just reading the API docs.

This is the story of a journey where an API migration turns into a domain crash course!

What Even Is Dwolla? 📚

Before I could migrate anything, I had to understand what I was migrating for.

Dwolla is a payment infrastructure provider that powers ACH (Automated Clearing House) bank transfers. In our app, it’s what enables employees to receive their expense reimbursements directly to their bank accounts, no check, no delay, just a bank transfer.

The core entity I’d be working with is called a Dwolla Customer. A metadata record that tracks the verification status of a user or an organization. And the verification journey is surprisingly involved:

• Has the customer’s identity been verified?

• Has a bank account been linked?

• Has that bank account been verified via micro-deposits (where the bank sends two tiny deposits and the user confirms the amounts)?

• Has a beneficial owner been added and verified (required for certain business types)?

• Has the account been suspended, or does it need a retry after a failed verification?

Each of these states drove different UI behaviors across more than a dozen components: dashboards, report submission dialogs, settings pages, and admin views. If I had just started swapping endpoints without understanding this, I would have been flying blind.

How Was This Different From My Previous Migrations ⁉

Let me be upfront about this,

Projects API migration taught me the basics, how to write an ED, how to transform API responses, and why we migrate in the first place. The scope was manageable: one GET endpoint, one persona, a straightforward field rename.

CCC API migration taught me the scale. 40+ API calls audited, 10+ APIs migrated, 2 categories of actions (card-level and transaction-level), and a particularly complex export feature. But the domain was familiar territory. I could look at “Assign card” or “Delete transaction” and immediately understand what the code was supposed to do.

Dwolla API migration was both at once: wide in scope and unfamiliar in domain. It added two layers of complexity I hadn’t encountered before: a subtle change in how null Responses were handled, and a persona-specific field problem that required understanding why two different user roles needed different data from what looked like the same endpoint.

More on both of those in a bit.

The Old World vs. The New 👵🏻

The old API had endpoints that required resource IDs in the URL:

GET /api/orgusers/{id}/dwolla_customers ← spender context

GET /api/orgs/{id}/dwolla_customers ← admin context

The new Platform API drops the IDs (authentication context handles scoping) and uses persona-specific paths:

GET /platform/v1/spender/dwolla_customers

GET /platform/v1/admin/dwolla_customers

Cleaner, more RESTful, and a consistent pattern with the rest of our Platform APIs. Easy enough to reason about.

But the API response key field names, that’s where things got interesting.

Why not just Find-and-Replace 🤨

The new Platform API standardized all boolean fields with a is_* prefix.

Ten boolean fields, all renamed. And these API response fields were used across 16+ component files.

My first instinct was simple global find-and-replace. Done in five minutes, right? Not quite.

This approach had two main problems: firstly, it creates a lot of noise in component files, which makes it harder to review the change systematically. And second, most importantly, if any of these field names had already been used as local variable names or component properties, a blind find-and-replace would create duplicate declaration issues. The code would break in ways that aren’t immediately obvious during review.

Hmm, okay, then I thought, why not transform the response in the service layer itself, just like I did during the Projects API migration? However, the challenge with the Projects API migration was that it involved many keys, and the changes in their naming were not as straightforward as simply adding a "is_*" prefix. We decided to transform the names to facilitate a quicker migration of the API. Unfortunately, these transformed API methods have become an oversight in the codebase, making it harder to read and maintain. Ultimately, we will need to eliminate them in the future.

So instead, I created a new model DwollaCustomerPlatform , that exactly reflected the API response shape with is_* field names. The service layer owns the HTTP call and returns this typed model. Components consume it and use is_* fields directly. This way, if the API shape ever changes again, there’s one place to update.

export interface DwollaCustomerPlatform {
  is_customer_verified: boolean;
  is_bank_account_added: boolean;
  is_bank_account_verified: boolean;
  is_customer_suspended: boolean;
  // ...
}

Clean, explicit, typed. Anyone reading the code knows exactly what the API returns.

The tradeoff was risk. Updating field accesses across 16+ files meant that missing even one would cause a silent failure, and Dwolla data is financial data. A missed field update is_bank_account_verified doesn’t just show a wrong value; it could break the consistency of a transaction flow entirely. So the approach demanded care: methodical file-by-file updates, TypeScript’s type checker flagging every unchecked access, and thorough testing at the end. But it was the right call, temporary pain for a codebase that would actually be maintainable on the other side.

The Null Problem (Which Was Actually a Correctness Problem) 🫙

Here’s the change that required the most careful attention.

The old API would throw an error if no Dwolla customer record existed for a user or org. Components had been written to treat that error as a signal: no record exists yet. It was an implicit convention, not great, but it worked.

The new Platform API changed this: it returns HTTP 200 with a null body when no record exists. Which is actually a better API design! But it meant that every component’s error-handling logic was now wrong.

Where components previously caught an API error as “no data,” they’d now receive a successful response with null. If you didn’t handle that, you’d get runtime errors trying to access properties on null.

The fix was systematic: update return types to Observable<DwollaCustomerPlatform | null>, add optional chaining on every property access (dwollaCustomer?.is_customer_suspended), and add explicit null guards at decision points where null was unacceptable.

switchMap((dwollaCustomer: DwollaCustomerPlatform | null) => {
  if (!dwollaCustomer) {
    return throwError(() => new Error('No Dwolla customer record found'));
  }
  // safe to proceed
})

The TypeScript compiler was my best friend here. Once I updated the return type, it surfaced every unchecked access across all 16 files. I couldn’t miss one even if I tried.

The Persona Problem (The Interesting One) 🦹🏼

This is the part I find most interesting to talk about, because it required understanding the domain, not just the code.

When a spender (employee) navigates to their profile page, the app needs to check whether the organization’s bank account is verified, not the spender’s own. This determines whether the spender can even see their personal bank account section. The org’s verification status is the gate.

In the old code, both admin and spender contexts used the same field name customer_verified because the underlying data was the same, and both roles could hit the same endpoint. Nobody had documented this assumption. It was just baked into the code.

In the new Platform API, things are split. The admin endpoint (/admin/dwolla_customers) is now admin-only. Spenders can’t touch it. And the spender endpoint returns a separate field, is_org_customer_verified, specifically to handle this use case, since spenders still need to know the org’s verification status without being able to access the admin endpoint directly.

Here’s where it gets interesting: the old code in one shared component used customer_verified for both roles. For the admin role, that was correct. For the spender role, it was already semantically wrong; it just happened to work because both roles could access the same endpoint. Once the admin endpoint became inaccessible to spenders, that component would silently break: a 403 in the background, and the bank account section just… disappearing for spenders, with no obvious error to debug.

We caught this during the ED phase. And the fix had two parts.

First, flagging it as a backend dependency: the Platform API needed to be exposed is_org_customer_verified on the spender endpoint so the frontend had something to work with. This couldn’t be solved purely on the frontend side.

Second, once that field existed, fixing the condition in the shared component:

const isVerified =
  this.userRole === 'ADMIN'
    ? dwollaCustomer.is_customer_verified
    : (dwollaCustomer.is_org_customer_verified ?? false);

One migration, one pre-existing bug surfaced and fixed, one silent production failure avoided. This is exactly the kind of thing that doesn’t show up in a ticket description; it only appears when you understand what each component is actually doing and why, not just what endpoint it’s calling.

What I Took Away 👨🏻‍🎓

Every migration teaches me something different. Here’s what this one added to the list:

• Domain understanding is the real prerequisite. I couldn’t have caught the spender profile access-control gap or understood why is_org_customer_verified existed as a separate field without first understanding what ACH onboarding actually looked like for users and organizations. The code is just the implementation of business rules, and you have to know the rules to know if the implementation is right.

• Null contracts are API contracts. The shift from “error on missing record” to “null on missing record” isn’t a small detail. It changes how every consumer has to be written. Treating it as a minor footnote in the API changelog would have been a mistake.

• The service layer is the right place to own API complexity. Field renames, payload wrapping, and endpoint selection by persona all live in the service. Components stay clean. Reviews are easier. Future changes have one place to go.

• Migrations surface what the original code assumed. The old code assumed the API would not return null. It was assumed that customer_verified meant the same thing for all roles. These assumptions were not documented; they were just baked into the code. A migration forces you to read carefully enough to notice them.

Wrapping Up 🗞️

This migration was the most involved one I’ve done so far, with wider code impact than Projects, a more complex domain than CCC, and a set of subtle contract changes that required careful attention rather than mechanical execution.

But it’s also the one I learned the most from. ACH, Dwolla, micro-deposits, and beneficial owners were all new words to me when I started. By the end, I could draw the full data flow from a user clicking “Add Bank Account” to the Dwolla API call and back.

That kind of domain knowledge doesn’t come from reading API docs. It comes from slowing down, asking questions, and refusing to treat a migration as a purely mechanical task.

A big thank you to Dimple for the help, and to Kirti and Prabhakar for patiently fielding every backend query I had and keeping the API contracts tight. Couldn’t have caught half of what I caught without those conversations.

Here’s to more of that.

Happy coding! 🚀

I’ve spent years learning and growing at global companies like Amazon and TCS. Those experiences gave me a solid foundation—an appreciation for structure, teamwork, and the power of large-scale impact.

But I realized I wanted to be in a space where I could see the results of my work firsthand, connect directly with clients, and move quickly from ideas to action. That curiosity let me to Fyle and the world of Customer Success. At Fyle, I’ve found the best of both worlds: the freedom to take initiative and a team that makes collaboration effortless.

Hi, I’m Sonia 👋

It’s been a year since I joined Fyle and looking back, it feels like nothing short of a whirlwind—in the best way possible. I’ve learned a ton, stretched myself in ways I didn’t expect and built connections that go far beyond just “work.”

Beyond work, I thrive on balance and little joys. I could live on Chinese food every day and my Bengali sweet tooth always makes room for dessert. For me, it’s all about mixing hustle with happiness—and making the ride as colorful (and delicious) as possible.

🔄 From Processes to People

One of the biggest shifts for me has been how collaboration happens. Here, cross-functional collaboration isn’t scheduled into quarterly meetings— It happens every day : in Slack threads, in quick huddles, in real-time problem-solving.

In my role, I get to work closely with product, engineering, support, marketing, and other teams to ensure our customers don’t just use Fyle—they love it.

From onboarding to ongoing engagement, managing a diverse portfolio of clients means every step of the customer journey is an opportunity to create impact. I get to be right at the heart of it—partnering with real users, solving meaningful problems, and witnessing firsthand how we’re transforming expense management for the better.

👩‍💻 A Day in the Life of a CSM

What does my day look like? No two days are alike—and that’s exactly what keeps it exciting. But some core themes remain constant :

• Managing client portfolios—tracking adoption, engagement, and business alignment.

• Partnering with finance teams to simplify their setup, support reconciliations, and answer billing queries.

• Troubleshooting integrations with platforms like QuickBooks, NetSuite, and Xero etc—ensuring clean, reliable data flows.

• Collaborating with product teams to share client feedback and surface insights that inform roadmap priorities.

• Helping optimize policy configurations for compliance, accuracy, and operational efficiency.

• Proactively checking in with clients—supporting their goals and spotting new opportunities to add value.

• Hosting onboarding sessions tailored to each customer’s workflow and culture.
  

It’s not just about solving challenges—it’s about building relationships and being a trusted partner in their success. At Fyle, being close to the client isn’t an occasional responsibility—it’s the core of the job. That proximity has been one of the most rewarding parts of my journey. I get to be the voice of the customer internally and a trusted advisor externally. Every resolved issue feels like a win. Every insight shared helps the product grow.

🧠 What I Love About Being a CSM

What truly energizes me about being a CSM is the blend of purpose, people, and problem-solving that defines the role. I love the variety. No two days are the same. Some moments call for deep listening and empathy, others for analytical thinking or strategic planning. I get to wear multiple hats—consultant, advocate, troubleshooter, and partner—all while staying connected to the real-world impact of our product.

Every client interaction is an opportunity to build trust, uncover insights, and drive meaningful outcomes—not just for them, but for us as a company.

But what I enjoy most is seeing the lightbulb moments—when a customer realizes how much easier their workflow has become, or when a product tweak we suggested makes a huge difference to their daily operations and reconciliations. That’s what makes the work deeply fulfilling.

🤝 The Power of Teamwork

One thing I’ve truly come to appreciate at Fyle is the tight-knit collaboration across teams. If there’s one thing that stands out about Fyle, it’s the people. The collaboration here isn’t just efficient—it’s genuine.

Need a quick answer? Help is always a ping away. We cheer for each other’s wins and share learnings from our challenges. That culture of openness and mutual support doesn’t just improve how we work—it strengthens how we grow together.

💡 Final Thoughts

Looking back, every chapter of my career—from structured environments at MNCs to the dynamic, client-focused world of Account Management—has shaped who I am today. I’m grateful for the experiences, the people, and the lessons along the way. And I’m excited for the adventures and impact that lie ahead.

I’ve found a space here that aligns with what drives me: people, problem-solving, and purposeful progress. I get to do meaningful work every day, supported by an amazing team and continuously learn from the challenges we solve together.

If you’re considering a move—or taking the plunge into startup life— here’s my advice:
Be open, stay curious, and never underestimate the power of great teamwork.

So that’s been my ride —time to grab some sweets and dive back in 😀

✨ Thanks for reading all the way!

If my journey resonates or sparks curiosity, let’s connect: LinkedIn

Hello, I’m Devendra 👋🏼 from the engineering team at Fyle. Over the past few months, I’ve been on a mission to fix one of the trickiest problems in software — time zones. Our goal? Make sure every timestamp in Fyle shows the right time for each user, based on their preferred timezone, no matter where they are in the world.

If you’ve ever tried scheduling a global meeting where everyone’s clock is different, you know how messy time zones can be. At Fyle, this challenge was real: we needed to ensure every timestamp — across expenses, reports, and comments — stayed perfectly aligned with the user’s chosen timezone, not their device clock or UTC. Here’s how we approached it, why it mattered, and how we made it work seamlessly in both Angular and legacy AngularJS.

⏳ The Challenge: A Timezone Tangle

Imagine you’re in London, but your finance team is in India. You set your Fyle app to “Asia/Kolkata” to sync with them, but the app shows timestamps in “Europe/London” or even UTC (Coordinated Universal Time — the primary global time standard used to regulate clocks and time worldwide, unaffected by time zones or daylight saving changes). Confusing, right? That’s exactly what our users faced.

Here’s why it happened:

• Database: We store timestamps in UTC (standard practice for consistency).

• Angular App: JavaScript’s Date object auto-converts UTC to the device’s local timezone when parsing Application Programming Interface (API) responses.

• AngularJS App: Some components displayed raw UTC strings without conversion.

• User Preference: Users can set a preferred time zone in “My Settings > Preferences,” which might differ from their device’s timezone.

The result? A single screen could show timestamps in local time, UTC, or a mix—causing chaos for expense comments, report comments, and action timelines.

Example: A London-based employee sets their timezone to “Asia/Kolkata.” An expense timestamp shows “10:00 AM Europe/London” in one component (Angular) but “3:30 PM UTC” in another (AngularJS). Confusion guaranteed.

📢 Customer Feedback

We received multiple customer requests to fix this — the consistent ask was:

“Show me all times in my preferred timezone from settings, not my device time or UTC.”

This was not just about aesthetics; it was about workflow accuracy.

Reviewing reports, reviewing expenses, or tracking actions all depend on precise and contextually correct timestamps.

Users expected all timestamps, everywhere — including expenses, reports, and comments — to follow that setting, regardless of where they appear in the app.

🧠 Designing the Fix

When we dug into the problem, one key design decision emerged:

Should the timestamp be shown in the timezone of:

1. The expense owner?

2. The viewer?

We went with the viewer’s timezone — because the person reading the timestamp needs the context in their preferred time, not someone else’s.

That led us to three possible approaches:

Approach 1 — Service-Level Conversion (API Layer)

Convert UTC to the employee’s preferred timezone before sending from the API response.

✅ Consistent across platforms

✅ No UI changes

❌ Any backend error affects all clients

❌ Requires backend deployments for formatting changes

Approach 2 — Component-Level Conversion (Frontend Layer)

Keep UTC from the API and convert it into each component before rendering.

✅ UI flexibility

❌ Repeated logic across components

❌ Easy to miss places → inconsistency

Approach 3 — String-Based Handling + Day.js + Framework-Specific Injection (Final Approach) ✅

Both previous approaches still risked accidental system-local conversions when using Date.

Our breakthrough:

• Keep timestamps as raw UTC strings until they are displayed.

• Convert only at the last step using Day.js with the user’s preferred timezone.

• Use Angular InjectionToken for global timezone access in Angular and service-level configuration in AngularJS.

Performance Impact:

• The Day.js conversion runs once per timestamp at render time (centralised via a pipe/filter), making it lightweight.

• Even for high-traffic views like expense timelines with hundreds of timestamps, the performance cost was negligible (<1–2ms per conversion on average in our profiling).

• By centralising conversion in a pipe/filter, we avoided repetitive conversions across multiple components, further reducing unnecessary overhead.

We ran a simple benchmark by converting timestamps using Day.js with timezone in different list sizes:

List Size Conversion Calls Average Time (ms) Per-Item Avg (ms)

10 items 10 0.87 ms 0.09 ms

100 items 100 3.99 ms 0.04 ms

1,000 items 1,000 37.16 ms 0.04 ms

Benchmark Methodology

All benchmarks were run in a controlled environment to ensure reproducibility. Tests were executed using MacBook Air (Apple M3, 16 GB RAM, macOS Sequoia 15.6)

Benchmarks were conducted using Node.js v22.14.0 and Chrome 116 (headless mode). Each result represents the average of 30 consecutive runs to minimise variance. For fairness, all libraries were tested with equivalent functionality and without unnecessary imports. Day.js was benchmarked both with and without plugins, depending on the use case, with plugin inclusion explicitly noted where applicable. No external caching or precompilation was used; all measurements reflect pure runtime performance.

✅ Observation: Even for 1,000 conversions, the delay is under 200ms, which is generally unnoticeable for most viewers.

✅ Centralising conversion in a pipe/filter avoids multiple re-parsings and keeps overhead low.

You can reproduce the benchmark using this open-source script:
👉 View benchmark script on GitHub

Does Converting on Display Cause Performance Issues in Large Lists?

In most real-world Fyle views (like expense timelines or report histories), we render well under 500 timestamps at a time, so the performance hit is negligible.

For extensive lists:

• We recommend combining this approach with Angular’s OnPush change detection or virtual scrolling to ensure that conversions run only for visible items.

• This ensures smooth rendering even for thousands of timestamps.

🚀 Results

• Unified Experience: Timestamps are consistent across expenses, reports, and comments in both Angular and AngularJS.

• No More Confusion: Eliminated mismatches between local time and UTC.

• Happier Users: Zero timezone-related support tickets post-fix.

• Developer-Friendly: One pipe/filter reduces manual timezone handling.

📚 Key Takeaways

1. Avoid JavaScript’s Date Object: It auto-converts to local time, causing unexpected behaviour.

2. Use Strings Until Display: Keep timestamps as UTC strings to prevent premature conversion.

3. Centralised Logic: A single pipe/filter saves time and ensures consistency.

4. Hybrid Stacks Need Extra Care: Angular and AngularJS require tailored solutions.

🖼 Before vs After

💬 Final Thoughts

This wasn’t just about fixing a bug—it was about building trust. By unifying timestamps across two frameworks, we streamlined workflows, eliminated confusion, and made Fyle’s app more reliable for global teams. Next time you’re wrestling with time zones, remember: keep it simple, keep it string-based, and let Day.js do the heavy lifting.

Have a timezone horror story? Share it below! ⬇️

Hello, I’m Shreyansh 👋🏼, part of the engineering team at Fyle. Today, I want to share our journey of transforming how we handle Data Migrations—a process that's critical, yet often challenging.

What Are Data Migrations?

Before diving into our journey, let's clarify what we mean by data migration. At its core, a data migration is the process of moving, transforming, or updating data within your database systems.

At Fyle, our data migrations are primarily focused on database operations:

• Backfilling data: Adding missing information to existing records.

• Schema updates: Moving data between tables when structures change.

• Data cleanup: Standardising formats, removing duplicates, fixing inconsistencies.

• Business logic updates: Restructuring data to reflect new requirements.

🚩 The Initial Approach & Its Pitfalls

Initially, our data migrations were manual. There was no standardised structure, i.e., everyone had their own way of writing and executing scripts.

Example:

• We had to update the data stored in notification_settings column in our user_preferences

• This needed a data backfill if the older data email_frequency stored in notification_settings is empty and which were created before 1st January 2024.

UPDATE user_preferences 
SET notification_settings = jsonb_set(
    notification_settings, 
    '{email_frequency}', 
    '"weekly"'::jsonb
)
WHERE created_at < '2024-01-01' 
  AND notification_settings->>'email_frequency' IS NULL;

Though straightforward, this approach caused serious problems:

• Long Execution Times: Large operations took hours and were dependent on incoming traffic.

• Impact on Production Traffic: Heavy updates block the rows that are being updated, leading to slower queries, application timeouts, and user disruptions. (We use PostgreSQL as our database)

• No Monitoring: With ad-hoc running of scripts, there was no way to track the progress of rows that were migrated.

🛠️ The Breakthrough: Batch Processing

We knew we needed to break large operations into smaller, manageable chunks. The concept was simple: instead of updating thousands of rows at once, we split migrations into batches of 50 to 200 records.

We developed a standardised SQL template that became our go-to pattern:

-- The batch-wise approach that saved our sanity
WITH batch_data AS (
    SELECT id, 
           row_number() OVER (ORDER BY id) as row_num
    FROM user_preferences 
    WHERE created_at < '2024-01-01' 
      AND notification_settings->>'email_frequency' IS NULL
),
batch_ids AS (
    SELECT array_agg(id) as ids
    FROM batch_data 
    WHERE row_num BETWEEN 1 AND 1000  -- Process first batch
)
UPDATE user_preferences 
SET notification_settings = jsonb_set(
    notification_settings, 
    '{email_frequency}', 
    '"weekly"'::jsonb
),
updated_at = NOW()
WHERE id = ANY((SELECT ids FROM batch_ids));

-- Then manually increment the BETWEEN range for next batch
-- BETWEEN 1001 AND 2000, then 2001 AND 3000, etc.

⚡The Immediate Improvements

This approach gave us breathing room:

• Standardization: Other developers could understand and use the same pattern.

• Reduced Timeouts: With smaller batched updates, users faced little to no disruption in the application.

• Resumability: If something failed, we knew exactly which batch to resume from.

• Production Friendly: Application performance remained stable during migrations.

But it came with its own challenges:

• Manual Execution: We still had to manually run each batch and track progress.

• Human Error: Easy to miss a batch or run the same batch twice.

• Failed batches: Failed batches required manual investigation and re-execution.

🤖 Automating Batch Processing

The batch approach worked, but the manual overhead of running the batches was still not effective. We were spending more time running these migrations than building features.

We introduced a Data Migration Worker System—a Python worker that continuously fetches batches from a dedicated table and executes them automatically.

The Core Architecture

We introduced three key components:

1. The task_batches table

This table was the command center – every batch is tracked from creation to completion.

CREATE TABLE task_batches (
    id SERIAL PRIMARY KEY,
    migration_version TEXT NOT NULL,
    entity_ids TEXT[] NOT NULL,
    handler_procedure TEXT NOT NULL,
    created_at TIMESTAMP DEFAULT NOW(),
    started_at TIMESTAMP,
    completed_at TIMESTAMP,
    failed_at TIMESTAMP
);

2. The worker_config table

This gave us runtime control over the migration process without code deployments.

CREATE TABLE worker_config (
    is_enabled BOOLEAN,
    query_timeout_ms INTEGER,
    processing_interval INTEGER
);

3. The Python Worker

A continuously running process that polls for new batches and executes them, and adds a backoff for processing:

class DataMigrationWorker:
    def run(self):
        while worker_running:
	    if config.is_enabled:
	       set_statement_timeout()
	       process_next_batch() # Runs a procedure
	    sleep(config.processing_interval)

4. Process Batch Procedure

CREATE PROCEDURE proc_execute_batch(batch_id INTEGER)
LANGUAGE plpgsql AS $$
BEGIN
    UPDATE task_batches
    SET 
      started_at = NOW()
    WHERE 
      id = batch_id;

    BEGIN
        EXECUTE handler_procedure(entity_ids);
        UPDATE task_batches SET completed_at = NOW() WHERE id = batch_id;
    EXCEPTION
        WHEN OTHERS THEN
            UPDATE task_batches SET failed_at = NOW() WHERE id = batch_id;
    END;
END;
$$;

The New Migration Workflow

Now, creating a migration has become as simple as:

1. Write a stored procedure that handles a batch of IDs; this is basically what you want to update:

CREATE OR REPLACE PROCEDURE proc_update_user_notifications(entity_ids text[])
LANGUAGE plpgsql AS $$
BEGIN
    UPDATE user_preferences 
    SET notification_settings = jsonb_set(
        notification_settings, 
        '{email_frequency}', 
        '"weekly"'::jsonb
    ),
    updated_at = NOW()
    WHERE id = ANY(entity_ids)
      AND notification_settings->>'email_frequency' IS NULL;
END;
$$;

2. Generate batches with a single query (what we had earlier improved with batch processing):

WITH records_to_migrate AS (
    SELECT id,
           (row_number() OVER ()) / 200 AS batch_id
    FROM user_preferences 
    WHERE created_at < '2024-01-01' 
      AND notification_settings->>'email_frequency' IS NULL
),
batch_grouping AS (
    SELECT batch_id, array_agg(id) AS entity_ids
    FROM records_to_migrate
    GROUP BY batch_id
)
INSERT INTO task_batches (
    migration_version, 
    entity_ids, 
    handler_procedure
)
SELECT 
    'v125_update_user_notifications',
    entity_ids,
    'proc_update_user_notifications'
FROM batch_grouping;

3. Let the worker handle the rest – it would automatically process all batches at a controlled pace.

⚠️ Learning from Failures

Initially, automation was effective—until batches began failing due to intermittent issues, such as database timeouts. Manually reprocessing failed batches wasn't scalable.

We added two new columns to task_batches table to handle this

CREATE TABLE task_batches (
    ...
    retry_count INTEGER DEFAULT 0, -- Current attempts of batch (if failed)
    max_retries INTEGER DEFAULT 3  -- Max attempts allowed to a batch.
);

We then updated our batch execution procedure to include automatic retries of failed batches with backoff at the worker level:

CREATE PROCEDURE proc_execute_batch(batch_id INTEGER)
LANGUAGE plpgsql AS $$
BEGIN
    -- Fetch one unprocessed batch at a time
    UPDATE task_batches 
    SET 
      started_at = NOW(),
      retry_count = retry_count + 1 
    WHERE 
      id = batch_id AND
      completed_at is NULL AND
      retry_count <= max_retries; -- This will automatically pick up failed batches.

    BEGIN
        EXECUTE handler_procedure(entity_ids);
        UPDATE task_batches SET completed_at = NOW() WHERE id = batch_id;
    EXCEPTION
        WHEN OTHERS THEN
            UPDATE task_batches SET failed_at = NOW() WHERE id = batch_id;
    END;
END;
$$;

Auto-retry made migrations resilient, automatically retrying failed batches up to their max_retries.

💻 Monitoring and Observability

All batches have clear timestamps (created_at, started_at, completed_at, failed_at) providing transparent monitoring capabilities.

We added Grafana dashboards, which made it easier to track progress and set up alerting on failures.

↗️ Flow Diagram

📈 Results:

The transition from manual to automated migrations has delivered measurable improvements:

• What used to take a developer 5-6 hours (or even more if it involved a large migration) to manage SQL queries now completes automatically. Engineers spend 90% less time on migration tasks, freeing them to work on product features.

• Previously, large migrations would cause application timeouts. Now, users experience no disruptions.

• Failed migrations that once required 1-2 hours of manual intervention and debugging now auto-recover within minutes.

🚀 Looking Forward

We've significantly reduced operational risk and improved migration efficiency at Fyle. This transformation allows developers to focus on building great features rather than firefighting risky migrations.

If this interests your appeal, this blog is all you need to become an expert in your SaaS onboarding career!

I’m Priya Dikshit, an Onboarding Specialist at Fyle for over two years. If you enjoy this blog, you might also want to check out my previous post: “A Day in the Life of an Implementation Executive at Fyle.”

Now, let’s jump into the main hustle!

The Art of Onboarding: Setting Customers Up for Success

The most powerful tech conversations begin with listening, not explaining

A smooth SaaS onboarding doesn’t start with software or tech information - it starts with the customer’s use case, their success metrics, and understanding what they want. I make it a point to understand their priorities, set up realistic timelines, and bring clarity to the scope, which helps both the customer and me stay on the same page.

Trust me - you don’t need to drop tool names or show off integrations. Setting the right use case and expectations from day one goes a long way in building a healthy, long-term bond with customers.

Checklist & Flexibility: The Unsung Heroes

Checklist - Easy, Simple, and Yet Used by Only a Few!

Yes, I was one of them until one of my teammates introduced me to this underrated, yet incredibly efficient tool called the checklist. Of course, checklists help you stay organised and free from brain clutter, but that’s just the tip of the iceberg!

Internal checklists and SOPs not only help in understanding and differentiating customer needs, but they also train you to build a powerful skill: flexibility.

A checklist might seem like a rigid tool, but it actually empowers you to be flexible - something that’s essential when building a strong onboarding foundation.

No two customers are the same, and no one checklist can cover every use case. I’ve worked with smaller clients who required more complex setups and larger accounts that demanded deeper coordination. That’s why having a system in place even a simple one can make a huge difference in keeping your onboarding process strong yet adaptable.

Tech is the Only Half the Story

Tech can solve problems, but knowledge prevents chaos

To be a problem solver, I first need to understand the problem myself before I can help someone else. Unfortunately, there’s no secret ingredient to problem-solving when it comes to helping customers.

As an onboarding executive, I act as the bridge between the product and the customer - and that means I need to have a strong grasp of the product from the ground up.

Onboarding = The Underrated Brain of SaaS

The onboarding team is often an underrated knowledge base in human form. From Product to Support, and Tech to Customer-facing - onboarding touches it all.

So, along with the technical know-how, I as an onboarding executive must bring in product expertise, customer empathy, and the confidence to handle client interactions effectively.

Speed + Empathy Wins

In my journey from an Implementation Executive to an Onboarding Specialist, I’ve learned that there are two things a customer always remembers and appreciates: how fast you responded and how understood they felt.

I’ve often received customer feedback highlighting professionalism and product knowledge - and both of these ultimately come down to how well you respond to ease the customer’s anxiety, and how well you make them feel valued.

Every account onboarding comes with its own struggles and blockers. But how you manage to solve them without losing your cool - that’s what truly makes a difference and stays with the customer long after go-live.

Life at the Crossroads of Tech, Process, and People

You Wear Many Hats - Sometimes All at Once

• Project Manager: We build timelines, take each account as a project, align stakeholders and ensure go-live doesn’t get derailed.

• Executor: Along with project managing, we individually form a one person team executing the plan to deliver the results.

• Trainer: We take complex product features and break them down into intuitive steps. You help users go from "What is this?" to "I can’t imagine working without this.”

• Troubleshooter: Field mapping errors? Integration hiccups? Export mismatches? We are the first line of defense - calmly untangling the mess and looping in the right teams.

  ---

  Growth in the Most Unexpected Ways

  Being in the Onboarding team as a beginner has helped me grow both professionally and personally. What started as a role about helping customers implement software, slowly became a role about:

• Solving Business Problems

• Understanding, growing and learning from different use cases and complexities

• Improving internal process

• Becoming the voice of the customer in product discussions

• And sometimes, even mentoring new teammates who are stepping into onboarding for the first time.

So, if you found the above interesting, appealing, and challenging enough to grow and explore this role, you might just be the right fit!

At the end of the day, onboarding is where the promise of the product becomes real and being a part of that transformation is as rewarding as it is challenging.

I hope this gave you a little more insight into our onboarding process and a little more appreciation for what our roles truly involve.

Hi, I am Sahil K., and the story I am about to write isn’t just about numbers on a pedometer. It’s about resistance, the kind that lives in your mind.

Once again, during our annual Fyle Health Challenge, I set out to break one mental wall: Could I walk 40,000 steps in a day?

🫐 The Silence Before the Steps

In May 2025, Fyle dropped another health challenge on us, and with it, a weekly series of tasks quietly escalated from ‘harmless’ to “you expect me to do what now?” A simple-sounding challenge with some not-so-simple bonus missions.

If you haven’t read already, I highly recommend reading Krupa Hebbar’s blog: The Full Circle Health Challenge - a personal journey…; it beautifully captures the essence of the entire challenge: the prep, the week-by-week chaos, the water bottles on baking scales, and the slow, glorious transformation into a hydrated, meditated, screen-conscious human.

But me? I’m here to zoom in on one absurdly specific day, one specific bonus challenge.

By Week 3, I’d already been moving daily, sipping water like a camel, and living like someone whose mobile screen had betrayed him. But then came the challenge that made me tilt my head and squint at the Slack message from Meeha:

🔥 Bonus Challenge: STEP UP - SOLO EDITION 🔥 📅 When: 6th May 2025

👣 Goal: step count for the day

⏰ Deadline: latest by 10:00 AM on 7th May 2025 in this thread.

🏆 Reward: top 10 individuals highest step count +1 bonus point each

Who’s stepping up for the MVP race? 🙋‍♀️

Simple. Dangerous. Yet Exciting.

I was in.

There’s something about a vague metric like “as many as you can” that speaks to a specific part of my brain, the part that believes walking 40,000 steps in one day is easily doable. A bonus point was on the line, and my team was counting on me. (Okay, maybe not specifically for this, but still. 😆)

🍊 A Challenge Worth Every Step

The day before the walk, I sat down to do what any rational person would do before attempting something potentially unhinged: research. 🤓 (For science, of course.)

And, here’s what I learned:

• The average person takes about 10 minutes to walk 1,000 steps. So to hit 40,000? I’d need 400 minutes of walking. “Yeah… 400 minutes. I think that’s doable, as long as I block out the rest of the day, except my working hours.”

• So I decided to divide this walk it into phases.

  • Morning walk: knock off 10K steps

  • During work: sneak in 5K steps through indoor pacing

  • Evening grind: a heavy 5 PM to 8 PM push

  • Final lap: a late 9 to 10 PM finish, if my legs hadn’t already filed a formal complaint

• And since I was taking this seriously (and also didn’t want to faint by sunset), I looked into calorie burn too. Turns out, you burn about 400 calories per 10K steps, meaning 40K would wipe out roughly 1,600 “EXTRA” calories. Now, I wasn’t trying to turn this into an accidental cut; recovery matters A LOT. So I made a plan: I’d eat my usual meals spread throughout the day, plus give myself a 400-calorie treat every 10K steps. A license to indulge in all the high-calorie foods I normally eat with suspicion: Walnuts, cashews, peanut butter, milk cream, butter, raisins, dates, figs…😋 the snack list goes on… In this way, I was still going to eat enough ‘healthy’ calories to support my effort.

Weirdly, that snack strategy turned the walk into a game: Walk 10K → Eat treasure → Repeat. 😅

But beyond all the math, prep, and peanut-butter bribes, the real goal? Not just to hit 40K steps, but to prove something I wasn't sure about yet: “Could I override the mental resistance that usually stops us far before my body ‘actually’ does?”

I didn’t fully know what I’d discover yet, but I could feel it; something was waiting for me on the other side.

And so, with a charged watch, a water bottle, and slightly too much confidence, I went to bed the night before, knowing that tomorrow I was going to walk, walk, walk, and some more walk.

🍒 The Long Walk Home (Literally)

It’s 6th May 2025, Morning 7:00 AM, the challenge began like most do with optimism, clean shoes, and a wildly underestimating brain.

• ☀️ 7:00 AM – Morning Walk (10K Steps)

  I stepped out, sun on my face, the first 10K steps felt light, almost easy. I was fresh, energetic, and kind of excited. My brain was like, “Hey, this might actually be fun. 🕺”

  It’s cute when your brain says things like that. I clocked those 10K by around 8:30 AM. So far, so good.

• 💻 12:00 PM – 6:00 PM – Work Hours + Indoor Laps (5K Steps)

  I knew I couldn’t let work hours become step-free hours. So, every chance I got between meetings, build times, or any slight pause, I was up and walking. Indoors. Like a caffeinated ghost, walking round and round in circles through the bedroom to the hall to the kitchen. 👻

  It wasn’t glamorous, but it worked.

  By the end of the workday, I had added another 5K steps, bringing the total to around 15,000.

  And this is where the real game started.

• 🌇 5:00 PM – 8:00 PM – The Big Evening Push

  This block was the main event. The make-or-break walk. I laced up again and headed out, legs slightly tired but spirit still intact. The first half-hour was smooth, I told myself, “Just keep walking, walking, and walking until it gets dark.”

  But around 20K steps, I hit that first mental dip. I was halfway done. But that meant I still had halfway to go. I had to walk almost the same distance I walked since the beginning of the day 🙀!

  Strangely, my legs were not complaining at all, but my brain started negotiating.

• 🧱 30K: The Wall

  This was the hardest stretch.

  Not physically, entirely, but more so mentally. It felt like time had slowed down. Each 100 steps took effort. My calves were a little sore, and my mind started spiraling with thoughts like “You’ve walked enough, right?”, “What if it affects your recovery?”, “What if your immunity dips?”

  This is where my brain was forcing me to stop. And honestly, this is where I usually stop.

  But that day, I decided to keep going. Just to see what would happen. I walked till 8:00 PM. Headed towards home for dinner.

• 🌙 9:00 PM – 10:00 PM – Final Lap (7K Steps)

  And just after having dinner…. I went out one last time. Legs heavy, calves tight, lower back starting to protest. But something had changed. Weirdly, the final stretch felt… quiet. Almost meditative. Maybe because I was talking on the phone with my friend 😉.

  So, I wasn’t checking my watch constantly. I wasn’t overthinking. My body was tired, but my mind had finally stopped resisting.

  Coming back home, I walked straight into the kitchen. Ate my final 400-calorie reward like I had just won a championship.
  At exactly 41119 steps | 29.11 km, I stopped. Smiled.

  And then?

  I slept like someone who had taken the entire bottle of sleeping pills…! 😴

🥝 One Bonus Point + Many Lessons

The next day, I checked the thread, and I was placed 3rd among the top 10. And had secured the bonus point for myself and my team.

But to my surprise, I was not as sore as I expected. I thought I would feel like I’d done hundreds of squats and lunges, the kind of soreness that makes stairs feel like Everest.

But strangely, I wasn’t even as sore as I usually am after a regular leg day workout.

Though I was not experiencing any major muscle soreness, I was still tired… So, I listened to my body and took a deload week, reduced my usual workout volume for that week, letting my system recalibrate.

And here’s what I realized: The hardest part isn’t the walking. It’s the idea of walking that long. That far. That endlessly. The real resistance? It lives in your head. Once you break through that mental wall, the voice that says, “This is too much,” or “you can’t keep going,” or “what ifs”, your body just follows. In reality, our body is capable of far more than we give it credit for.

My brain, like most of ours, is a mischievous little storyteller. It loves spinning worst-case scenarios, dramatic dialogues, and catastrophic conclusions. But I’ve started learning something important. My job isn’t to silence it. That’s impossible. My job is to stop taking its stories as reality. Listen, but don’t obey. Acknowledge, but don’t believe everything it says.

And somewhere between step 35,000 and 40,000, I really understood that.

🍋 A Heartfelt Thanks

Before I wrap up, I want to take a moment to send a big thank-you to Fyle for putting together another incredible health challenge.

A special shoutout to Meeha and everyone behind the scenes who made this happen. Your effort, energy, and consistency turned this into more than just a challenge.

So here’s to the journey once more,

Keep exercising, stay active, and keep pushing your limits.

See you at the next one!

Happy fitness…! 💪

Hi, I’m Pradyumna Dinni. I’m a Product Manager at Fyle, a B2B expense management software. I’ve been with Fyle for over three years, building and scaling features across different modules, contributing to revenue by building things for market expansion and saving customer churn.

Recently, we decided to deprecate two long-standing pages in our product. In this post, I’ll share how we evaluated that decision, what went into communicating it, and a practical checklist for product managers — especially those working in B2B SaaS.

Before we get started with the content of the blog post, I’d like to give some context and tell you a story, because who doesn’t like stories?

Fyle has three primary user roles:

• Spenders, employees who incur business expenses.

• Approvers, typically managers who review submitted expenses.

• Administrators (admins), who configure and manage the business account.

And internally, we call each roadmap item an initiative.

With the context set, I’d like to jump into the story and tell you my first experience with deprecation.

My first experience with deprecation

One of my first initiatives at Fyle in early 2022 was to remove a page showing all corporate card transactions for spenders. The idea was simple: since expenses were being auto-created from transactions, the page felt redundant.

But the deprecation didn’t go as planned. I lacked product context, and we missed steps like customer communication, identifying workarounds, and preparing internal teams. As a result, the initiative dragged on for nearly a year, affecting customer trust and my confidence.

At the time, I was still learning the product and understanding our customer segments. The backlash we received from customers, even in ways we hadn’t anticipated, taught me a critical lesson. Sunsetting a feature isn’t just a backend cleanup task; it’s a cross-functional decision that impacts users and teams in more ways than one.

I learned an important lesson: sunsetting a feature needs the same attention and rigor as launching one.

What have we learnt?

Fast-forward to 2025. During a roadmap discussion last quarter, our Design Head, Dhvani, curiously asked: “What about the Company Summary page?” It was a good question because we were not focusing on that page in the last few quarters, and not everyone internally had a proper idea of what that page was about! This page — one of two summary pages we had (the other being Team Summary for approvers) — was originally built to give a high-level view of expenses. But it hadn’t seen much engagement recently.

At the same time, our engineering team was migrating the frontend code from AngularJS to Angular. AngularJS to Angular migration has been a major focus for our frontend team over the last few quarters. The migration is essential for better maintainability, performance, and long-term scalability. You can read more about it from our colleagues about migrating the Chrome extension from scratch here and writing end-to-end tests for smooth migration here.

In the same roadmap planning session, our Engineering Manager, Dimple, inquired if these two pages were relevant. If so, they need to migrate these two pages to Angular. Keeping those summary pages would mean more effort for our engineers.

So we added an initiative: “Decide the future of Company and Team summary pages” on our Q2 roadmap.

The objective wasn’t to hastily pull the plug. We wanted to understand:

• Are customers still finding value in these pages?

• Are there opportunities to improve them meaningfully?

• Can the same insights be surfaced elsewhere in the product more effectively?

• And crucially, is it worth the engineering effort to migrate them to Angular?

What do these pages have?

• Company Summary (for Admins) and Team Summary (for Approvers) show a list of employees with their total amount of incomplete expenses, submitted expenses, reimbursements, and advances.

  

• These were originally built for Indian businesses during the pre-COVID era, where reimbursements and advances were common.

But our ICP (Ideal Customer Profile) today is very different — primarily US-based SMBs (Small and Medium-sized Businesses) with simpler, card-driven workflows.

Applying the lessons: Start with data

This time around, I was determined not to repeat the mistakes I made in 2022. No assumptions. No hasty decisions. I wanted to approach this with a clear head and apply a structured process — starting with data and internal insights before we even thought about deprecation.

Step 1: Usage analytics

We pulled usage data for the Company Summary and Team Summary pages over six months — from October 1st, 2024, to early April 2025. Specifically, we looked at:

• How many customers viewed these pages

• How many exports were made from each page

This gave us a quantitative sense of activity and whether these pages were still relevant in day-to-day workflows.

Usage data looked like this - Exports: Less than 50 from Company Summary and less than 20 from Team Summary. Users who visited these pages multiple times were also about the same number. Most users had only visited these pages once — likely out of curiosity rather than necessity.

Step 2: Internal conversations

In parallel, I reached out to our Sales and Customer Success teams — those closest to the end users and have a pulse on what truly matters.

• Sales Team: I asked whether these summary pages come up during demos or discovery calls with prospects. Are potential customers curious about them? Do they find value or raise questions during evaluations?

• Customer Success Team: I wanted to know if existing customers ever reference these pages during check-ins or onboarding calls. Do they request enhancements or mention pain points? Is there a problem that is solved only by these pages in our product? Also checked if any support tickets had been raised in the last 6–12 months specifically around these pages — issues, bugs, confusion, or even requests for improvement.

Before we even approached customers directly, this internal sweep helped us gather a 360° view of usage, perception, and visibility of the two pages.

The responses from the teams were alike - no recent prospect asked about these pages. No requests, questions, or feedback in recent quarters from existing customers either!

This was a strong signal: these pages were no longer essential, which is reflected in low engagement.

Between the lack of usage, low user engagement, and shifting product-market alignment, we had enough evidence to start preparing for a sunset.

Customer validation: No surprises, no regrets

Even after our internal research and data review pointed toward deprecating the Summary pages, we didn’t want to assume customer silence meant customer agreement. We wanted to be doubly sure.

So we launched two carefully crafted customer-facing campaigns:

1. In-app announcement

We added an announcement (via Appcues) directly on the Summary pages themselves, informing users that these pages were scheduled for deprecation. This ensured that any active user of the page would be aware and could raise concerns.

2. Targeted email campaign

We also emailed a curated list of users who had visited the pages multiple times over the last six months or exported data from these pages. These were our most relevant users, and we wanted to give them a heads-up — not just about the deprecation, but about what they could use instead.

Offering alternatives: The guide to employee spend summary

To support users, we created a detailed document outlining:

• Feature alternatives within Fyle that provide similar or better value.

• How to achieve the same outcomes using more modern, supported tools, like Copilot, our AI assistant, helps users query their data and navigate the product with ease, and the Spend Overview page, which visualizes trends across categories, departments, cards, and employees — offering a more actionable lens than static tables.

We linked this guide in both the Appcues banner and the email. The goal: give users time, clarity, and confidence to adapt.

Grace period and listening window

We didn’t rush. We gave users a 2–3 week buffer — clearly communicating that the pages would be deprecated on a fixed date, approximately 20 days after the announcement. This gave them enough time to:

• Explore the suggested alternatives

• Understand the rationale behind the decision

• Reach out with any objections or concerns

The result

Not a single customer objected. No new tickets. No unexpected feedback from Sales, Customer Success, or support during the entire window.

So, with all stars aligned, we finally hit the button — the Summary pages were officially deprecated.

This initiative was rolled out smoothly, thanks to our Engineering Manager, Dimple, and our Member of Technical Staff, Vaibhav. They helped me promptly with data, sharing their thoughts, and gave us time to take calls and deprecate the two pages.

Here’s the checklist:

When done right, deprecating a feature simplifies your product, respects your users, and frees up team bandwidth to build what really matters.

When done wrong, it can shake customer trust and burn valuable effort of everyone involved.

If you’re a PM facing a similar call, I hope this story and checklist help you make it with confidence.

Dimple and I worked on that 2022 initiative that didn’t go well. During our initiative reflection call recently, she mentioned that the deprecation initiative for summary pages was “as smooth as butter!”

I may have completed the redemption arc! 😇

Hello, I’m Shreyansh 👋🏼, part of the engineering team at Fyle.

Managing deployments across multiple regions has always been a critical task for us. Initially, we relied on manual processes, which, while functional, were time-consuming and prone to errors. As the product and services grew, we recognized the need for a more efficient solution and transitioned to automated deployments.

I'll share our journey from manual deployments to embracing ArgoCD for continuous delivery. We'll explore the challenges we faced, the solutions we implemented, and how tools like Kustomize were pivotal in streamlining our deployment processes.

Chapter 1: The Setup That Seemed Fine 🏗️

Let me paint the picture of where we were. We had a decent setup, or so we thought. Our services ran on Kubernetes clusters in two regions - India 🇮🇳 and US 🇺🇸. Each service lived in its own Docker container 🐳, neatly organized into different namespaces. Our GitHub workflows automatically built new Docker images whenever developers pushed code.

On paper, it looked modern and efficient. ✨

But the deployment part? That's where our modern infrastructure meets our stone-age processes. 🗿

Chapter 2: The Old Way - A Daily Nightmare 😵

Picture this: It's Monday morning, and we must deploy five services across both regions. Here's what that looked like. 😤

First, I had to SSH into our India production machine. The terminal would greet me with:

$ ssh user@india-prod-01
Welcome to Ubuntu 20.04.3 LTS
Last login: Mon Oct 23 08:15:32 2023

Then I'd navigate to our deployment repository and run our "helpful" bash script: 🤖

$ cd /opt/prod-deployment-repo
$ ./deploy default api:api_v2.1.3,worker:worker_v1.8.2,scheduler:scheduler_v3.0.1 payments payment-service:payment_v4.2.0 notifications email-service:email_v2.5.1

Look at that command. It's a monster. 👹 And this was just for one region. I had to repeat the entire process for the US region, carefully making sure I didn't mix up the versions.

The script would then use sed commands to find and replace image versions in our YAML files:

sed -i 's|api:.*|api:api_v2.1.3|g' deployments/default/api-deployment.yaml
sed -i 's|worker:.*|worker:worker_v1.8.2|g' deployments/default/worker-deployment.yaml

Then it would apply the changes:

kubectl apply -f deployments/default/api-deployment.yaml
kubectl apply -f deployments/default/worker-deployment.yaml

Chapter 3: When Everything Went Wrong 💥

We had deployed a critical fix for our api service. The command looked like this:

./deploy api api-service:api_v4.1.0

But due to a typo 🤦‍♀️ , instead of api_v4.0.1, we deployed api_v4.1.0 - an older version with a known bug.

The deployment "succeeded" but the service was running an unintended version of code.

To make matters worse, we couldn't quickly see what went wrong. There was no easy way to compare what was deployed versus what should have been deployed. We had to check each service's current image version manually:

kubectl get deployment api-service -o jsonpath='{.spec.template.spec.containers[0].image}'

The rollback process was equally manual and stressful. We had to remember the previous working versions and run the deployment script again with the correct images. 🔄

Chapter 4: The Problems That Kept Growing 📈

This wasn't an isolated incident. Our manual deployment process was a ticking time bomb with multiple problems: 💣

The SSH Bottleneck 🔒: Only certain team members had production access. When they were unavailable, deployments waited.

Command Line Nightmares 🖥️: Our deployment commands grew longer as we added services. A typical deployment command would span three lines:

./deploy default api:api_v2.1.3,worker:worker_v1.8.2,scheduler:scheduler_v3.0.1,logger:logger_v1.4.2 \
         payments payment-service:payment_v4.2.0,fraud-detector:fraud_v2.1.0 \
         notifications email-service:email_v2.5.1,sms-service:sms_v1.9.0,push-service:push_v3.1.4

One wrong character and the entire deployment would fail, or deploy the wrong versions. ❌

The Secret Update Dance 💃: When we updated database passwords or API keys, the process was brutal. First, we'd update the Kubernetes secret:

kubectl create secret generic db-secret --from-literal=password=newpassword123 --dry-run=client -o yaml | kubectl apply -f -

Then we had to manually delete all pods that used this secret:

kubectl delete pods -l app=api-service
kubectl delete pods -l app=notification-service

If the secret was used by ten services, we'd have to remember and restart all ten. Miss one, and that service keeps using the old credentials until it restarts naturally. 🤷‍♂️

Version Chaos 🌪️: Different team members would sometimes deploy different versions to different regions. We'd end up with API v2.1.3 in India and v2.1.1 in the US.

The Knowledge Gap 🧠: New team members took weeks to learn our deployment process. They had to shadow experienced engineers multiple times before being trusted with production deployments.

Chapter 5: The Breaking Point 💔

The final straw came during a major product launch. We needed to deploy updates to twelve services across both regions. The deployment took hours because:

• Two services failed due to typos in the deployment command ❌

• We discovered a config map needed updating, which required manually restarting six services 🔄

• Version mismatches between regions caused API compatibility issues 🔀

• The rollback process took another hour when we found a critical bug 🐛

Chapter 6: The Search for Something Better - Enter ArgoCD 🦸‍♂️

ArgoCD is like having a dedicated deployment assistant that never sleeps, never makes typos, and never forgets to update something.

Here's how it works: You put all your deployment configurations in a Git repository. ArgoCD watches this repository continuously. When you commit changes, ArgoCD automatically applies those changes to your Kubernetes clusters.

Think of it like this - instead of manually applying changes, you declare what you want your system to look like in Git, and ArgoCD makes it happen.

The magic happens through something called the "GitOps loop":

1. Developer commits code changes

2. CI pipeline builds and pushes a new Docker image

3. Someone updates the deployment repository with the new image version

4. ArgoCD detects the change within 3 minutes or instantaneously if you have configured webhooks.

5. ArgoCD applies the changes to all configured clusters automatically

No SSH. No manual commands. No typos.

Chapter 7: Adding Structure with Kustomize 🏗️

Along with ArgoCD, we adopted Kustomize to organize our deployment files better. Kustomize uses a "base and overlay" pattern that eliminates duplication while handling environment differences elegantly. 🎨

Here's how we structured it: 📁

The Base Configuration 🏗️

We created base configurations that contain the common parts of our deployments:

# base/api-service/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
  labels:
    app: api-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-service
  template:
    metadata:
      labels:
        app: api-service
    spec:
      containers:
      - name: api
        image: api-service:latest
        ports:
        - containerPort: 8080
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: url
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"

The base kustomization file references all our common resources:

# base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- api-service/deployment.yaml
- api-service/service.yaml
- notification-service/deployment.yaml
- notification-service/service.yaml
- worker-service/deployment.yaml

commonLabels:
  environment: production

The Regional Overlays 🌍

Then for each region, we create overlays that specify only the differences:

# overlays/india/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

bases:
- ../../base

# Image versions for India region
images:
- name: api-service
  newTag: v2.1.3
- name: payment-service
  newTag: v4.2.1
- name: worker-service
  newTag: v1.8.2

# India-specific patches
patchesStrategicMerge:
- api-service-patch.yaml

# India-specific config
configMapGenerator:
- name: region-config
  literals:
  - REGION=india
  - TIMEZONE=Asia/Kolkata
  - CURRENCY=INR

secretGenerator:
- name: db-credentials
  literals:
  - url=postgresql://india-db.internal:5432/app

The patch file handles India-specific requirements:

# overlays/india/api-service-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 5  # More replicas for higher traffic in India
  template:
    spec:
      containers:
      - name: api
        resources:
          limits:
            memory: "1Gi"  # More memory for India region
            cpu: "1"
        env:
        - name: LOG_LEVEL
          value: "INFO"    # Different log level for India

The US overlay looks similar but with US-specific values:

# overlays/us/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

bases:
- ../../base

images:
- name: api-service
  newTag: v2.1.3
- name: payment-service
  newTag: v4.2.1
- name: worker-service
  newTag: v1.8.2

configMapGenerator:
- name: region-config
  literals:
  - REGION=us
  - TIMEZONE=America/New_York
  - CURRENCY=USD

secretGenerator:
- name: db-credentials
  literals:
  - url=postgresql://us-db.internal:5432/app

Chapter 8: The New Way - Deployment Zen 🧘‍♂️

Now here's what our deployment process looks like. 🌟

When we want to deploy new versions, we simply update the image tags in our kustomization files. For example, to deploy API v2.1.4 to both regions:

# overlays/india/kustomization.yaml
images:
- name: api-service
  newTag: v2.1.4  # Updated from v2.1.3

# overlays/us/kustomization.yaml  
images:
- name: api-service
  newTag: v2.1.4  # Updated from v2.1.3

Then we commit and push:

git add .
git commit -m "Deploy API v2.1.4 to all regions"
git push origin main

That's it. ArgoCD detects the changes instantly and deploys to both regions automatically. ⚡

The Magic of Automatic Secret Updates 🔮

Remember our painful secret update process? Now it's automatic. When we need to update database credentials, we use Kustomize's secret generator:

# overlays/india/kustomization.yaml
secretGenerator:
- name: db-credentials
  literals:
  - url=postgresql://india-db.internal:5432/app
  - password=newSecurePassword123

When we commit this change, Kustomize generates a new secret with a unique name like db-credentials-a1b2c3d4. All services that reference this secret automatically get redeployed with the new version. No manual pod deletion required. 🙌

Chapter 9: The Complete Transformation 🚀

The change was dramatic. Let me show you with a real example.

Before ArgoCD: Deploying a critical security patch to all services in both regions. 😰

Time: 1 hour | Steps: 5 manual commands | People involved: 3 engineers | Errors: 2 version mismatches | 1 forgotten service

After ArgoCD: The same deployment. ✨

Time: 5 minutes | Steps: 3 Git commits | People involved: 1 engineer | Errors: 0

The Benefits Keep Coming 📈

No More SSH Nightmares: We eliminated production machine access entirely. Deployments happen through Git commits that anyone can make and review. 🔒

Version Consistency: Both regions always run the same versions because they reference the same base configurations. Version drift became impossible. 🎯

Instant Rollbacks: Rolling back became as simple as reverting a Git commit. ArgoCD automatically applies the previous state within minutes. ⏪

Automatic Secret Management: Services automatically redeploy when secrets or configs change. No more manual pod restarts or forgotten updates. 🔐

New Team Member Onboarding: New engineers can deploy safely on their first day. They just need to know Git workflows, which they already understand. 👨‍💻

Visibility: ArgoCD's dashboard shows the deployment status of all services across all regions in real-time. We can spot issues immediately. 👁️

Reduced Stress: Deployments went from high-stress, error-prone events to routine operations that anyone can perform confidently. 😌

A Real Example of the New Process 💫

Last week, we needed to deploy a new feature that involved updating four services. Here's exactly what happened:

1. Developer finished the feature and pushed code to the main branch 💻

2. GitHub workflows automatically build new Docker images:

   • api-service:v2.2.0

   • worker-service:v1.9.0

   • notification-service:v2.6.0

   • scheduler-service:v3.1.0 🐳

3. I updated the image versions in both regional overlays:

# overlays/india/kustomization.yaml and overlays/us/kustomization.yaml
images:
- name: api-service
  newTag: v2.2.0
- name: worker-service
  newTag: v1.9.0
- name: notification-service
  newTag: v2.6.0
- name: scheduler-service
  newTag: v3.1.0

4. Committed and pushed the changes:

git add overlays/
git commit -m "Deploy new messaging feature v2.2.0 to all regions

- Updated API service to v2.2.0 with new messaging endpoints
- Updated worker service to v1.9.0 with message processing
- Updated notification service to v2.6.0 with new templates
- Updated scheduler service to v3.1.0 with message queuing"
git push origin main

5. ArgoCD automatically deployed to both regions within 5 minutes ⚡

Conclusion: From Chaos to Confidence 🎯

Our journey from manual deployments to ArgoCD wasn't just a technical upgrade - it was a transformation in how we work. We went from dreading deployments to treating them as routine operations. 😌

Most importantly, we can focus on what matters: building features that help our users instead of fighting with deployment processes. 💪

If you're still doing manual deployments, especially across multiple environments, you don't have to suffer through what we did. Tools like ArgoCD and Kustomize can transform your deployment experience just like they transformed ours. 🚀

The setup takes some initial work, but the payoff is immediate and compounds over time. Your future self - and your team - will thank you for making the switch. 🙏

Hello World,
I am Timothy Alphonso and have been a part of Fyle for over 4 Years now. When I look back at my time at Fyle, it’s hard not to smile at how far I’ve come from joining as a tentative intern in the Customer Support function to now leading a team in the Customer Onboarding function. It’s been a journey of learning, unlearning, and growing both personally and professionally. God truly ordained this job, and He orchestrated the whole process of me breaking through is a testimony in itself.

Before I jump into the meaty part of this blog, I just want to share a glimpse of my initial days and how that has shaped me in my professional walk at Fyle.

The Demo That Nearly Broke Me (But Didn’t)

One of the first rites of passage for anyone who joins Fyle is to give a demo of the platform. It’s a way to showcase what you’ve learned so far, and more importantly, to get feedback on where you can improve. Sounds fair, right? Except for me, it was absolutely nerve-wracking.

I still remember that day vividly. I had little confidence speaking to an open forum (though virtually ) as I thought this was the day of the test of my knowledge and leaving a lasting first impression. My palms were sweaty, and I could barely move my cursor straight. To make matters worse, I was dealing with a shaky internet connection and had to rely on my mobile hotspot. Just as the session began, GMeet started acting up, so I made a split-second decision to move everyone to Zoom. But guess what? Zoom wasn’t any kinder. After a few more hiccups, I had to shift the whole team back to GMeet.

Ahhhh, it was chaotic. I was flustered, embarrassed, and convinced that I had completely blown my shot. I remember thinking, “This is it. They’re never going to bet on someone like me.”

But they did.

God made me find favour with Fyle, and more specifically, with my then-manager, Pratima, who took a chance on me. After my three-month internship, it was time to find out whether I would be converted to a full-time role. And by God’s grace, I was. I can’t even describe the joy I felt.

But what truly stayed with me wasn’t just the conversion—it was something Pratima said during that discussion. She told me:

“Timothy, one of the key highlights of your internship was your ability to be curious and learn. You persevered through the challenges, stayed calm under pressure, took feedback in stride, and kept improving. That’s what made all the difference.”

Those words struck a deep chord. They became a mini compass for me—something I’d keep coming back to whenever I felt lost or unsure. That demo may have been a mess, but it ended up laying the foundation for everything that came after.

The Start: Stepping Into the World of SaaS Support

I joined Fyle as a support intern, unsure of what to expect but excited about the opportunity. In those early days or if I may say “Nights” as we cater to US clients and work in the US hours at Fyle, I was handling customer tickets, responding to queries via email and chat, and acting as the first line of communication for our users. It was fast-paced, detailed work, and I loved the immediacy of helping someone solve a problem, and the customer's appreciation for it was a cherry on top.

What made the support role dynamic was the coordination it required across teams. If a customer faced a bug or requested a new feature, I had to collaborate closely with the Product and Engineering teams to get things moving. It was a crash course in cross-functional communication and problem-solving.

Another fulfilling aspect of my role was conducting admin trainings—over 100 of them! Helping admins understand the platform, watching their confidence grow, and knowing that I played a role in that transformation was incredibly satisfying.
The irony of life - the same guy who messed up his first demo went on to give admin trainings to multiple folks globally. Just a testament to the fact that even if a stone makes you stumble, God can turn that same stone into a rock and make you climb high!

The Shift: Embracing Onboarding for a Bigger Picture

After two years in Support, I found myself craving deeper customer relationships. I wanted to be a part of their journey, ensuring I help them cross the finish line in their onboarding by trying to provide an experience that leaves a lasting impact. That’s what drew me to the Customer Onboarding team.

The switch wasn’t just about a new role—it was about a new mindset. Onboarding is more proactive, project-oriented, strategic, and incredibly nuanced. Every customer is unique, with different needs, goals, and expectations. I was no longer just answering questions—I was guiding customers through their first steps with Fyle, from setting up their accounts to integrating with accounting platforms, connecting corporate cards, and everything in between.

And yes, I continued delivering admin trainings here too, because some things don’t change when you love them.

The Present: Leading with Purpose

Today, I wear two hats. I’m still an individual contributor, actively onboarding customers and ensuring their experience is smooth and successful. But I also lead a team within the onboarding function, which brings its own set of responsibilities.

Managing a team has been one of the most rewarding aspects of my journey. It’s about more than answering questions or solving issues. It’s about mentoring, challenging, supporting, and sometimes simply listening. Watching my team members grow, helping them find their rhythm, and guiding them through complex onboarding journeys—that’s where I find purpose now.

I work remotely, during US hours, and while the night shift comes with its own challenges, it has also given me the space to focus deeply, build strong processes, and connect with our global customers seamlessly.

Reflecting Back, Looking Forward

My journey at Fyle hasn’t been linear, but it has been meaningful. I started out nervous, unsure, and a tad sceptical of myself. Today, I’m confident, deeply involved in strategic work, and leading a team of brilliant people, all while continuously introspecting and seeking answers even during days when things look foggy.

The culture at Fyle has played a big part in this. It’s a place that values curiosity, initiative, and growth. I’ve always felt encouraged to try, to fail, to learn, and to keep pushing forward.

If there’s one thing I’ve learned in the past few years, it’s that growth often begins at the edge of your comfort zone. I’m grateful to have taken that first step—and every one since.

Here’s to the journey so far, and all the adventures ahead.

Thank you for reading so far, would just like to end this blog with a Bible verse that keeps me going each day -
Philippians 4:13: "I can do all things through Christ who strengthens me.

I’ll put down the challenge format as simply as I can for some context. We could get 1 point per person per day by doing 45+ minutes of physical activity that day, and 2 bonus points per person per week for maintaining a 7 day streak for that week’s bonus challenge. The weekly challenges ranged from quite simple (10 minutes of meditation) to nearly impossible (<90 minutes screen time? In this economy?). To win, each team of five had to cumulatively collect 35+ points every week, leaving little room for off-weeks (**foreshadowing**). The bonus challenges were the most exciting for me —

• (Week 1, 21st April) 💧 Hydration Nation - Drink 2.5L+ water daily

• (Week 2, 28th April) 🧘🏻‍♀️ Zen it to Win it - Meditate for 10+ minutes daily

• (Week 3, 5th May) 📵 Scroll-Free Society - Limit phone screen time to <90 mins daily

• (Week 4, 12th May) 😴 Snooze to Cruise - Sleep 8+ hours daily

The committee’s goal was sustainability and consistency — we couldn’t make up for slow days by doubling up workouts. We couldn’t win without consistency. Being new to the company, not really knowing my team, and not really sure if I could achieve these challenges, I was mostly expecting to be there for a good time not a long time. As the days and weeks went by, I noticed improvements in my health that I couldn’t ignore, and decided to document this journey for posterity!

The week before: Prep!

In true enthu-cutlet fashion, I spent the week before the challenge downloading all the tracking apps — sleep tracking, water intake tracking, meditation, screen time tracking. I set up the Minimalist phone launcher and app timers, made plans for daily long walks even on rest days. I started keeping an eye on my normal water intake (shockingly low) and screen time (terrifyingly high). I also started trying out all these apps and skipping over paywalled ones, buggy ones, and ones with overly complicated UI. I was determined to give my best shot to every single week’s bonus challenge since every single one related in some way to one of my many new years’ resolutions for this year.

Week 1: 💧 Hydration Nation

I knew this would be a tough one for me, considering my history of failure in trying to increase my water intake. Getting to one litre would be a good day for me. So I set up my baking scale, my emotional support water bottle, my 7 day free trial to WaterMinder, and made sure to track every single sip. This strategy also made sure that the challenge was at the very forefront of my mind all day every day (turns out, water bottle on a weighing scale is just odd enough that I couldn’t visually tune it out and forget). Not a single sip of water went uncounted! Looks like all I needed to win was this highly specific combination of gamification, a team to hold me accountable, a constant visual cue, the promise of prizes, and the (frankly delusional) week 1 optimism of topping the leaderboard.

Week 1 ended with the TCS 10K run (and my personal worst time which I will not be getting into). I had been incredibly sore and in a lot of pain during all my 6K and 7K practice runs in the months prior, but I was pleasantly surprised to feel zero soreness after the full 10K — something I can only attribute to this unprecedented increase in my water intake in the week prior.

Week 2: 🧘🏻‍♀️ Zen it to Win it

From the day of the health challenge announcement, I chalked this up as an easy week. As a yogi I’m no stranger to meditation, and do genuinely enjoy it and have experienced its benefits for many years. Looking ahead though, I was anticipating week 3 as my white whale.

So I started using this week to prep for week 3’s challenge. While practicing staying away from my phone I discovered an incredibly upsetting habit of constantly unlocking it to check for notifications multiple times an hour.

Our collective fracturing of attention spans has been of concern to me since I saw this Anna Akana video —

I have noticed my own attention span dwindling over the years, with reading fewer books and spending more hours on Instagram. I started this year wanting to reclaim my attention and so week 2’s meditation challenge was the perfect set up for week 3’s screen time challenge for me. I found Calm’s 7 Days of Focus series and practiced it for 10 minutes every day, first thing in the morning.

Unfortunately thanks to the low-screen-time practice, this was also the week I lost my treasured 108-day Wordle streak. Alas.

On the plus side, I did find myself naturally drinking far more water than I used to before week 1, so consistency was already showing results!

Week 3: 📵 Scroll-Free Society

My white whale at last. I had looked at my average screen time on my phone during prep week — 4 hours.

So I spent the weekend gathering six novels to read during the week, aiming to read a few pages every time I felt tempted to go on my phone. I noticed in previous weeks, my longest screen time was either on WhatsApp (with long conversations), Instagram (mindless scrolling, mainly), Swiggy (apparently I was regularly scrolling for 30+ minutes wondering what to order!?), or the alarm app (when it would ring continuously for 20+ minutes if I didn’t hear it). There were also instances of Slack or other work apps taking up time. So my plan of action was clear.

1. Keep WhatsApp conversations to a minimum, make phone calls instead (with the screen locked - did you know a phone call also counts for screen time unless you lock your screen?)

2. Set up Instagram as a restricted app on Minimalist phone launcher (to kick me out when the app timer was done. This was a game-changer!)

3. Set up similar app timers for Swiggy, Slack, Clock and other apps to prevent unintended screen use

I experimented with all these strategies over the previous two weeks to find all the edge cases (that’s how I found out phone calls take up screen time), and it paid off!

This was a tough challenge for me with many takeaways. There was definitely a big sense of disconnect — those long async WhatsApp conversations were my only way of connecting with friends with different schedules and different timezones, who I ended up speaking to far less during this week. My reduced Instagram usage also led to far fewer conversations with the friends I keep in touch with there.

On the flip side, I saw the results of one of my new years resolutions. Not wasting so many hours on Instagram gave me that many more hours to read, and I ended up reading 7 books (2.5K pages!) this week alone — my most productive reading week of the year so far! I also saw the “battery low” notification on my Kindle for the first time in many many months :)

In the long term, <90 minutes screen time may be a stretch, but 4 hours was definitely overkill. I’m hoping to find a happy middle where I can stay connected to all the things I want to be connected to, and still be able to mindfully disconnect the rest of the time. The long-term goal is to cut the doomscrolling and consume mindfully, and I finally proved to myself over this week that I could do it!

(Alas, this was the week my team slipped below the victory threshold, but it was a tough time for a few folks and so, “Que será, será, whatever will be will be” — the benefits are still free and I wasn’t planning to stop!)

Week 4: 😴 Snooze to Cruise

At last the final week of the challenge — one where we had to literally sleep our way to the finish line. This did mean sleeping by 9:30pm every single day so that I could be up by 6am to make it to yoga class. This is close enough to my usual schedule that it was quite doable, I just made sure not to make any evening plans this week so as to not upset the routine!

I spent this week reflecting and trying to reach for sustainable versions of the previous 3 weeks’ worth of challenges — meaning more water, less doomscrolling, more yoga, and self-care.

As I reflected on the previous 3 weeks of challenges, I saw how this simple points-based motivation was enough for me to make the changes I had been talking about making for months. I was able to keep up 5-6 days a week of activity every single week of the challenge. I successfully made it through all four bonus challenges, and I saw significant benefits from making the effort. Benefits that I had theoretically always known about (enough to make it to my vision board), but for the first time felt the practical effects of.

Reflections

The previously described indefatigable offsite committee (Shoutout to Meeha!) also posted some incredibly wholesome bonus challenges through the weeks — going for a walk with a loved one, having a healthy snack, putting on a face mask, and just doing something that brings joy. All things that really brought into sharp focus the recipe for a happy, wholesome, healthy life. Meeha’s weekly highlights also helped me be inspired by my colleagues’ grit and determination — through their personal bests, perseverance, and pushing of limits, I stayed motivated every week to keep at it. The energy of the committee, my team, and all the other teams was a positive spiral for the ages.

All in all, my first Fyle health challenge was a positively transformative experience, and my team may not have won but I feel like a winner nonetheless!

I’m Adreeja! I’ve been at Fyle for the last 2 years, and oh my gosh, what an incredible, wild, fulfilling ride it’s been. Major things you should know about me: I'm obsessed with Football, spend half my time in the gym, and convince myself that leg day is character-building. This sushi freak also swears by a solid plate of biriyani and spends half her money on plane tickets to travel to different places. So yes, I contain multitudes.

At Fyle, I’m a Customer Success Manager and a Partner Success Manager. I wear two hats, balancing both roles seamlessly while ensuring every interaction is delivered with clarity, confidence, and a smile.

The “Before” Era: Classic CSM Grind.

Let’s rewind a bit.

I was fully immersed in the Customer Success trenches. Honestly, that phase shaped everything I know about navigating people, problems, and priorities, and it continues to shape the way I envision building impactful, human-centered experiences for the future.

Customer Success taught me empathy. It taught me how to listen, even when answers weren’t obvious. It taught me to step up, take initiative, and be the face customers could rely on, the one they looked forward to seeing on a call. And for that, I’m genuinely glad I chose to become a Customer Success Manager.

But being a Customer Success Manager also meant:

• Back-to-back calls where a “minor issue” somehow spiraled into three escalation threads.

• Balancing multiple clients, internal syncs, churn risk alerts, sometimes all in the first half of the day.

• Designing onboarding journeys smoother than ‘my go-to playlist’ and the occasional check-ins to ensure the customers, we are in this together.

• More so, staying composed even when a high-priority email popped in on a Friday night.

But what I have learnt in all of this is that building genuine rapport with customers not only leads to stronger relationships, it often opens the door to organic upsell opportunities and glowing testimonials, both of which directly fuel revenue growth and amplify the brand trust.

So it is a lot. It is intense. But it is also real, meaningful, and weirdly exhilarating if you ask me.

This chapter taught me how to stay calm under pressure, how to think fast, and how to truly be an advocate for the people I am accountable for.
And truthfully? I love every bit of it.

Enter: The Wonderful World of Partner Success

While I found my rhythm in the world of customer goals, renewal conversations, and the occasional guessing game of “why haven’t they replied yet?”, life at Fyle took an exciting turn when I was entrusted with the opportunity to step into the Partner Success space.

And let me tell you, it felt like unlocking a whole new level of growth. Suddenly, I wasn’t just focused on ensuring customer success; I was contributing in a new direction and managing different strategic conversations with partners who bring their network, expertise, and energy to the table.

The shift was meaningful.

Customers and partners are both crucial, yet play distinctly different roles. With customers, the focus is on guiding, supporting, and ensuring they succeed with your product. With partners, it's about collaboration, equipping them, aligning on shared goals, and building the kind of trust that turns them into powerful advocates shouting about your product in rooms you’re not even in.

It is always focusing on the combined goal of “How can we win this together?”

Being a Partner Success Manager has taught me how to think bigger, collaborate deeper, and appreciate the power of scale. Being a CSM taught me the foundational skills needed to navigate strategic conversations with clarity and purpose. And I’m deeply grateful for everything I’ve learned (and continue to learn) in this role. This journey into partnerships has added a new dimension to what success looks like for me.

Wrapping It Up: One Journey, Two Hats, Endless Growth

Looking back, I feel incredibly grateful to have experienced the best of both worlds: the heart and hustle of Customer Success, and the strategy and scale of Partner Success.

Wearing both hats hasn’t always been easy (my calendar can confirm), but it’s been incredibly rewarding. One role taught me empathy, ownership, and how to be the voice of the customer. The other taught me to think more strategically, build long-term ecosystems, and amplify impact through others.

Together, these roles have helped me grow not just as a professional, but as a person more thoughtful, more collaborative, and more resilient.

So whether I’m solving an issue or enabling a partner, I know I’m playing a part in something meaningful. And honestly? Some days, I’m knee-deep in customer journeys, ensuring they’re happy, heard, and on track. Other days, I’m in enablement mode, building relations, training partners, and helping them get onboarded swiftly. So here's to the juggling act, the learning curves, and the beautiful mess that is Customer and Partner Success. I wouldn't have it any other way. I love both.

Customer and Partner Success fuel my passion for creating value. Together, they empower me to make a meaningful impact.

What I’ve Learned: I never stopped being a CSM. I Just Multiplied.

You don’t need to choose between being customer-obsessed and partner-driven. You can ‘absolutely’ be both. Success looks different depending on who’s across the (virtual) table, and it’s all about showing up, adding value, and building trust.

So if you’re ever in this in-between space, part-Customer Success, part-Partner Success, know that it’s not confusion. It’s growth. It’s you leveling up. If there’s one thing I’ve learned, it’s that growth doesn’t always come with a clear playbook. Sometimes, it looks like trying, stumbling, adapting, and still showing up with the same passion (and a slightly better version of yourself).

Because the truth is, whether I’m solving a problem or building a partnership, I’m doing what I love most: helping people succeed and having a little fun while I’m at it. So here’s to learning on the job, leading with heart.

Because at the end of the day, success isn’t just about outcomes. It’s about people, trust, and the journey in between.

And I’m just getting started.

Now, excuse me while I hop into my next call, not sure yet if it’s a partner or a customer, but I’ve got it all figured out, trust me! 😛

Intro

Hi, my name is Puru, and I'm a Customer Success Manager at Fyle. You might be wondering what exactly a customer success manager does. Essentially, I'm assigned to specific customers or accounts with the goal of ensuring they receive the maximum possible value from our product, ideally turning them into enthusiastic advocates. While not every customer will become a raving fan, the aim is always to demonstrate the product's worth. And when we do succeed in creating those passionate fans, that's where the real magic happens.

Alright, so I could kick this off with some super inspiring (or maybe a tad pretentious!) morning routine, but let's be real: I don't really have one! My day pretty much starts when most people's afternoons are winding down. I'll roll out of bed, grab something to eat, and maybe get in a light workout to wake myself up. Then, you'll usually find me casually scrolling through Slack or my emails. It's less about hardcore work at this point and more about catching up on things, or perhaps finishing off a task. Think of it as my 'pre-game show' for the night. I'm just gently getting a feel for what needs tackling first when I actually dive into work later, sort of lining up my ducks for the main event.

Later on, I'll gear up for another workout, and this is where I really go all in! It might sound a bit funny, but I honestly love that feeling of being completely wiped out afterwards – you know, when you feel like you’ve put every ounce of energy you have into it, body and soul. When you're catching your breath and your mind just goes quiet... yeah, that's my sweet spot! After that, I'm surprisingly recharged and totally ready to tackle the night.

The Night

The sun is about to light up some other part of the Earth, and I have logged in. Yes, first up: the emails! Now, this is the part where I slowly go through the emails, respond to some, and, on the other hand, note down others where I need to discuss a couple of things and get back, writing hold-up responses. This is partially where I learn how this day is going to pan out.

And you know how late-day emails can sometimes feel like they're designed to throw a comical wrench into your whole evening? It’s a classic reminder that 'certainty' is often just a fun suggestion, and honestly, that’s part of the daily adventure! It always makes me chuckle because, in a way, I totally get someone like Ethan Hunt. Now, don't worry, I'm not about to leap off any speeding trains or scale a mountain before my next coffee break! But you know how he meticulously plans out his missions, only for everything to hilariously go sideways, forcing him to improvise his way to success? That’s my workday in a nutshell sometimes: plan, watch the plan implode, and then figure it out on the fly to somehow still make it work!

There are times when you think you have an email conversation wrapped up, and all of a sudden, surprise, surprise… Yeah! Anyway, now back to the drawing board to get it under control.

Here's a key note for emails: write them diligently. Never take any email for granted. Even when you just need to say "OK" to a customer, go the extra mile – add some sauce, you know what I mean? Never, ever undercook your emails. Instead of just writing Ok write something like “Indeed, that is quite satisfactory. I find no reason to object and am content with the proposal/situation as it stands.”

So, a lot of talk about emails. Let's talk about the app I possibly use most after dating apps (just kidding; I am not on one): Slack!

Slack is where my fellow compatriots seek my assistance, suggestions, or contributions. This is where I ring the alarm bells when needed. Nah, I do not hesitate for a second to “light the beacons to call Rohan for help.”

Slack is also where I celebrate my victories (I win sometimes) and post the thing no CSM ever wants to post: The Churn!

(Churn is when a customer decides to part ways with us and requests to cancel their subscription.)

Oh boy, that word! I do not love upsells or cross-sells as much as I hate churn! It's just a bummer. The only feeling that comes close is seeing Barca lose. (Barcelona, Football Club Barcelona, the love of my life. Been a fan for 20 years.)

But you know, in these little and great defeats, you learn the most. Could you expect Jordan to win the 1989 playoff game in Cleveland without all the shots he missed and all the defeats he suffered? Do you remember that celebration, or have you ever seen it?

Yeah! Churn is devastating, but when studied with diligence, it will lead to victories everywhere.

All right, we will talk about churn more later, probably XD. In a thesis, most likely.

Cause Churn is big, REALLY BIG!, there is just so much to it. It can’t be explained with mere lines or a couple of sentences. Wait! Did I just tease my next blog?

Midnight

“The night is darkest just before Dawn.”

Alright, now for the part that really keeps us on our toes: the actual customer calls! Before diving into any of them, I always make sure to go through my notes and all the information at hand – a little prep goes a long way, right? Because, let me tell you, this is where it can get really, really dark if things go sideways! So much hinges on how that conversation flows – how ready you felt, how you handled those unexpected curveballs, whether you managed to jot down all the crucial bits, and if you truly 'got' what they were saying.

You see, these interactions are a gold mine. If you just take care of these well enough, you will make the rest of your night and the upcoming ones that much easier.

Everything is important: the doubts in customers' voices, the joys, their expectations, and their disappointments. You need to account for everything here because what you bring back from this pit hole will shape your journey with the customer.

It comes with experience for sure. Sometimes the nerves get the better of you; you know the solution, but just couldn’t give the answer at the right time.

Now, I won’t say it’s all doom and gloom after a bad call, but these instruments, when used well at times, can stop or delay that upset customer from churning (this damn word).

Also, on these calls, you understand where the customer actually stands. How much do they know about the product? How well are they using it? What are their actual feelings?

I've observed customer usage patterns that are creating significant risks, essentially setting them up for major issues if unaddressed. This is a situation that requires immediate and proactive intervention on our part. So that the customer finds the desired value in the product. Do not make your boss say, “Where were you, Ethan?” Ethan acts then and there, makes it right, or at least tries to.

Question everything, be a good listener—yes, that is very important. But do not just listen to what the customer is saying and be like, “Ok, bye ~!” No, no, haha! This is where you can extract so much value by being a 5-year-old kid who questions everything. The worst calls are those where you listen like a sitting duck and go back to your team or engineering, or product without your proper diagnosis of your own, because you will end up just going back to the customer and asking more questions. Time wasted. “We don’t have much time, Ethan!”

Yes, one thing you will never have is Time. What, you think handling a portfolio of 180 accounts is a cakewalk? I am proud of it, and I know every minute spent on one customer is exactly the number of minutes not spent on 10 others. You see how big this domino is?

The last part of midnight is “ClickUp”, raised to unblock and understand customer scenarios. This goes back to the point of extracting as much information as you can so that you can provide it to the relevant teams earlier than required and get things resolved quickly.

Dawn

“The End of Ignorance, the Start of Understanding.”

This is not the part where you relax and sink into your chair. This is where you do the most important thing about being a CSM: You document! Document everything!

You see, this is something I learned the hard way. College spoiled me—no notes, someone else completes my projects, etc., etc. I had forgotten the art of documenting, and even in my prior experience, this was not required a lot.

But you've got to document the heck out of everything you did, starting with the call notes. Keep these boys meaty, as if you are Tolkien reincarnated and about to write a 126-page chapter on hobbits and their day-to-day errands.

This is no joke. You will have multiple conversations with the customer and will take many notes. You will detect catastrophes way before and help your teammates identify them. You will learn patterns and will be able to document new cases and handle them with ease when they show up again. And yes, when you are on leave and someone else needs to take care of your stuff, it will be as easy as sharing the link.

Also, make sure you add new tasks to that task list, yeah, there is a Task list. Make sure you handle it like your life depends on it. Go through it every day and update it every time. Did I mention I handle 180 accounts? Yeah, this is how to keep all of them under control and forget no case, no escalation.

Another part of Dawn is where you start your proactive behaviour: check the metrics and become that analytics guy. Sometimes disasters and upsells are brewing quietly. Open that CS Platform for the customer 360, and start looking at things, and voila!

Not gonna lie, I love this part of my job. This is the closest to feeling like Batman—just sitting, detecting, analysing, and anticipating the customer’s next move, acting on it before they reach out to me. This goes a long way; customers feel valued.

Even those overage charge emails will come back with nice responses: “Thanks for highlighting this to us.” And where the usage is low, you will learn many things, for eg: “There is a new POC; the old one left.” See? Now you can act on it before the new POC goes through Fyle on a hectic day, dislikes a few things about it, and pulls the trigger.

Final Act

After all the hustling, it's a sensational feeling when you take a moment to reflect. I've been at this for three straight years, and I've changed my methods, tricks, and how I approach things along the way. There's such a sweet joy in those upsells and the testimonials you get. And it's an even bigger celebration when you manage to bring an account back from the brink of churning!

I really appreciate those lovely conversations with customers when they tell you how much they've enjoyed working with you, and how much they love the product and your services. Sometimes, you can even drop the wall between you and the customer and chat about cultures, cities, basketball, or films. On those good days, you log off after putting in the effort and just groove to your favourite music, feeling satisfied and ready to do it all again tomorrow.

“A feeling of perfect peace, of utter contentment. It's a silent ecstasy, a knowing that everything, in that moment, is exactly as it should be.”

So yeah, that is pretty much it. I still feel I can write a lot more, but perhaps that’s for some other time, some other blog. See, do not try to find chronological storytelling with me; that will be an insult to my cinematic sensibilities. Look at these three as three chapters that overlap and underlap each other every moment that passes by. I have segregated them on the basis of some symbolism I found in them.

I also wanna thank my very dear NA-CS team who have helped every time and have been instrumental in me getting better at my Job year after year, month after month! Thank you, folks! Really! Appreciate it! :)

So, until next time! Ciao!

As I pondered and uncovered the intricacies of a CSM’s wide area of influence, I thought this could be something professionals stepping into this role can immensely benefit from.

Hi, I’m Shreyosi, and I’ve been a Customer Success Manager at Fyle. As a CSM, I enjoy driving successful outcomes for my portfolio, and my work across the organization leads me to complex and rewarding conversations with multiple teams. What truly drives impact is approaching both the customer and internal teams’ needs with empathy, strategic thinking, and clear intent.

Over time, I’ve learned how valuable it is to collaborate effectively with teams like Product Management, Engineering/Development, Customer Marketing, Operations, Support, and Billing. Whether it is advocating for roadmap visibility or pushing for urgent fixes, CSMs often walk a fine line: timing conversations thoughtfully, balancing persistence with kindness, and always keeping the customer’s voice at the center of every decision.

So in this blog, I’m excited to share what I call the Golden Rules of Engagement and what it truly feels like to wear the Customer Success hat across teams.

With that context in mind, let’s break down the key areas we’ll explore:

Navigating Invisible Complexity Across Teams

We hold an invisible complexity in being a Customer Success Manager (CSM) while working with different departments. Often, the challenge lies in balancing alignment, advocacy, and execution, all without having direct control. We become the voice of the customer, and it requires influencing different departments, which means mastering the art of persuasion and effective data-backed storytelling, as each department has its own processes and priorities.

It’s important for us to understand how to align with them and make it onto their priority list. We need to excel at ensuring that the customer’s voice is clearly heard and effectively represented. Often, this means translating feedback into structured, actionable insights that resonate with different teams, each with their own goals, language, and priorities. Since customer success is inherently cross-functional, driving impact requires strong storytelling and seamless coordination across departments. It’s essential that we work in a collaborative environment where we support one another and align on shared goals, ensuring both customer and internal success.

Behind the Curtain: CSMs at the Core of Cross-Team Alignment

Being a Customer Success Manager often feels like guiding air traffic from a quiet control tower—essential, but often unseen. We’re the steady bridge connecting customers with internal teams, often navigating without a detailed map, but still, it is required that we chart the course. While every department runs its important race, we’re the ones weaving between customers and internal teams, sometimes at a sprint to keep everything moving smoothly and everyone aligned.

Staying in Sync: The Power of Being Up to Date

One of the most important parts of being a CSM is knowing what’s happening, both with our customers and within our product. We’re the bridge between the two, and to build that bridge in the right place, we need to be armed with the most accurate and up-to-date information. Customers’ needs evolve quickly. Their goals and challenges shift often, and our product is constantly developing to keep up with those changes. At the same time, different CSMs manage different accounts, and each customer may have unique requirements. So, it becomes essential for us to stay in the loop about new feature releases and enhancements. Sometimes, those new features don’t perfectly match a customer’s needs, and that’s where our creativity kicks in. We often come up with thoughtful workarounds or best-fit solutions to keep things moving forward. But it doesn’t stop there. Part of our job is to bubble up these insights to the product team, helping them see what’s coming up repeatedly. That feedback can spark product improvements that benefit not just one customer, but many. In short, being up to date isn’t just about knowing what’s new—it’s about turning that knowledge into meaningful action for our customers and our company.

Collaborating with Stakeholders Effectively

While many teams in the organization operate on well-defined calendars and predictable workflows, the nature of a Customer Success Manager’s role often brings unexpected shifts. Flexibility becomes part of the rhythm, and we learn to navigate changing priorities with resilience and care. We’re working with customers to ensure they get value consistently, even when a glitch or a bug has thrown the plans off course. That’s why empathy is so important at all times and in every interaction.

Usually, product and engineering teams are working on long-term goals, building features and fixes that take time and planning. As CSMs, it’s our job to represent the customer voice, but in a way that’s thoughtful and constructive. When we bring up a bug, service request, or feature idea, it helps to frame it with context: What’s the impact? How many customers are affected? What’s the urgency?

Not everything can or should be treated like a crisis, and that’s okay. Keeping our tone collaborative and our messaging clear goes a long way. It builds trust when customers know their requests are prioritized effectively and internal teams are aware that requests are carefully analyzed to accord the right priority.

From Glitches to Game Plans

When something goes wrong, our role isn’t only to sound the alarm—it’s to shine a light on what’s happening and help guide everyone towards a solution. As CSMs, we’re often the first to hear about issues from customers, whether on a call or in an email. In those moments, it’s important to stay calm, focused, and constructive. Rather than reacting emotionally, we gather and share the right details to help the relevant teams downstream.

Customers may express frustration strongly, and understandably so. Our job is to listen beyond the emotion and extract the true need. That way, we can communicate urgency and context to internal teams with clarity and accuracy, ensuring the issue gets the right attention and the customers continue to use the product without fluctuations.

Be the Adapter: Translating Needs into Action

When it comes to integrations, CSMs often wear the hat of a translator. Since most SaaS products support a variety of integrations, we’re the bridge between what the customer needs and what’s technically possible. To do this effectively, we need a strong technical understanding of the systems so we can determine how the integration should work and anticipate any potential challenges. That knowledge helps us ask the right questions internally, share clear information externally, and bring in the right people when needed. It’s also our job to set expectations early, especially when integrations involve multiple steps or longer timelines. Communicating those complexities with empathy helps prevent surprises later. And when something needs a deeper dive or a faster resolution, knowing who to loop in—and when—can make a lot of difference.

Know the Dollars Before You Talk Value

A customer’s experience with billing isn’t just transactional—it’s part of their ongoing journey with us. Whether they’re on a monthly or annual plan, they deserve a smooth, transparent experience. As customer success managers, we stay informed not to intrude but to be helpful. Understanding a customer’s billing history, subscription preferences, and any unique terms ensures we’re prepared to assist thoughtfully and accurately when questions arise.

This level of support is made possible through close collaboration with our billing and finance teams. Staying in sync on billing status, subscription structures, and plan details allows us to guide customers confidently and efficiently when they need clarity or direction.

We also keep an eye on product usage—not to micromanage, but to proactively add value. If we notice trends like unused seats or potential overages, we reach out with recommendations that help customers get the most from their plan. These conversations, when handled with care and backed by internal alignment, build trust and reinforce that we’re invested in their success and not just the sale.

Wrapping It Up: No Map, Just Mission

Most people don’t realize how many hats a Customer Success Manager wears—until things get real. We’re the ones navigating customer expectations, urgency, and emotion, often without a warning. When we appear suddenly in a thread or a meeting, it’s not chaos; it’s because something critical is on the line, and trust is being built (or rebuilt) in that moment.

Our priorities shift dynamically, but we’re still expected to get everyone to the destination on time and in one piece. We are the voice of the customer and the ear of the company: translating needs, managing expectations, and making sure the right message reaches the right team at the right time. Because at the end of the day, internal alignment isn’t just nice-to-have; it is a must-have.

Stakeholder success = Customer success.

Thank you so much for taking the time to read my blog!

—THE END—

Have you ever hesitated to update your website’s core technology, perhaps anxious about unexpected bugs, downtime, or the daunting task of retraining your team on new tools? Worried that one wrong step could stop leads from flowing and negatively impact your business? We felt exactly the same before transitioning our large, static Jekyll site (a static site generator that builds websites from plain text and templates) from Vue 2 to Alpine.js. This blog shares our journey, challenges, solutions, and why this move turned out to be one of our best decisions yet.

Hi, I'm Shreyash Mogaveera, a Web Developer 1 at Fyle. Our website is a large static Jekyll project with multiple resource pages, pricing pages, and 7–8 different lead generation forms, each with distinct purposes. Over time, our Vue 2 setup became an outdated and heavy overkill for these straightforward functionalities. Our team decided it was time for a change to improve performance and maintainability. This successful migration was a team effort. Garvit Singhal significantly contributed by writing validators and preparing extensive end-to-end tests to ensure our forms worked perfectly. My manager, Abhishek Jain, supported and trusted our initiative, guiding us through this transition. Shubham Bhansal was invaluable in thoroughly testing and identifying any potential breaking changes alongside our manager.

Why We Chose Alpine.js

Before settling on Alpine.js, we explored other options, including continuing with Vue 2 or upgrading to Vue 3, using Stimulus.js, or even adopting plain vanilla JavaScript.

• Vue 3: We considered upgrading from Vue 2 to Vue 3 for better performance and long-term support. However, the migration was non-trivial and would require a large refactor across the site with minimal real benefit for our use case.

• Stimulus.js: Stimulus offered a lightweight and modern approach, but its syntax felt too abstract for our team, and it lacked the reactive simplicity we liked about Vue.

• Vanilla JavaScript: We briefly considered refactoring everything into plain JavaScript. However, that would have meant writing and maintaining a lot of boilerplate code, which would defeat our goal of simplifying the site.

In contrast, Alpine.js provided exactly what we needed:

• Lightweight (~10KB)

• Reactive and declarative like Vue: Alpine allows you to bind data to the DOM and automatically update the view when data changes, using intuitive syntax similar to Vue’s directives (e.g., x-data, x-model, x-show). This makes it easy to build dynamic UI interactions without the complexity of a full framework.

• Easy to integrate with our existing Jekyll + Bootstrap setup

• No build step required

Alpine allowed us to enhance interactivity directly within our HTML without the need for complex frameworks or heavy tooling. It was the perfect balance of simplicity and power for our static site.

Our website initially used Vue 2 extensively, coupled with plugins like vue-validator. Although powerful, Vue 2 brought heavy JS bundles, complicated dependencies, and maintenance challenges. Alpine.js emerged as the ideal solution: lightweight, easy to learn, and perfect for enhancing our static site’s interactivity.

Preparing for Change

Before diving into the migration, I spent around a week researching various alternatives to replace Vue 2, finally deciding on Alpine.js. We performed a thorough audit of our site to map out which components were using Vue and what our priorities should be:

• Resource pages: Targeted first, we replaced Vue-based components and toggle buttons in the pricing page and resource pages within 2–3 days.

• Forms: Around 7–8 forms were interconnected and bundled into a single large JS file. We realized forms had to be migrated together.

We decided to proceed carefully, starting with simpler elements to build confidence.

Step-by-Step Migration

The entire migration project was broken down into careful, manageable stages over the span of approximately three weeks. We intentionally started with non-critical components to test our Alpine.js implementation and to minimize risk. After the success of the first stage, we tackled the more complex and business-critical elements.

Our initial targets were the resource page components and toggle buttons on the pricing page. This stage only took 2–3 days to complete. However, the form migration, which affected 7–8 highly interconnected forms across our website, took approximately 1.5 weeks. We spent extensive time on staging with thorough manual and automated testing before pushing to production.

All along, we maintained detailed documentation of our progress and collaborated closely using our internal team tools to ensure smooth communication and transparency. In hindsight, this phased and well-documented approach was one of the key reasons why our migration went smoothly.

Step 1: Easy Win with Sliders

Our slider component was the simplest, isolated, and safest starting point. We converted this component smoothly using Alpine.

Step 2: Forms - The Critical Challenge

Forms were our biggest concern. They generated leads essential to our business. We couldn't afford mistakes, so thorough testing and fallback mechanisms were mandatory.

Step 3: Simplifying Navbar

Previously, our navbar was overly complex, mixing vanilla JavaScript, jQuery, and Vue 2. We entirely rebuilt it using Alpine, drastically reducing complexity.

Results and Improvements

The results after switching to Alpine.js were immediate and impressive. Not only did we successfully modernize our front-end architecture, but we also achieved measurable technical and business outcomes:

• JavaScript bundle size: Reduced by more than 50KB, resulting in faster load times.

• Performance improvements: Lighthouse scores improved dramatically, jumping from 75 to 97.

• Developer experience: We reorganized our large monolithic JavaScript file for forms into three distinct files: constants, reusable functions, and form logic. This made the codebase more modular, readable, and maintainable.

• Selective JS loading: By embedding Alpine logic directly into the page HTML, we were able to ensure that JavaScript only loaded on pages where it was required. This drastically reduced unnecessary script loading and improved the experience for users on pages without interactive forms.

• Improved team collaboration: This migration also encouraged stronger communication and documentation practices within our team, which will benefit us in future projects.

ref:- https://pagespeed.web.dev/analysis/https-www-fylehq-com-pricing/1wfb042zjn?form_factor=desktop

Challenges and Lessons Learned

• One of the biggest differences we noticed between Vue and Alpine was around deep reactivity. In Vue 2, when data inside nested objects changes (for example, user.profile.name), Vue automatically updates the DOM. Alpine, on the other hand, only tracks changes at the top level of x-data objects. It does not automatically watch nested objects for changes. This limitation made complex form state tracking more challenging in Alpine and required us to structure our data and validation logic more carefully. While Alpine’s shallow reactivity helps keep it lightweight and fast, it does demand a different approach when working with deeply structured data.

• Our initial plan to migrate forms one by one had to be abandoned. A deeper analysis of the codebase revealed that all form logic was tightly centralized in a single file, forcing us to migrate every form at once.

• Forms needed extensive testing to avoid business disruptions.

• Navbar's transition required thoughtful planning and refactoring.

Tips for Your Alpine.js Migration

Here's a quick checklist to ensure a smooth migration:

• ✅ Audit thoroughly: Identify all Vue-dependent components clearly.

• ✅ Start small: Migrate simple, isolated components first to gain confidence.

• ✅ Prepare validators: Create or identify reusable custom validation methods.

• ✅ Extensive testing: Set up end-to-end tests for critical elements like forms to avoid disruptions.

• ✅ Fallback strategy: Always have rollback plans ready for high-impact migrations.

• ✅ Train your team: Ensure your development team is comfortable with Alpine's syntax and concepts beforehand.

Conclusion

Transitioning to Alpine.js was a significant yet rewarding endeavor. The website now loads faster, developers find it easier to maintain, and our business didn't experience any disruptions. If your static website needs a lightweight, powerful way to manage interactions, Alpine.js could be your ideal solution.

If you're considering lightening your website with Alpine.js, I highly recommend it. It's been a game-changer for us. Have questions or want to share your own migration story? I'd love to hear from you!

This situation is not unique to Fyle; it occurs with every product that grows and evolves. The only way to address these inconsistencies and usability gaps is through continuous effort, tackling them one by one, day by day, until the experience feels seamless.

This is when the Swachh Web-App Abhiyan was born. The initiative focused on cleaning, refining, and fixing the app, bringing everything together under one unified experience. The goal was simple: to make the Fyle web app feel like a single, well-thought-out product rather than a collection of separately built components.

The Genesis! 🐣

In December 2024, I had just wrapped up an initiative on the mobile app, ensuring that stats displayed exact amounts instead of rounded values. I was ready for my next challenge, and that’s when an opportunity came up to work on a high-impact cleanup of the Fyle Web App — addressing inconsistencies in UI elements like buttons, shadows, spacing, font sizes, border radii, sentence casing, and fixing functionality bugs in edge cases.

At first, the fast-paced nature of the initiative felt overwhelming. I had never worked on anything similar before. However, it also presented the opportunity to work on almost every part of the Fyle Web App, which is a rare chance. I have always enjoyed organizing things (creating order out of chaos 😅) and ensuring seamless experiences. This initiative felt like the perfect opportunity to achieve that on a larger scale. It was about giving the web app the polish and consistency it deserved. And so began my journey with what we fondly call the Swachh Web-App Abhiyan.

The Plan and Roadmap! 🗺️

Once the initiative kicked off, the first step was to take stock of everything that needed fixing. But instead of a structured approach with documentation, we opted for something simpler: a thread-based system.

Each part of the web app or usability issue had its dedicated Slack thread. A thread would list all the inconsistencies, broken UI elements, or functionalities that needed attention.

Some threads were obvious: buttons that looked different across pages, mismatched font sizes, and uneven spacing. Others were more intricate, requiring deeper discussions across engineering, product, and design teams, like refining the receipt viewer experience or reworking the sidebar colors. Then there were the frustrating ones, tiny functional breaks that surfaced only in edge cases, often going unnoticed until a user stumbled upon them. None of these were showstoppers on their own, but together, they added up to a fractured experience. Clicking around the app, you could sense the lack of cohesion like a house with rooms designed by different architects, each following its blueprint. It wasn’t bad, but it wasn’t seamless either.

Each of these threads became a to-do list of sorts, with multiple items being tackled simultaneously by the team. With three engineers (Aditya, Amit, and me) actively working on different parts, we needed a way to keep track of ownership without overcomplicating things. That’s when we introduced a fun little system of emoji markers. Each of us picked a unique emoji to tag our threads: 🐬 for me, 🆎 for Aditya, and 🐧 for Amit.

This tiny addition made it much easier to glance through threads and instantly know who was working on what. It also added a bit of personality to the otherwise fast-paced and intense process.

Day by day, thread by thread, the cleanup was in full swing.

The Cleanup Begins! 🏁

As the weeks passed, we tackled a variety of issues, ranging from subtle inconsistencies to more visible usability problems. Some fixes were small but impactful, while others required a complete revamp of certain components. Here’s a breakdown of the key improvements we made and their impact:

🔸 Bringing Sentence Case & Language Consistency

Across all platforms, Web App, Mobile App, Chrome Extension, Outlook Add-in, and Integrations, we standardized text formatting, sentence casing, and tone to create a more polished and professional look.

With over 1,000+ files containing UI text, manually reviewing and fixing them was out of the question. Instead, we wrote a custom script to scan all HTML templates, extract placeholders and text within tags, and automatically apply the correct casing. But automation alone wasn’t enough, we had to manually review and test every change to ensure accuracy.

What seemed like a simple fix turned into a 2-3 week effort, but in the end, it made a huge difference.

Impact: A cleaner and visually consistent experience that improved readability across the app.

🔸 Making Tables (List-views) More Intuitive

Tables are at the heart of financial management, so we focused on making them more flexible and user-friendly:

✔ Drag-and-drop support for reordering table columns.

✔ Column resizing to let users adjust views as needed.

✔ Info icons with contextual explanations where relevant.

Impact: Enhanced control over data visualization, making it easier to customize tables for different workflows

🔸 Subtle UI & UX Enhancements That Made a Big Difference

Sometimes, it’s the little things that make an app feel refined. We focused on polishing micro-interactions and visual elements:

✔ Smooth icon animations for a more delightful experience.

✔ New sidebar colors to improve visual hierarchy.

✔ Standardized hover states for buttons, close icons, and search fields.

✔ Redesigned export dialog for better usability.

Impact: A more polished UI that just feels better and consistent.

🔸 Dashboard Enhancements

We made dashboards more insightful and intuitive:

✔ Added team expense stats for approvers in web and mobile apps.

✔ Introduced a payment mode filter in My Expenses for better tracking.

✔ User greetings on the dashboard to add a personal touch.

✔ Improved corporate card management, making it easier to add and view cards from zero-state screens.

Impact: Smarter dashboards and better data visibility, making financial tracking even easier.

🔸 UI Cleanup & Visual Consistency

A layer of polish involved modernizing outdated visuals and fixing inconsistencies across the app:

✔ Redesigned login & logout pages with a fresh, modern & minimalist look.

✔ Replaced outdated illustrations with cleaner, more relevant visuals.

✔ Fixed the Receipts/PDF Viewer, ensuring images and PDFs display in the correct aspect ratio.

Impact: Visually modernized app that feels more intentional.

While these were some of the major changes, the full scope of this initiative was much larger. In total, we tackled, fixed, and closed 125 threads, each addressing a specific inconsistency, bug, or usability issue.

Each fix, no matter how small, contributed to making Fyle a cleaner, more seamless, and more delightful experience.

Learnings & Achievements! 🏆

This initiative was intense, fast-paced, and filled with valuable takeaways. Beyond just shipping features and fixes, I learned how to work smarter, collaborate better, and make decisions with impact. Here are some of my biggest learnings:

🔸 Staying Aligned Across Teams Matters

With multiple teams working in parallel, I realized the importance of keeping track of everything happening across different initiatives. Following different channels like product_bulletin, product, and product_design kept me updated on ongoing discussions. Since we were rolling out multiple changes, I also monitored ongoing Angular migrations and joined several Q1 initiative channels to ensure our work didn’t conflict with other improvements.

🔸 Zooming Out for Better Consistency

I learned to step back and take a broader perspective when making changes. Instead of implementing fixes in isolation, I started checking:

✔ How similar components were built in other parts of the app.

✔ If variable names and content followed a consistent pattern.

✔ Whether UI elements are aligned with our design system and language.

This approach helped maintain uniformity across the app and improved both the codebase and UI in the long run.

🔸 Debugging & Problem Solving Got Easier

Compared to last quarter, I became more efficient at breaking down problems and finding solutions. Debugging, which sometimes felt tedious, became much simpler and structured.

🔸 Realization: Reviewing PRs is Harder Than Raising Them

One unexpected realization was that reviewing pull requests (PRs) can be tougher than raising them. When you're writing code, you have complete context, you know why you made certain choices, what trade-offs you considered, and how everything fits together. But you don't have that luxury when reviewing someone else’s PR.

I found myself spending more time understanding the "why" behind the changes rather than just checking the code itself. Some PRs touched multiple parts of the app, making it even harder to verify their impact without deep-diving into different flows. This experience made me more mindful of changes before requesting a review. I started:

✔ Reviewing my PRs before assigning them.

✔ Adding detailed comments explaining why I made specific changes.

✔ Ensuring PRs were well-structured to reduce unnecessary back-and-forth discussions.

✔ Provide screenshots or screen recordings for UI-related updates.

These practices not only accelerated the review process but also enhanced the readability and maintainability of the codebase.

🔸Backing Arguments with Real Data

Instead of relying purely on intuition, I learned to validate my decisions with actual customer data. Whether it was running DB queries or analyzing tracking metrics, these data-driven approaches made decisions:

✔ More objective and impactful.

✔ Easier to justify when discussing with product or design teams.

🔸 Automation = Time Saver

I saw firsthand how automation reduces manual effort and improves efficiency.

✔ Writing scripts to scan and fix inconsistencies.

✔ Adding linting rules to enforce standards automatically.

✔ Configuring end-to-end (E2E) tests for better reliability.

✔ Setting up GitHub workflows to streamline development.

Each of these saved time, reduced errors, and made the overall development process smoother.

Wrapping It Up! 🙇

The Swachh Web-App Abhiyan wasn’t just about fixing inconsistencies, but it was about rethinking how we build, refine, and maintain a product.

This initiative pushed me to zoom out, debug more efficiently, and collaborate across teams. More importantly, it reinforced a key lesson: Great products aren’t built overnight; they’re the result of continuous iteration, attention to detail, and a shared commitment to quality.

And the best part? The app feels cleaner, more intuitive, and more delightful to use, which was the goal all along.

A huge thanks to Abhishek and Dimple for this opportunity, Aditya for reviewing countless PRs, Amit for all the help with the development, Hari, Sri Ashwathi, and Dhvani for their lightning-fast & well-thought-out designs, and Meeha for all the product and content support. This was truly a team effort! 🎉

Looking ahead, the goal remains the same: keep improving, keep refining, and never stop making things better.

Happy Coding! 🧑‍💻

As the sun dips below the horizon and the city begins to settle into sleep, my world is just waking up. At 6:30 p.m., my inbox lights up—tickets start pouring in, chats begin pinging, and threads need urgent replies. Each notification is a little puzzle waiting to be solved: some simple, some stressful, and sometimes, the kind that completely takes over my night.

I grab my coffee, take a deep breath, and settle in—ready for whatever comes next

Finding My Rhythm

At first glance, my job might seem pretty straightforward—answering tickets, handling live chats, leading training sessions—but a lot more is happening under the surface. Since I work remotely from India, my nights run from 6:30 p.m. to 2:30 a.m., and sometimes even later when things get intense. It’s a fast-paced mix of multitasking, staying calm under pressure, and genuinely caring about helping people. Every ticket is someone reaching out for help, so empathy isn’t just a soft skill here—it’s everything.

The first hour always hits the hardest. It’s like hopping onto a moving train—you’ve got to find your rhythm quickly! I prioritize fast, scan through what needs my attention, juggle admin trainings, chat queues, and internal syncs. No two nights look the same, so being mentally prepped is key.

The Art of Managing Tickets and Real-Time Support

Tickets feel like an ever-evolving puzzle. One minute I’m deep into crafting a detailed reply, the next I’m jumping into a live chat where an admin’s stuck with reimbursements and needs help right now. I have to immediately switch gears, dive into the issue, resolve it with care, and then watch their thank-you message pop up. It might be a small win, but in the middle of a hectic shift, it feels big. Urgent issues come first, but there’s always the chance that a new critical ticket might pop up right when I’m in the middle of something

Time management is everything. Between digging into tricky problems, replying with clarity, and always staying kind and patient—it takes real focus. It’s fast-paced, a bit chaotic, but incredibly rewarding when a customer’s issue gets resolved and they’re back on track.

When Things Get Real: Escalations

Then come the escalations. Picture being in the middle of a live chat and getting alerted to a p0 escalation (That’s short for “Priority 0,” meaning something critical has broken, and it’s affecting multiple customers.) — it is a situation so critical it demands all hands on deck. In SaaS, especially with US clients, these issues tend to hit in the dead of night here in India. These moments test your ability to remain calm under pressure. I have to pivot quickly, coordinate with different teams, and work to resolve the issue while ensuring the customer feels supported every step of the way.

Everything else is pushed aside as I move swiftly, connecting with engineers, gathering details, updating the customer—all while making sure they don’t feel left in the dark. These moments are high-pressure, where precision matters more than ever. Staying calm is not just a skill; it’s a necessity.

Some nights, these crises stretch my shift beyond the usual log-off time. But when the dust settles and the issue is resolved, the relief in the customer’s response makes every lost hour worth it.

Training That Actually Empowers

It’s not just about reacting to problems either. A big part of my work is leading admin training sessions. These aren’t just boring walkthroughs—we’re helping people actually understand and own the product. The goal is to leave them feeling confident and independent, ready to navigate everything on their own.

Each session takes planning—prepping custom content, guiding them through hands-on demos, and anticipating their questions. And then there’s that moment during a session where something clicks for them—that’s the magic. There’s something really special about watching someone start off unsure and overwhelmed, then slowly find their footing and become a total pro. That shift—that spark of confidence—it’s one of the most rewarding parts of my job. It reminds me why I love doing what I do.

Mentoring Interns - Buddy culture at Fyle!

We always talk about the beautiful culture at Fyle, a very wholesome aspect of this process is that every new joinee at Fyle has a buddy! Every new joiner gets paired with someone experienced to help them settle in, kind of like the Army’s buddy system. Buddying is an extremely time-consuming and tough task. It requires patience and resilience to no extent. You have to get on countless huddles and help the interns with numerous questions.

Now, I help new interns and junior team members find their footing. Guiding them through tricky tickets, stepping in when they get stuck during live chats, and reassuring them that they’ll get the hang of it. Because support isn’t just about answering questions—it’s about building a team that thrives together.

Mentorship helps build a real sense of team spirit. Watching interns go from unsure and nervous to confident and capable feels amazing—and it naturally brings all of us closer. It’s less about just doing a job and more about growing together and having each other’s backs.

Behind the Scenes: The Invisible Work

This job often feels like steering a ship quietly through a storm. The outside world might not see everything, but what we do behind the scenes is critical. While customers might simply see a swift response, behind the scenes, there's intense preparation, careful thought, and empathetic understanding. Each interaction, whether through a chat or admin training, is shaped by countless unseen moments—times I've paused to recheck information, collaborated with teammates to find the perfect solution, or attended a learning session to enhance my expertise.

There are product updates to keep track of, weekly learning sessions to attend, and cross-team collaborations to ensure we’re aligned. Every night, I absorb, adapt, and translate technical complexities into clear, actionable solutions for our customers. These aren’t things customers ever see, but they’re the reason the support feels seamless.

Clocking Out with Pride

By the time I’m wrapping up, the sky’s starting to lighten. The rush is over, my inbox is clear (for now), and things feel a little more peaceful. I log off knowing that someone, somewhere, is having a smoother day because of the work I did tonight.

It’s not glamorous. It’s not always easy. But it’s real. And it matters. It’s a strange kind of satisfaction—the kind that comes not from being in the spotlight, but from knowing that, behind the scenes, I’ve played my part in keeping things running smoothly.

We might not build the product, but we make sure people trust it. And sometimes, that’s the real magic. Not all heroes wear capes—some wear headsets and quietly save someone’s day without ever being seen.

In this post, I’ll share how we revamped 50+ emails, from research to rollout, plus a few moments that had me both laughing and screaming into the void. Let’s dive in.

What Makes Email Development So Different from Web?

At first glance, email development looks straightforward, just some HTML and CSS. But once you dig in, you realize it’s a whole different world with its own set of rules. Here’s what makes it so unique.

🎯 Web Browsers vs Email Clients

• While web browsers (like Chrome, Safari, and Firefox) are designed to render modern websites using shared standards and engines, email clients (like Gmail, Outlook, and Apple Mail) are built specifically to display email messages, often with their own rendering engines and rules.

• Because email clients prioritize security, performance, and offline support, they don’t fully support modern web features.

🎯 Emails Don’t Run, They Render

• JavaScript is entirely blocked by email clients as emails are meant to be read and they’re designed to display content safely.

• Even Google’s AMP for Email which enables interactivity like carousels and forms, avoids JavaScript. Instead, it uses custom components that keep things lightweight and secure.

🎯 Image Handling & Spam Sensitivity

• Many email clients including Outlook, Gmail (web), and Yahoo Mail block images by default for security reasons. That’s why it’s important to have fallbacks.

• Unlike web pages, emails must pass through spam filters before reaching an inbox. Even a messy code structure or certain keywords can raise red flags.

This blog by SendGrid lists common triggers and tips to stay out of the spam folder.

🎯 Debugging Emails Is Like Archaeology 😆

• Unlike browsers, email clients offer no inspect tools or dev consoles. Debugging is manual - testing across platforms and learning through iterations.

• Any mismatch in data, or small code flaw can break rendering, clip content, or prevent delivery entirely.

In short, Email development comes with its own set of constraints, quirks, and unexpected behaviors. But once you master the rules, you can craft reliable, beautiful emails that shine across (almost) any inbox.

Development Journey in Three Phases

By now, you’ve seen how strange and specific the world of email development can be. Here’s how my own journey unfolded, not just a task, but a full-on expedition that involved planning, coding, testing, (lots of testing), and cross-team coordination.

🧭 Phase I: Laying the Groundwork - Research & Setup

Before jumping into code, I took a step back to understand the unfamiliar world of email development. With so many hidden quirks and client-specific behaviors, the real work started with research before the code editor.

🔹 Email Client Compatibility Investigation

I started by creating a document that mapped out all the CSS properties we planned to use, from layout and typography to spacing and checked their compatibility across major email clients.

The doc included:

• A compatibility matrix of planned CSS properties - referenced from caniemail.com

• Notes on known quirks or workarounds from resources like EmailOnAcid and SendGrid.

• A client / device usage breakdown based on internal metrics to prioritize what mattered most

This reference became my north star throughout the development and honestly, it saved me more times than I can count.

🔹 Dev Environment & Email Rendering Pipeline

The next step was to understand how the email system worked end to end. So I dug up the backend codebase and traced the full notification flow: from the triggering event to the final payload sent by our email service.

The email flow isn’t just one service, it spans across multiple layers of our system, each responsible for a part of the process. Here's a simplified view of how it worked:

• User Interaction triggers an event in the system like submitting a form or completing an action or this can be a scheduled job.

• This kicks off the business logic for email generation workflow, which is picked by the notification service.

• The email layout and content are then generated by dedicated services. These services communicate via APIs to compile the final email structure.

• Finally, the email is passed to our mail delivery provider SendGrid, which handles delivery to the user’s inbox.

I spun up private branches across the repos involved, deployed them to a test environment, and manually triggered emails through the UI. This setup gave me room to experiment and tweak things with real data in place.

⚙️ Phase II: Development – Designing, Coding, and Fighting Bugs

In the world of emails, modern layouts take a backseat. Instead, good old <table> based HTML is your most reliable companion. But even with those time-tested techniques, there’s no guarantee things will just work.

The development phase was full of surprises. Here are a few of my favorite (and confusing) discoveries.

🔹 The Gmail Box Shadow Mystery

Somewhere between “this style doesn’t work” and “why does it work there but not here,” I stumbled upon this:

Gmail App supports box-shadow but only for non-Google accounts.

It would’ve made sense the other way around, right? Support it on Gmail accounts to promote your own product. When I first found this, this is exactly how I felt about Google for making my life difficult:

There’s no straight answer to why it works this way, but this deep dive by Rémi Parmentier does a great job breaking it down to possible causes.

🔹 The Invisible Character That Broke Gmail

At one point, Gmail started clipping my email for no reason. Hours of diffing later... the culprit? A single invisible Unicode character, pasted straight from Figma was enough to push Gmail’s 102KB rendering limit.

Now I double-check every copy block and never trust pretty text.

🔹 Outlook Fixes (Witchcraft Edition)

Outlook Classic uses Microsoft Word as its rendering engine. Yes. Word for email rendering. The only way to overcome layout mishaps is to use MSO (Microsoft Office) specific conditionals and write supported code inside:

<!--[if mso]>
  <table>
     <!-- Outlook-specific content -->
  </table>
<![endif]-->

These conditionals help prevent layout shifts and keep things aligned in Word-based clients without affecting others.

To add to the fun, Outlook doesn’t support rounded corners natively, you’ll have to lean on an ancient markup language called VML (Vector Markup Language) to implement those stylish buttons.

🔹 That Sneaky Line of Preheader Text

We added custom pre-headers, the snippet that shows up next to your subject line in the inbox preview, but nowhere inside the email. It helps set context and improve clarity.

It’s also great for deliverability: a well-crafted preheader can reduce the chances of getting flagged by spam filters. Small touch, outsized impact.

🚀 Phase III: Release & Final Validation

This is the part where the emails leave the comfort of dev and meet the real world. And unlike web pages, emails don’t come with hotfixes, once they land in a user’s inbox, you’re done. So we took testing and validation seriously.

🔹 Testing Across the Inbox Universe

Once things looked good technically, our product and design teams jumped into staging and took QA to the next level. From 1px misalignments to button spacing issues on narrow screens, they caught what tools couldn’t. We tested our emails across ~8 different clients and multiple types of devices. The list included:

• Gmail (web, Android, iOS)

• Outlook (Office 365, classic desktop)

• Apple Mail (macOS, iOS)

• Yahoo, Proton Mail, and a few others

Every client had its own rules. What looked perfect in Apple Mail might break in Outlook, or wrap oddly in Yahoo.

RIP Windows Mail 🪦

We’d done a fair bit of development and testing with Windows Mail in mind. But just as we were wrapping up, Microsoft announced they would retire the app starting Jan 2025, in favor of a new Outlook version which uses a modern rendering engine.

It was one of those classic dev moments: you spend days battling platform-specific bugs, only to find it’s being phased out.

Still, the effort wasn’t wasted, many of the same fixes helped with older Word-based clients too.

Conclusion

Revamping 50+ emails was more than just a design refresh, it was a deep exploration into the wonderfully weird realm of Email Development. From balancing old-school <table> layouts, to debugging invisible Unicode gremlins, writing Python code for content, and validating every last edge case - it was a journey.

A huge shoutout to my colleagues, Hari from the design team and Jishnav from the product team for the beautiful visuals, thoughtful copy, and going all-in on QA. Their contributions made these emails not just reliable, but on-brand and delightful.

To summarise:

If you’ve ever wrangled Outlook conditionals, hit Gmail’s 102KB limit, or found joy in a perfectly aligned <td>, I’d love to hear your story too.

Thanks for reading and may your emails render clean, your tables nest true, and your box-shadows always show up 📨✨

Hey! I’m Aniruddha Shriwant, a Software Engineer at Fyle, where I’ve been working for the past two years. In this blog post, I’m going to share our approach to ensuring smooth migration from AngularJS to Angular, particularly by writing End-to-End (E2E) tests for our legacy codebase.

My colleague Aditya previously shared how we kicked off this migration journey in this blog. Do check it out for additional context!

The Challenge: Testing Legacy Code

As mentioned in Aditya’s blog, our migration journey from AngularJS to Angular has been ongoing for the past two years. Now, we’re finally approaching the finish line - reaching the most critical and complex areas of our web application.

However, we encountered a significant challenge at this stage. Our legacy AngularJS codebase didn’t have any unit tests in place, which meant every feature or change had to be manually tested. This made it extremely difficult to confidently migrate critical sections without introducing regressions or missing subtle functionalities.

To tackle this effectively, we needed a reliable way to ensure that nothing broke during the migration.

Why Choose End-to-End (E2E) Testing?

Typically, in the testing pyramid, unit tests form the base and are prioritized because they’re fast, inexpensive, and provide immediate feedback. End-to-End tests, on the other hand, sit at the top - usually fewer in number due to their higher cost in terms of execution time, CI resources, and maintenance complexity. However, when dealing with legacy code that lacks existing unit tests, this pyramid gets inverted. Here, prioritizing E2E tests makes sense, since they quickly verify critical user interactions, offering immediate assurance that essential functionalities aren’t broken during major changes like migrations.

With this perspective, we decided E2E tests were our best bet to confidently manage our Angular migration.

Our Approach to Writing E2E Tests

1. Documenting Feature Requirements (FRs)

   We started by exhaustively identifying and documenting every feature and edge case supported by our legacy codebase. Since we previously had no documentation, this step became crucial. These documented FRs served as a reliable source of truth, something we could always refer back to.
   My colleague, Aiyush, played a pivotal role here - his extensive experience at Fyle helped us clearly document critical functionalities and, in many cases, understand why certain features existed in the first place. By the end, we had nearly 150 feature requirements documented!

2. Grouping FRs into User Testing Scenarios

   Given the large number of FRs, individually writing an E2E test for each wasn’t practical. Instead, we grouped related FRs into cohesive user flows and scenarios. This helped us efficiently cover multiple FRs within fewer tests. Moreover, grouping improved our Continuous Integration (CI) pipeline efficiency, as E2E tests are relatively slower to execute and consume more CI resources.

3. Writing the E2E Tests

   Finally, we translated these user scenarios into E2E tests that closely simulated real-world user interactions.

   With this structured approach, we ensured comprehensive and practical coverage of our most critical user journeys.

Few best practices we followed while writing E2E tests

Here’s how we implemented some best practices to write reliable, maintainable, and effective E2E tests, We used Playwright - a testing tool that helps automate browsers and simulate real user interactions, making it ideal for writing reliable End-to-End (E2E) tests.

• Prioritizing User-Centric locators

  • When writing E2E tests with Playwright, there are generally two ways to select DOM elements:

    • Component or CSS selectors:

      // Clicking the save button using a component-specific CSS class:

      page.locator('.save-cta').click();

    • User-facing selectors (recommended approach):

      // Clicking the save button as a user would identify it:

      page.getByRole('button', { name: 'Save', exact: true }).click();

  • We strongly preferred the second approach—user-centric locators—because they’re less brittle. Component or CSS-based selectors tend to break easily whenever component names or CSS classes change, which was common during our migration from AngularJS to Angular. By contrast, user-facing selectors rely on elements the user actually sees and interacts with, making our tests more resilient and maintainable.

  • This approach aligns directly with Playwright’s recommended best practices.

• Grouping and Structuring Tests into User Flows

  Given our extensive list of Feature Requirements (FRs), individually testing each scenario would have been highly inefficient. To address this, we grouped related FRs into coherent user flows, typically covering 7-8 FRs within a single test scenario.

  Example scenario: testing various form inputs tests in one flow:

  • Verify that specific input fields appear by default.

  • Check for mandatory field errors when attempting to save without providing the required details.

  • Ensure dropdown fields load and display default selectable values.

  • Confirm date input fields validate correctly, especially for future dates.

  • Validate that configurable labels and placeholders correctly reflect user-defined settings.

• Minimizing API Mocking to Prioritize Real Integrations

  Playwright provides an easy mechanism to mock API requests. However, we consciously minimized the use of mocks in our E2E tests. Instead, we prioritized genuine integration with our backend services

  This approach allowed us to:

  • Test the complete flow: from creating real backend resources (such as projects with category restrictions) to verifying user interactions like saving an expense form.

  • Detect issues early: Not just frontend regressions, but also subtle backend bugs or unexpected behaviour changes in APIs.

  Of course, there were cases where mocking became necessary—for instance, when backend APIs operated asynchronously or had slow responses. In these scenarios, selective mocking allowed us to maintain test stability and speed, effectively balancing ideal test conditions with practical constraints. By thoughtfully minimizing mocks, we increased our confidence that the E2E tests genuinely reflected the end-user experience, capturing issues across both frontend and backend layers.

Early Impacts and Anticipated Benefits

Through our structured approach to E2E testing, we’ve already started seeing some encouraging results:

• Detecting existing bugs early: We’ve uncovered a long list of hidden issues while writing our E2E tests—bugs that would have otherwise gone unnoticed until production. 😛

We’re also excited about the future benefits that we anticipate from continuing this strategy:

• Rapidly identifying missed behaviours or unexpected changes introduced during migration.

• Greater confidence in releasing major updates to the most critical parts of our web app.

• Achieving a smooth, successful transition from AngularJS to Angular, finally allowing us to say goodbye to our legacy codebase! 👋🏻

I’d love to hear about your experiences—have you faced similar challenges or successes with E2E testing in legacy code migrations? Let me know!

Special thanks to my teammate Suyash for closely collaborating on writing these E2E tests and helping us confidently prepare for a smooth migration! 🚀

Hi folks, I’m Sayonee from Fyle’s product marketing team, and I’ve had the fortune of being a part of some of these awesome treks. In this blog, I’ll take you through how we go about planning these treks, why we do them, and why they’ve become so important to us!

Since 2022, we’ve covered all these treks a few times around Bangalore ⛰️:

• Skandagiri – Famous for its stunning sunrise views and a steep final stretch.

• Kaiwarabetta – We’ve done this so many times that, at this point, it’s Fyle’s own hill.

• Makalidurga – A mix of boulder hopping and history, with fort ruins at the top.

• Savandurga – One of Asia’s largest monoliths and an absolute leg burner. (This is where Sholay was shot, btw).

• Chinagabetta – A shorter yet steep trail that ends with a little rock climbing.

• Kodachadri – A tough forest trek with stunning peak views.

Here are some pictures of the stunning views (and us) over the years:

As a Bangalorean, I thought I knew the city and its surroundings well, but I had no idea so many incredible treks were just a short drive away. Discovering these trails has been an unexpected but amazing experience, and I’m glad I did.

In the past few months, many of these trekking spots around Bangalore were closed, which meant we had to take a break from our usual climbs. But now that they’ve reopened, we’ll be sure to go back for more.

How It Happens

This is how it usually goes down:

1. Someone drops a message on Slack.

2. A few brave souls (usually 4-6 of us) decide that, yes, climbing a mountain before dawn sounds like a fantastic idea.

3. We sort out cars, tickets, and a meeting point - all while questioning our life choices.

4. And then we actually climb. 🧗

The Fyle Trek Experience

Every trek starts the same way: an absurdly early meeting time at 3 or 4 AM. Groggy but determined, we get into cars, turn up the music, and spend the two-hour drive discussing everything from work gossip to deep existential questions (or just vibing in comfortable silence).

By 6 AM, we reach the base and start the climb. Some treks are easier than others, but we always stick together. Yitzhak (from our people team) leads the way, occasionally doubling back to check on folks who get stuck (the people questioning all their life decisions mid-trek). The group energy is always high—whether we’re helping each other over steep rocks or laughing at someone who insisted, “this should be easy” five minutes before gasping for breath.

And then, the best part: reaching the top. That, along with getting some pretty pictures, makes everything worth it. The quiet, the endless sky, the view, the sunrise - there’s nothing quite like it. 🌅

One of our colleagues, Kamalini, had very generously packed and brought us yummy food on a few treks, and needless to say, we devoured it at the peak.

The Descent (AKA, "When's Breakfast?")

Climbing down is faster but much less patient. The sun is up, we’re sweaty, and everyone just wants to eat. Tradition dictates that we stop for breakfast on the way back, whether it’s at Adyar Ananda Bhavan or Ajantha, we always find a place to refuel.

By the time we finally get home, the exhaustion hits, but so do the happy hormones. Kicking off the day with a trek has a way of making everything else feel easier.

Why This Has Become a Fyle Tradition

Somehow, these treks have become a part of Fyle’s culture. There’s always a group of people ready to say yes to testing their endurance, and pushing themselves a little more each time.

There’s something about waking up before dawn, challenging yourself physically, and spending the morning outdoors that sets the tone for the rest of the day. It’s the kind of thing that seems like a terrible idea the night before but always ends up being worth it. And it’s safe to say, we’ll keep doing more of it.

It’s not just about the treks, though. Over time, staying active together has become second nature, whether it’s these early morning climbs or our regular Saturday runs at Cubbon Park, where a group of us gathers to clock in a few kilometers before heading for breakfast.

At Fyle, there’s space for every kind of adventurer - paragliders (yes, we have those), mountaineers (these too 🤯), swimmers, runners, and more. With so many people pursuing different outdoor passions, there’s always something exciting happening, and everyone is encouraged to find what they love.