It would be an understatement to say that your tech stack makes or breaks the project. Not only does a tech stack determine the kind of app that the team will be able to build in the end, but it also directly impacts the efficiency with which the developers build it. Thus, it was imperative for the core team at Fam to curate an effective yet dynamic tech stack.

When we started building Fam, the core team had experience in developing backends with Django and Android apps. We chose what we were most comfortable with and knew it was a scalable framework having been used by Instagram (until ~2015), Pinterest, Disqus, and Creative Commons.

Languages

GoLang - Most of our backend code is in Go. Go is an open source programming language that makes it easy to build simple, reliable, and efficient software. We use Gofiber and net/http as our Go web framework for HTTP server implementations. For micro-services communication, we leverage gRPC with Google's gRPC libraries for efficient, language-agnostic communication between services. Our Go projects follow a hexagonal architecture, enabling modular design and easy evolution of services over time.

Python - Python's design philosophy emphasises code readability with its notable use of significant indentation. Additionally, we use static code checking tools like flake8, black, isort to have consistent patterns. Now you can even code in notepad and still, that won’t break PEP8 guidelines xD.

Java - Mostly used by Android App, Java is a High Level, class-based, object-oriented programming language that is designed to have as few implementation dependencies as possible.

Kotlin- Kotlin is a cross-platform, statically typed, general-purpose programming language with type inference. Along with Java, most of our Android app is now written in Kotlin.

Swift - Swift is a general-purpose, multi-paradigm, compiled programming language developed by Apple Inc. and the open-source community.

Dart - Dart is a modern, client-optimized programming language developed by Google. Dart offers a familiar C-style syntax, sound type safety, and a rich standard library that makes development efficient and predictable. Its asynchronous programming model with async/await and support for isolates enables smooth concurrency handling, making it a versatile choice for both frontend and backend development using the Flutter framework.

TypeScript - TypeScript is an open-source language developed by Microsoft that builds on JavaScript with static typing and modern ES features. It compiles to plain JavaScript, ensuring full compatibility across browsers and Node.js. We use TypeScript across both frontend (React, Next.js) and backend (Node.js) projects for its type safety, better tooling, and maintainable, predictable codebases.

Frontend

⚡️ Website

We use Next.js to power our frontend applications. Next.js offers built-in server-side rendering (SSR), static site generation (SSG), and automatic code splitting, enabling fast, scalable, and SEO-friendly web experiences. Our frontend is deployed on Cloudflare Pages, leveraging its globally distributed edge network, automatic builds, and seamless CI/CD integration for reliable and lightning-fast performance.

🤖 Android

Fam’s Android app started as a native Android app in 2019 with majority of it built with Android specific frameworks using Java/Kotlin. The majority of views were written in XML, and there’s been an active effort to shift towards Jetpack Compose and hybrid technologies.

The app is built using MVP/MVVM architecture relying on popular libraries like OkHttp, Retrofit, Glide, EventBus, Chucker, RxJava, & Kotlin Coroutines for its functioning.

Overtime, as the requirements grew more complex, we wanted to explore modern day hybrid solutions like Flutter, Kotlin Multiplatform & PWAs in order to deliver at a faster pace and maintain unified a codebase across our apps. Currently, our mobile apps utilize KMP for some of their core business logic handling and the plan is to further expand our dependence to KMP layer for more platform-level usecases.

Today our apps are structured in a way that we can deliver full-fledged features either in native Android or as a PWA or using Flutter. This architecture, today grants us the power of choice to deliver any feature using the framework of our choice.

🍎 iOS

Fam’s iOS app began its journey in 2019, built natively using Swift and SwiftUI. The app architecture primarily relies on the Reactor pattern to manage state and business logic, along with the Coordinator pattern to handle navigation and flow between screens.

As the product and its requirements evolved, our team started exploring cross-platform technologies to accelerate development and achieve greater code sharing across platforms. This led to the adoption of Flutter, which we integrated into our native iOS application using the Flutter Engine. This hybrid setup allows us to seamlessly embed Flutter-based views and features alongside our native SwiftUI components. Over time, we’ve continued to enhance this integration, giving our iOS app the flexibility to deliver complete features either natively in SwiftUI or via Flutter — depending on what best fits product requirements.

Today, this architecture empowers us with the same “power of choice” across iOS as on Android — the ability to develop and deploy features using the most suitable framework for each use case, whether it’s SwiftUI or Flutter.

Some of the libraries that we depend on include: Reactor, SwiiftUIX, Merge & Swallow

🧶 Web Apps / PWA

Our Progressive Web App (PWA) — is the primary web layer of Fam, built with React, TypeScript, HTML, and CSS. It powers multiple sections of the app organised through modular routes for rapid iteration.

Designed for fast development and deployment, the PWA runs seamlessly as a web view inside both Android and iOS apps, combining the agility of the web with the reach of native platforms. This flexibility allows us to roll out updates instantly, significantly accelerating gamified feature delivery across the Fam ecosystem.

Deployed on Cloudflare Pages, it benefits from global edge delivery, automatic builds, and reliable CI/CD pipelines, ensuring a smooth, scalable, and high-performance user experience.

🧩 Kotlin Multiplatform

As Fam evolved, maintaining shared logic between Android, iOS apps became critical. Kotlin Multiplatform was adopted to unify our core business logic and reduce redundancy across platforms. Its adoption began with a specific feature where it encapsulates critical operations such as data handling, networking, caching, and business domain logic, and integrated seamlessly between Android and iOS apps. It relies on libraries like Ktor for network operations, Kotlinx Serialization for data parsing & others.

Going forward, our goal is to expand the KMP layer to include more platform-level use cases, enabling even greater code reuse, consistency, and development velocity across the Fam ecosystem.

🐦 Flutter

Fam’s Flutter journey began as part of our effort to accelerate feature delivery and maintain a consistent user experience across platforms. Flutter was introduced to power select modules within the app that required rapid iteration, pixel-perfect UI, and cross-platform parity. Currently it powers important flows like entire KYC flow, Home Screen Tabs & others.

We currently maintain a single codebase for all Flutter flows with parts running inside our native Android and iOS apps using separate flutter engines. We are managing multiple flutter engines inside our apps using flutter engine cache and engine grouping.

Our flutter codebase leverages popular libraries and frameworks such as get for state management & dependency injection, dio for networking, cached network image & flutter svg for image loading.

Backend

Frameworks

🥃 GoFiber & net/http (Go)

Our backend services use both GoFiber and net/http, depending on the service requirements. Some services use GoFiber for its fast routing, lightweight API, and built-in middleware support, while others use Go’s standard net/http package for its simplicity, robustness, and direct integration with the Go ecosystem. This flexibility allows us to choose the right framework for each service’s performance and architectural needs.

⚙️ Asynq (Go)

Asynq is a simple, reliable, and efficient background task queue library built in Go. It enables distributed processing of asynchronous jobs with support for both real-time execution and scheduled task management. Asynq uses Valkey as its message broker, offering low-latency task dispatching and strong reliability guarantees.

We use Asynq to offload long-running or non-critical workloads — such as notifications, data syncs, and background processing — from our core request path, improving response times and system scalability. We deploy these workers on Kubernetes and with appropriate horizontal pod autoscaler (HPA) configurations our workers scale horizontally based on the backlog of tasks pending

🔮 gRPC

We use gRPC for high-performance, language-agnostic communication between microservices. Built on top of HTTP/2, gRPC enables efficient request multiplexing, bidirectional streaming, and strongly typed interfaces defined through Protocol Buffers. This allows our services to communicate with low latency and minimal overhead while maintaining clear contracts and backward compatibility across service boundaries.

🛠️ Temporal

We use Temporal for reliable task orchestration across distributed systems. Temporal allows us to define workflows as code, providing built-in reliability, state management, and automatic retries. This ensures that multi-step and long-running operations execute exactly once, even in the face of failures. By leveraging Temporal, we achieve guaranteed execution, simplified error handling, and greater resilience across our services.

🗿 Django + Django Rest Framework

Our first monolithic services were built in Python using Django and Django REST Framework (DRF). Django is a high-level web framework that promotes rapid development and clean, pragmatic design — it handles much of the heavy lifting so developers can focus on business logic instead of boilerplate. DRF, on the other hand, made it easy to build and serve complex JSON-based REST APIs for our frontend applications.

Most of our early user-facing services were written in Django, but as our scale grew, we began transitioning toward a microservices architecture — gradually decomposing the monolith into smaller, domain-focused services written in Go, each optimized for its specific responsibility.

We’re continuing this migration journey and will soon share our learnings from moving out of the monolith — stay tuned for that upcoming blog!

📜 Celery

Celery is a simple, flexible, and reliable distributed system to process vast amounts of messages while providing operations with the tools required to maintain such a system. It’s a task queue with a focus on real-time processing, while also supporting task scheduling. Celery workers are also deployed on Kubernetes and with appropriate horizontal pod autoscaler (HPA) configurations our workers scale horizontally based on the backlog of tasks pending.

Databases

🦣 PostgreSQL

We have highly relational data so choosing RDBMS was an obvious choice, Django has really good ORM support for Postgres as well. We heavily rely on its transactional properties. We are using PostgreSQL to store most of the data. It's deployed via AWS RDS - Postgres managed service.

🫀 Valkey

You may have heard of it as the in-memory key-value store, but Valkey is truly the Swiss Army knife of NoSQL databases. Valkey provides a rich set of data structures — including strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes, and streams — making it highly versatile for a wide range of use cases. It supports built-in replication, Lua scripting, LRU eviction, transactions, and multiple levels of on-disk persistence, while offering high availability through Sentinel and automatic partitioning via Cluster mode. We run Valkey in cluster mode using AWS ElastiCache, ensuring scalability, fault tolerance, and low-latency access across services.

🤖 DynamoDB

We use Amazon DynamoDB as our NoSQL database for applications that require single-digit millisecond latency at any scale. It’s a key-value and document database that delivers high performance with seamless scalability. DynamoDB enables Z-axis scaling, allowing us to horizontally partition data across multiple shards to handle massive workloads efficiently while maintaining low latency and high availability.

💡Clickhouse

We use ClickHouse as our high-performance analytical database across multiple domains. It powers our data warehousing workloads, supports our fraud and risk management engine for near real-time analysis, and stores HTTP access logs for request-level analytics and observability. Being self-hosted, our ClickHouse deployments give us fine-grained control over performance tuning, data retention, and resource allocation, enabling efficient large-scale data processing while maintaining operational flexibility.

Queues & Messaging

We use multiple queues and messaging platforms to support service decoupling, scalability, and real-time event processing:

🛖 MSK (Managed Kafka)
A managed Kafka service that powers our distributed messaging and high-throughput event pipelines. We use MSK extensively for event-driven communication between microservices.

🚡 WAL Queues
We use Write-Ahead Log (WAL) queues in Postgres to guarantee reliable and exactly-once message delivery between services. Our open-source project, Factlib , provides a structured and fault-tolerant framework for producing events to Kafka using WAL semantics. It ensures that messages are durably persisted before being dispatched, enabling recovery and replay in case of service or network failures, and maintaining end-to-end delivery guarantees across our event-driven systems.

🧀 SNS
Used for push-based notifications and alerting. It integrates with CloudWatch to send alerts to our internal alerting service, which escalates issues to the on-call team for rapid response.

Analytics

🥷 Metabase

Metabase is the fastest, easiest way to share data and analytics inside your company. We can connect many DB sources and it creates beautiful graphs for us. It makes it easy for non-technical users to ask questions about data. Using its alert feature we get notified if something is wrong with the data or application. Like successful transactions rate or any failure with external services.

🤠 Mixpanel

MixPanel is a great product analytics tool to understand user behaviors, Segment integration with Mixpanel pushes data there.

🎯 CleverTap

CleverTap helps us craft contextual and personalized campaigns to engage our users through Push Notifications, In-app Messages, SMS, Web Push, Emails, WhatsApp, Facebook. It provides comprehensive campaign management and user journey analytics.

🎩 Data Warehouse

We operate multiple microservices, each with its own independent database. To enable centralized analytics and reporting, we built a data pipeline that continuously ingests data from these individual databases into our ClickHouse-powered data warehouse. We use a self-hosted deployment of the open-source project PeerDB to capture Change Data Capture (CDC) events from all databases and stream them into ClickHouse in near real time. Internally, PeerDB reads Write-Ahead Logs (WAL) from source databases, stores the data in Amazon S3, and then ingests it into ClickHouse. The entire architecture is orchestrated using Temporal, ensuring reliability and fault tolerance throughout the pipeline.

The entire system is self-hosted, giving us full control over performance, scalability, and data governance.

We’ll be publishing a detailed blog soon on how our data pipeline has evolved — from initial prototypes to a fully self-hosted, scalable architecture.

Automation

🤖 N8N

n8n is a fair-code licensed extendable workflow automation tool, you can automate all kinds of the mundane processes using this as we live in API world you can connect pretty much anything. For example, we use it to automate push notifications to customers when they win rewards or when there’s a special campaign, such as a Diwali sale.

🛠️ Appsmith

Appsmith is our open-source alternative for building internal tools and admin panels. We use this for specific features that are not available in Metabase. We can set up webhooks here which helps in automation. This is also used internally by the customer support teams to make changes to user data as per customer’s request.

Observability

🎩 Sentry

Sentry helps us catch and fix those elusive, once-in-a-blue-moon bugs. It’s an application monitoring and error-tracking platform that enables developers to diagnose, fix, and optimize application performance with deep context. We use a self-hosted deployment of Sentry running on Kubernetes, giving us complete control over data and integrations, though their SaaS offering is also available. In addition to error tracking, we leverage Sentry for distributed tracing, allowing us to monitor request flows across services and identify performance bottlenecks in real time.

📊 Grafana & VictoriaMetrics

For metrics and observability, VictoriaMetrics as our high-performance, Prometheus compatible time series database, and Grafana as our visualization layer. This stack allows us to monitor infrastructure health, visualise trends, and set up alerts for critical events.

📔 Logs

We use Loki and Amazon CloudWatch for centralised log collection, viewing, and filtering across our services.

In addition, we ingest HTTP access logs from Cloudflare and various other providers into ClickHouse for analytical querying and long-term storage. This allows us to efficiently analyse traffic patterns, identify anomalies, and derive insights from large volumes of request data while keeping operational logging lightweight and real-time. This Clickhouse is self-hosted on an EC2. Checkout Logverse which enables us to ingest these logs into Clickhouse in a reliable way.

Infrastructure & Platform

💇🏼‍♀️ Github Actions

We use GitHub Actions to automate our CI/CD workflows, including build, test, and deployment pipelines. It enables consistent and reproducible automation across projects, helping us maintain high development velocity. Our Forgejo setup is fully compatible with GitHub Actions, allowing us to run self-hosted runners and leverage the same workflow syntax for seamless integration between code hosting and continuous delivery.

🐳 Docker

Docker takes away repetitive, mundane configuration tasks and is used throughout the development lifecycle for fast, easy, and portable application development. Most of our codebase is containerized, allowing it to run anywhere.

🚟 AWS ECR

Amazon Elastic Container Registry (ECR) is a fully managed container registry that makes it easy to store, manage, share, and deploy our container images and artifacts anywhere. Since we use Docker, we needed a place to store private images so what could be better than ECR which tightly integrates with other AWS services.

☸️ Kubernetes

Kubernetes is our choice for orchestrating containerized workloads and services. With its declarative configuration and automation capabilities, Kubernetes simplifies deployment, scaling, and management of our microservices architecture. We utilize features such as namespaces, config maps, secrets, and horizontal pod autoscaling to ensure resilience and operational efficiency. Our environments run on managed Kubernetes services for easier upgrades, monitoring, and integration with AWS resources.

🪃 Amazon Elastic Beanstalk

AWS Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker on familiar servers such as Apache, Nginx, Passenger, and IIS. All of our core services are containerised and deployed using Beanstalk.

🦉 Nginx

Nginx is a high-performance web server that can also be used as a reverse proxy, load balancer, mail proxy, and HTTP cache. We mainly use it as a reverse proxy in front of open source projects, next server, python WSGI server. It handles SSL and sending responses to the clients.

🪙 Gunicorn

Gunicorn 'Green Unicorn' is a Python WSGI HTTP Server for UNIX. It's a pre-fork worker model. We observed that most of our traffic is IO bound so we changed its worker pool to gevent and monkey patched psycopg.

🌐 Envoy Gateway

Envoy Gateway serves as our modern reverse proxy and load balancer, simplifying the deployment and management of microservices. It plays a key role in setting up isolated development environments, enabling each feature branch to be independently tested by developers and QA teams as part of our Git Flow process. Envoy also performs authentication and authorisation checks at the initial stage of the request lifecycle, ensuring only validated requests reach downstream services. We also are able to maintain route and user level rate limiting so that our APIs don’t endure abuse from attackers.

☁️ Cloudflare

We use Cloudflare as our primary DNS management and security platform, leveraging its built-in WAF and DDoS protection to safeguard our infrastructure. Several Cloudflare products play a key role in our stack:

• Cloudflare Pages: Hosts our React-based web applications and websites. It removes the overhead of managing deployments while providing built-in CI/CD pipelines for fast and reliable releases.
• Cloudflare R2: Serves as our CDN-backed object storage for media assets — including button images, website visuals, and other static content.
• Cloudflare DNS: Handles all DNS management and routing for our domains.
• Cloudflare WAF & DDoS Protection: Monitors traffic patterns, blocks malicious activity, and provides detailed security analytics and reports.

🍀 Pulumi

Pulumi helps adopt infrastructure as code automation, combined with tried and true software engineering practices. One of the projects we are working on is to create a data pipeline and data warehouse. We are leveraging this to create and destroy AWS infrastructure.

👋 k6

k6 is our modern load testing tool that sends load to web applications and provides comprehensive performance metrics and latency distribution summaries. It's developer-centric and provides excellent insights into application performance.

Deployment

Our deployment workflow is built around a common foundation — we build Docker images, push them to Amazon ECR, and then deploy them across environments using simple, automated scripts.

For AWS Elastic Beanstalk applications, deployments are executed via the AWS CLI, while for Kubernetes-based services, we trigger ArgoCD to handle the rollout and synchronization. Both processes are automated and abstracted behind a web interface powered by Script Server , allowing developers to trigger deployments for their respective services with a single click.

This setup provides a unified, low-friction deployment experience across environments, while maintaining safety, consistency, and operational control.

OSS

👻 Ghost

Ghost is designed for ambitious, professional publishers who want to actively build a business around their content. We use it for publishing blogs and sending newsletters to subscribers. There are built-in XML sitemaps, Google AMP pages, canonical tags, optimised URLs, Facebook Open Graph tags, support for Twitter cards and clean semantic markup for better SEO. Ghost is really fast, you can get >95% score on google page speed easily. We have self-hosted this on EC2.

👾 OAuth2-Proxy

A reverse proxy and static file server that provides authentication using Providers (Google, GitHub, and others) to validate accounts by email, domain, or group. OAuth2 proxy adds an authentication layer in between for projects like ListMonk and N8N

📮 Postal

We use Postal as our self-hosted mail server for sending and managing transactional and system emails. Postal provides full control over email delivery, routing, tracking, and bounce handling, allowing us to maintain high deliverability without relying on third-party email providers. By self-hosting Postal, we gain flexibility in configuration, better cost efficiency, and the ability to tightly integrate email workflows with our internal systems.

🦅 Netbird

We use NetBird as our self-hosted, zero-trust networking solution to securely connect infrastructure and services across environments. NetBird simplifies private network management by creating an encrypted peer-to-peer mesh overlay using WireGuard, enabling seamless and secure access between cloud resources, on-prem systems, and developer machines without relying on traditional VPN setups. This setup enhances security, reduces operational overhead, and provides fine-grained access control through identity-based policies.

🧊 SonarQube

We use SonarQube as our self-hosted platform for continuous code quality and security analysis. It helps us maintain clean, reliable, and maintainable code by automatically scanning repositories for bugs, vulnerabilities, and code smells during the CI/CD process. SonarQube enforces consistent coding standards across teams, provides detailed quality metrics, and integrates seamlessly with our development workflow to ensure that code meets our quality gates before being deployed.

📓 Forgejo

We use Forgejo as our self-hosted Git service for managing source code, pull requests, and CI/CD pipelines. Forgejo provides a lightweight, reliable, and privacy-focused alternative to cloud-based Git platforms, giving us full control over our repositories and development workflows. It integrates seamlessly with our automation tools and internal systems, enabling secure collaboration, efficient code reviews, and streamlined deployment processes across teams.

Conclusion

There are some key takeaways that the core team has realized through the journey:

• Choose a tech stack that you are most comfortable with.
• Picking the right tool for the right job is equally important.
• If you are facing a problem there is a good chance that an open-source solution exists for it.
• Go with the solution that works now and easily modifiable when required. We like to keep things simple.
• Automate business processes and repeating workflows.
• Consult with an expert when in doubt.

Keeping these things in mind will help you lay a solid and thoughtful foundation when you begin developing a project. It only makes things easier if critical thinking and decision-making have been done beforehand when choosing from the plethora of options available. However, in the end, experimentation and dynamism is key to arranging your tech stack.

Found this article interesting and want to share your insights? Drop in an email at tech@fampay.in!

From Design to Code: Building Homelander

The plan was ready; now it was time to build. This part covers how we implemented Homelander—rewriting core logic in Go, optimising database access, and rolling out the ETag and CDC systems that made the 50 ms home feed possible.

Target Implementation

As our system continued to scale, we realised that our existing Django-based architecture was no longer meeting performance demands—especially for the highly dynamic home screen rendering process. To address these challenges, we built a new Golang service called Homelander, which directly accesses the monolith’s database while focusing only on the specific tables required to render Home.

Yes—by traditional service boundary standards, this was a design violation. Homelander directly querying another service’s database is generally discouraged, as it couples two systems at the data layer. However, in our context, this trade-off was intentional and pragmatic. The home feed’s performance needs were extreme, and duplicating or syncing data through additional APIs or event pipelines would have added unacceptable latency and operational overhead. By carefully scoping Homelander’s access to read-only queries on a well-defined subset of tables, we preserved data consistency while unlocking the performance required to meet our sub-50 ms goal.

Rewriting Logic from Django to Go

We decided to migrate the core logic from Django to Golang for several reasons:

Improved Concurrency Handling:

We utilized singleflight to handle concurrent API requests that require the same database query. This significantly reduced the number of duplicate calls hitting our database.

Controlled Database Access:

By using pgx v5 directly (instead of an ORM or generic SELECT * queries), we gained tight control over query execution. It also allowed us to map database rows directly into Go structs, avoiding redundant memory copies that occur in ORM layers.

In-Memory Context Store:

We built an in-memory store that attaches both user and common data to the request context. Once a piece of data is fetched from the database, it’s cached within the same request lifecycle to avoid redundant lookups — for example, when multiple downstream calls require the same user record. This eliminates one class of N+1 query issues, particularly those caused by repeated access to identical objects. However, it doesn’t replace the need for explicit prefetching or batched queries when fetching related entities (e.g., fetching all users linked to a set of payments).

Performance Boost:

Golang’s concurrency model and lower overhead (compared to Python/Django) naturally delivered faster response times.

Validating the New Service

Before fully switching to Homelander, we ran extensive tests to ensure the service was functionally equivalent to the old system:

• Limited Rollout: We initially released Homelander to a small percentage of users to verify its behavior in a production environment. We made use of cloudflare DNS which helped in rewriting the hostname to homelander’s URL that way without any app update we were able to understand if the APIs were backward compatible and worked properly with the existing app builds.
• Parity Checks: Over the course of a day, we compared Homelander’s responses to those from the Django service for 500,000 users. This helped us confirm that both systems produced identical results for real-world scenarios.

After confirming business logic parity, we rolled out Homelander to all users at full scale. The results were immediately impressive:

• p90 Server-Side Latency of ~49 ms: A major improvement over the previous 2–4 second response times. This figure reflects backend processing time, not end-to-end user-perceived latency, which can vary based on network conditions and client-side rendering.
• Reduced Load: Singleflight and in-flight caching dramatically cut the volume of redundant database queries.
• With this our monolith service (Westeros) also needed less EC2s to host the servers and the buffer of resource limits increased for redis and postgres both.

Implementing the ETag System

Following Homelander’s successful launch, the final Etag logic has to be implemented:

1. ETag Generation:
   • On each request if we do not get the ETag from the client, the server generates an ETag which is actually a ULID
   • We added a new header key: Accept-Etag if this is sent with true by the client then only homelander will attach an etag and return the tag as well. This helps us roll it out in a controlled manner and understand if system is working as intended.
2. Time-Based Invalidation:
   • For any time-based invalidation vectors, if the remaining time is less than 24 hours, we reduce the overall ETag’s TTL accordingly.
   • This ensures that time-sensitive data doesn’t remain cached beyond its validity window.
3. Caching the ETag and Invalidation Vectors:
   • At the end of request processing, we store the ETag with a list of its invalidation vectors.
   • Each invalidation vector is cached individually, initially set to a value of 0 (representing a “valid” state).

Implementation of WAL consumer

To keep the ETag cache accurate, we rely on PostgreSQL’s Write-Ahead Log (WAL) for Change Data Capture (CDC). A separate WAL consumer service processes these logs and updates invalidation vectors:

1. Detecting Changes:
   • The WAL consumer listens for changes to tables that affect or represent invalidation vectors.
   • When it detects an update or insert that invalidates a particular vector (e.g., a user’s KYC status changes), it sets the vector’s cached value to the current timestamp.
   • We built our custom WAL consumer using the pglogrepl library, taking inspiration from PeerDB ’s approach to streaming data pipelines. Over time, we also developed our own lightweight library wal-e, to simplify WAL consumption and make integration easier across services.
2. Checking ETag Validity:
   • On subsequent requests, Homelander compares the timestamp in the ETag’s ULID against the updated timestamp of the invalidation vector.
   • If the vector’s timestamp is greater than the ETag’s, it indicates the data is stale, and Homelander re-renders the response and issues a new ETag.
   • If it is not greater, the system returns 304 Not Modified, allowing the client to use its cached content.

Lets take an example of how this logic would work in its entirety:

• Request Initiation:A user with ID 1 sends a request to Homelander to render their home screen.
• Rendering and Vector Collection:Homelander begins rendering the home page, applying various filters and logic to decide which cards should be shown to the user. During this process, it collects all the invalidation vectors involved in those decisions (for example, user attributes, feature flags, or campaign configurations).
• Vector Registration in Redis:Once rendering is complete, Homelander registers each collected vector in Redis using SETNX.
  • If a vector doesn’t exist, it is created with an initial value of 0 (indicating a valid state).
• ETag Generation:Homelander then generates a unique ETag (a ULID) for this rendered response and stores it in Redis along with the list of associated vectors.
  • The ETag’s TTL is set to the minimum TTL among its vectors to ensure consistency.
• Change Detection via WAL:When any relevant change occurs in the database (for example, a user’s record or card configuration is updated), the WAL consumer detects it and updates the corresponding vector’s value in Redis to the latest date_modified timestamp.
• Subsequent Request Handling:When a subsequent request arrives with an existing ETag:
  • Homelander first checks if the ETag exists in the cache. If not, it re-renders the page and generates a new one.
  • If the ETag is found, it retrieves all associated vectors.
  • If any vector’s timestamp is greater than the one associated with the ETag, the ETag is considered invalid, and the response is re-rendered. Otherwise, the cached version is returned with a 304 Not Modified response.

Visualisation:

⚡️ Measuring the Impact: From Optimised 200s to Near-Instant 304s

These metrics represent 200 OK responses, where the home feed is fully recomputed and rendered on the server. Despite executing the complete rendering pipeline, p95 latency consistently stays under ~50 ms, reflecting the efficiency gains from Homelander’s architecture and query optimisations.

These metrics show 304 Not Modified responses, where the server validates the request using ETags and instructs the client to reuse its cached home feed. Since no re-rendering is required, this path avoids almost all computation, resulting in p95 latencies under ~5 ms. Additionally, because the client already has a cached response, the app can render the home feed almost instantly on startup. If any changes are detected, the feed is re-rendered making the overall experience feel significantly more responsive and snappy.

🚀 Wrapping Up

With Homelander, we transformed one of the most performance-critical parts of our app—its home feed—into a lightning-fast, scalable, and resilient system. By combining architectural shifts, smart caching using ETags, and CDC-based invalidation via PostgreSQL WAL logs, we reduced load times from several seconds to under 50ms.

Our approach ensured that flexibility wasn't sacrificed for speed. Product teams can still iterate freely, while engineering benefits from a lean, efficient backend.

In the coming weeks, we’ll be rolling out the ETag strategy to our clients and sharing performance insights from that launch—stay tuned for those updates!

🔮 What’s Next?

The home screen is just the beginning. Rendering it involves fetching multiple pieces of data from the backend to display up-to-date information to users. Currently, many of these supporting APIs are outside the Homelander service.

Looking ahead, we plan to gradually migrate all such APIs to Homelander and power them with the ETag caching model. This will allow us to avoid repeated data fetches and further streamline our infrastructure—pushing us closer to a consistently fast and efficient user experience across the board.

We also plan to evolve the ETag mechanism itself. Today, it operates in an “all-or-nothing” mode—any change invalidates the entire response. Our next goal is to enable partial cache reuse, where unchanged sections of the response continue to be served from cache, and only modified components are re-rendered.

📝 Acknowledgements

This work wouldn’t have been possible without the contributions of a few people who played a pivotal role in shaping Homelander.

Amarender Singh laid the foundation for this project and helped take it from idea to reality. He set a high bar for how Go services should be designed and written within the company, and his emphasis on clean, elegant engineering motivated the rest of us to build the system the right way.

Pratik Gajjar brought deep design clarity to the project. His fundamental thinking around caching and invalidation led to the ETag-based approach that became central to the system, and his ability to simplify complex problems was instrumental in making the architecture both robust and efficient.

Designing the 50 ms Home Feed

As Famapp's user base expanded to over 7 million monthly transacting users, we began to encounter significant performance bottlenecks in our infrastructure. These issues became particularly apparent during evening usage surges and UPI ecosystem degradations, when increased app reloads would cause traffic to spike uncontrollably.

The most resource-intensive component of our system was the home feed API—the critical API responsible for loading the app's first screen. This API was designed with maximum flexibility in mind, dynamically rendering different UI elements based on user segments. iOS users might see Apple Store codes while Android users would receive Google Play recharge options. High-spending users could receive subscription nudges while others wouldn't.

Furthermore, our home screen was designed to be highly responsive to user behaviour, potentially refreshing its elements after each user action. For every app open, our system would:

1. Check the user's current state
2. Fetch all possible UI elements
3. Determine which elements to display

This approach served us well in Famapp's early stages, but as we scaled, our monolithic Django service began showing signs of strain. Most concerning was the home screen's loading time, which had reached an unacceptable p95 latency 2-4 seconds—creating a poor first impression for users expecting a fluid transactional experience.

The key reasons why these latencies were very high:

• Every request rebuilt the entire home page from scratch, repeating the same database queries and filtering logic even when nothing had changed.
• Django’s ORM, while convenient early on, introduced hidden n+1 query patterns that inflated network latency.
• And since our monolith also handled mission-critical flows like payments, these redundant rendering requests were eating into CPU time meant for golden paths.

After analysing these challenges, we established two key objectives for our solution:

• Reduce home screen loading time from 2-4 seconds to under 50ms
• Preserve our product team's ability to dynamically modify UI elements without technical constraints

This is the story of how we redesigned our system to meet these ambitious goals while maintaining the flexibility our product team relied on.

Why? Why 50ms?

We set the 50 ms target based on established responsiveness benchmarks. Human perception studies show that interactions completing within 100 ms feel instantaneous, while delays beyond 300 ms start to feel sluggish, and anything over 1 second breaks the user’s sense of flow. Since the home feed is the first screen users see, we aimed for sub-perceptual latency—ensuring it loads faster than users can consciously notice.

How?

Working with our talented engineering team (yeah the same best minds who are working on it 😅), we conducted a thorough analysis of our existing system challenges:

1. Redundant Calculation Overhead: Our home screen rendering process recalculated display elements on every request, evaluating user cohorts, recent activities, wallet balances, and other parameters. We discovered that many of these calculations were unnecessary, as users frequently refreshed without any meaningful state changes occurring.
2. Cascading Failure Patterns: During payment infrastructure degradations, we observed a problematic feedback loop: users would repeatedly reload the app when transactions appeared to stall, triggering a surge of redundant home screen calculations. This pattern created resource contention precisely when our system needed to prioritise processing critical payment flows.

These findings highlighted how our rendering approach not only consumed excessive resources during normal operation but also exacerbated system strain during partial outages—effectively creating an avalanche effect in the system

After thorough assessment, we determined that our customisable rendering system remained conceptually sound, but required significant efficiency improvements. We developed a comprehensive strategy targeting key performance bottlenecks:

• Caching Card Configurations: Implemented caching on client side to eliminate repeated database calls to get the same data. If the client has the home feed and there is no change in the response then no extra database calls! Problem solved!
• Request Consolidation: Introduced a mechanism so that concurrent requests for identical card configurations would trigger only a single database operation with shared results.
• Eliminating N+1 Query Patterns: Refactored our code to prevent hidden database calls caused by Django's ORM in our object-oriented architecture. We implemented request-level caching to ensure any resource fetched once would be reused throughout the request lifecycle.
• Architectural Shift: Began migrating from our monolithic Django service to a lightweight Golang implementation with direct SQL queries instead of ORM, reducing overhead and improving response times. Independent TechEmpower benchmark results have shown that optimized Go services consistently outperform the fastest Django setups—typically delivering 5–10× higher request throughput and 2–4× lower p95 latency under equivalent load. In our case, using Go’s native pgx driver, strict type system, and efficient JSON serialisation reduced memory allocations and parsing overhead, resulting in a leaner and faster service.

This multi-pronged approach allowed us to address performance bottlenecks at each layer of our stack while maintaining the flexibility our product team required.

Home Screen Architecture

Our home screen follows a hierarchical structure designed for maximum flexibility and personalisation:

1. Primary Home Section: The main container that encompasses all interactive elements visible to the user upon app launch.
2. Contextual Groups: Within the primary section, content is organised into logical groups based on functionality or user relevance (e.g., "For you section”, “Quick actions” etc.)
3. Contextual Cards: Each group contains individual cards that serve as the atomic units of our interface. These cards dynamically display:
   • Customised imagery tailored to user preferences
   • Personalised text reflecting the user's current state
   • Interactive elements that adapt based on usage patterns and eligibility

This nested structure allows our product team to precisely target content delivery at multiple levels, ensuring each user receives a home screen optimised for their specific context and needs.

Why so dynamic? Why a backend driven architecture?

Our home feed is entirely backend-driven, allowing the product team to dynamically control what each user sees without requiring app releases. Every card’s content, layout, and eligibility logic are generated on the server based on real-time user attributes—such as transaction history, verification status, and feature access. This design enables us to experiment rapidly, run targeted campaigns, respond instantly to ecosystem changes and most importantly provide a personalised experience to our users.

Balancing Dynamism and Performance

Our challenge was clear — we couldn’t compromise on the flexibility that made the home feed valuable, yet we needed to bring its performance closer to that of a static page. A fully cached or precomputed home feed would have been extremely fast, but it would also strip away the personalisation that defines the product experience. On the other hand, fully dynamic rendering ensured contextual relevance but came with significant computational cost.

We needed an approach that could retain the home feed’s dynamism while avoiding redundant recomputation.

The key insight was that not every user attribute changes frequently. If we could identify exactly which variables a home screen depends on — and determine when those variables last changed — we could safely reuse previously rendered results instead of recalculating everything from scratch.

We also realised that the home screen didn’t need to be real-time to the millisecond. Allowing a small relaxation window of around one second would still feel instantaneous to users while drastically reducing backend load.

This thought process led us to design a conditional caching mechanism, where responses could be reused as long as none of their dependent variables had changed. That reasoning ultimately formed the foundation for our ETag-based caching system — a way to preserve full dynamism while achieving near-static response times.

Implementing ETag-Based Caching

We adopted an ETag-based caching strategy inspired by frontend systems and applied the principle of disaggregation—keeping heavy home-feed computation out of the request path. With ETags, the server does minimal work unless data changes, because the fastest operation is the one you don’t do.

What is Etag?

An ETag (Entity Tag) serves as a fingerprint for an API response, uniquely identifying its current version. When the underlying data changes, the ETag changes too, helping the client know whether it can safely reuse cached data or needs to fetch fresh content

Fundamental Working

• Server generates an ETag for a response (usually a hash of the content).
• Client caches the response along with the ETag.
• On the next request, the client sends the ETag in the If-None-Match header.
• The server compares the client's ETag with the latest version:
  • If unchanged, server replies with 304 Not Modified (no data transfer needed).
  • If changed, server sends the new data with a new ETag.

This pattern significantly reduces server load by eliminating unnecessary rendering and data transfer when a user's state remains unchanged between requests. The approach is particularly effective during system degradations when users frequently reload the app, as it converts potentially resource-intensive rendering operations into lightweight validation checks.

After deciding on an ETag-based caching strategy, we faced a critical implementation question: how could we efficiently determine when cached content should be invalidated?

The Invalidation Vector Approach

We developed a system based on "invalidation vectors" - specialised data structures that represent specific conditions under which a cached response becomes invalid. The elegance of this approach lies in its precision:

A visual representation:

What is a vector?

A vector is a lightweight data structure that tracks the validity of a cached response. Each vector stores:

• Key → A unique identifier (e.g., user ID, home contextual card ID).
• Value → A timestamp derived from the date_modified column in our database. If this timestamp is greater than the one associated with the cached response, the vector is considered invalid.
• TTL → The duration for which the vector remains valid before it must be refreshed.

Each vector represents a specific component or state that, if changed, would necessitate a fresh rendering of the responses that depend on this vector.

1. Composite Validation Logic: The entire response validity depends on AND logic across all invalidation vectors. If any single vector becomes invalid, the entire cached response must be regenerated.
2. Hierarchical Dependency Mapping: We mapped dependencies between different vectors to understand cascading invalidation effects. For example:
   • If a user's KYC status changes, it invalidates the user vector
   • If a home contextual card's image mapping changes, it invalidates the corresponding card vector
3. Targeted Invalidation: Each invalidation vector is associated with specific IDs (such as user IDs or card IDs), ensuring that changes only invalidate relevant cached responses.

So we ended up making two kinds of vectors:

• Primary Invalidation Vectors: Directly linked to a specific response and determine its validity
• Secondary Vectors: Can trigger invalidation of primary vectors through defined dependency relationships. Example: KYC table linked to user, Card image map table which invalidates the card itself.

This two-tier approach creates a invalidation cascade system, where changes propagate through our dependency graph, ensuring we only regenerate responses when truly necessary.

• Red: Primary Invalidation Vectors
• Green: Secondary Vectors

As we can see above, any change in the User group map table for example will invalidate the user vector (the primary invalidation vector)

Once the invalidation vectors were in place, the next challenge was determining how to effectively track the changes that should trigger a cache invalidation. We evaluated two approaches:

Option 1: Manual Event Emission

In this method, specific sections of our monolithic service would be modified to emit change events to a message broker (such as Kafka). Consumers would then process these events in line with our dependency graph to invalidate the appropriate vectors. While this method offers direct control over which events trigger an invalidation, it comes with significant downsides:

• Increased Code Complexity: Embedding event emissions into the existing codebase adds extra lines of code, making the monolith more cumbersome to maintain.
• Consistency challenges: Ensuring event emissions perfectly match database state changes introduces a consistency nightmare, especially when failures, retries, or partial rollbacks occur. Even minor mismatches can lead to stale or prematurely invalidated cache entries.
• Scalability Concerns: Every new feature would need to incorporate this mechanism, raising the risk of inconsistencies and oversight as the system evolves.

Option 2: Change Data Capture (CDC) from PostgreSQL (Preferred)

Our preferred solution leverages PostgreSQL's Change Data Capture (CDC) capabilities. Here’s how it works:

• Automatic Change Detection: PostgreSQL logs every transaction in its Write-Ahead Log (WAL). By consuming these WAL logs, we can automatically capture all changes made to tables that either contain or affect invalidation vectors.
• Minimal Code Modification: This approach operates independently of the application logic. It requires little to no modifications to the existing codebase, ensuring that new features integrate seamlessly without additional overhead.
• Dynamic Decision Making: Based on the type of operation (such as UPDATE or INSERT) and the specific table affected, our CDC system evaluates which invalidation vectors need to be refreshed. This ensures that the caching system remains accurate and up-to-date with minimal manual intervention.

The CDC-based system thus provides a robust and scalable solution, significantly reducing the need for manual code changes and allowing us to operate entirely outside the core application code. This not only simplifies maintenance but also ensures that our caching mechanism stays aligned with the dynamic nature of our data.

From planning to execution

Part 1 brought us to a clear, battle-tested plan: reduce redundant computation, eliminate N+1 patterns, introduce ETag-based conditional caching, and track data changes precisely using invalidation vectors and CDC. With the design in place, the next challenge was turning this blueprint into a real, production-ready system.

In Part 2, we dive into how we built Homelander—the service that made sub-50 ms home feed responses possible.

Student life is definitely not easy, and having to study literally all the time for exam or the other can be super frustrating. But as they say, there is a method to every madness - Let's talk about the method. Exam season is here and we know you need some study advice to keep your head in the game.

1. (Don't) stop cramming 🙇‍♂️

Cramming is the worst way to understand anything, especially when you try to cram all your syllabus in one night. The trick is to read the same chapter, same syllabus every week - such that your brain naturally remembers what you read. Remember when Jeetu Bhaiya said - "21 din mein koi bhi aadat ban jaati hai", yes exactly that!

2. Make sure you have a set time to study ⏳

You know when we were young and moms used to say - 'Roz bas ek ghanta padh le!' Well that's true my friend. Studying just 1 hours everyday, on a set time will save you from those all nighters right before exam. Don't just try to be consistent with your study, study at the same hour everyday.

3. Understand and try to love what you study 💖📚

While it's true that a formula or an equation will not really help you in life 10 years later, it's still knowledge that makes us more curious, and open to learning. Learning new concepts of any new subject is super fun and interesting! If you really try to love what you're studying, you are surely going to ace it!

4. Don't study without a goal 🥅

Why do your textbooks have separate chapters and questions after each on of them? It's because each chapter addresses a different part of the subject and needs to be studied separately. Always study one chapter at a time, and finish the entire chapter fully before moving on to the next one.

5. Start with the difficult subjects or topics 🙆‍♂️

How many times have you started a study session and asked yourself - "Shuru kaha se karu?" We have a simple solution to this huge problem - start with the most difficult. It will take the most time and will give the most confidence when you successfully complete it.

6. Don't study (too much) 🙅‍♀️

This is definitely the most important point. Studying the entire syllabus in one hour is just as effective and not studying at all. Space your studying time out over shorter periods of time, with breaks in between.

7. Always study in a quite setting 🏡

Distraction is easy. Distraction will also mean understanding less. Studying needs a flow. Remember that one really good study session you had. How each word that you read was so easy to understand, you could relate to each and every question and understand most concepts. Now look at the larger picture and see how quiet and peaceful that environment was. That's what you need every time.

Ever wondered why your debit/credit card carries the 16-digit number? Its a unique identifier that you use when you are making online transactions. You pull out the card from your wallet, enter the 16-digit and voila! - the Shopping site now knows its your card from where they should debit the money!😃

But what if there was a simpler solution, that will avoid the walk from your comfort zone till your wallet? What if while you are browsing the shopping site on your phone, you can copy the 16 digit pin easily and paste it to continue the transaction? 👌🤑

Simple innovations begin by asking the question"why"! We started in 2019 by asking the question "Why should digital payments be for people of age 18 and above?" Less than a year later, we ask again "Why should cards have numbers?" Turns out, they don't need to!

In our efforts to push the boundaries of innovation by constantly challenging the norms, we have launched India's first numberless card, and unlike the rest of the cards, this is not for 18 and above, its for teenagers! 🤴👸✨

FamCard is the first of its kind numberless card that teenagers can now use to make payments online/offline independently, relieving parents of the trouble of giving them cash or their credit/debit card.

Ok, I get it, you have launched a card for teenagers, but what's the big deal about Numberless?!

We're glad you asked! FamPay is for teenagers and their families. And teenagers haven't been using digital payments until now. So they are kinda new to the whole world of digital payments, UPI, Cards, and we have to make sure their payments are safe and secure.

Its a 1+ level secure!

FamCard has no numbers on the physical card which makes it very secure. The card number and other details (expiry date, CVV) are stored securely within the FamPay app instead of being printed on the physical card. So, if a teen loses the card, there’s no fear of card information getting disclosed. Plus, the card can be paused, blocked and managed at fingertips on the app. Additionally, all the card details within the app can be accessed only with device lock like fingerprint, face ID, pattern lock or PIN.

We don't stop here! We have added an extra feature we have to save you from spending too much money! You can keep a check on the maximum limit you want to spend every transaction. This feature is available for both online and offline transactions. Ain't that handy?

Contactless in the age of Corona

FamCard has a special feature of “Flash PIN”, which is dynamic and is generated for every transaction. Teens can just flash this PIN to the cashier for offline payments, without the need of entering the PIN by themselves on the POS machines, allowing for true contactless payments amidst COVID-19.

No frills for the no-nonsense generation

When the number is not required for either online or offline transactions, then why have it in the first place? EXACTLY! Cards carrying the 16 digit number have been used for years now, but this number is not really required on the card when transacting offline. As FamCard has no numbers, all the card details are saved on the FamPay app and there is no need to refer to the physical card to fill in details during online transactions. FamCard is an innovative product in the sense of utility, one in a few across the world and the first in India - a perfect no frills product for the no-nonsense generation, Gen-Z!

Designed for the best

Did you know that Gen-Z teens are the coolest generation of all times? Don't believe us? Well, just look them up! They are tech savvy, empaths and woke! Any product that addresses their needs will have to resonate with their vibe. FamCard’s design is minimalist with only relevant information displayed on it. It is a sleek and vertical card that matches their aesthetic style. The unconventional vertical card design is already a hit with the GenZ, who are excited as the card can be personalized. Numberless design will last longer because there are no numbers to fade with the passage of time.

Hmmm, so anybody could have created a numberless card, no biggie, right?

NOPE! Anybody could have, but didn't. And it is a big deal. Making a numberless card was not an easy option for anyone until now, because there were plenty of processes and systems already that manufacture a card a certain way. And don't get us started on the backend systems. There was a lot of unlearning and re-learning that we executed with the card manufacturers, approvers and issuers. After months of hard work and perseverance from the FamPay team, and with the support of National Payments Corporation of India (NPCI), the numberless card in India has become a reality, which can be achieved by anyone now. But we'd like to believe the first time's the charm 🤗

Interesting, can I use this card everywhere?

Yes! You can use it everywhere - Online/ Offline! Famcard works just like any other bank's Debit card!

Offline: Buying groceries for mom at your kirana store? Need quick stationery from the shop downstairs? Wanna surprise dad by paying for petrol/diesel while he is getting it filled? FamCard can do all of this for you. It works at all merchant outlets accepting RuPay cards. Don't forget to be safe and use contactless payment option - the Flash PIN! ⚡

Online: You can book an Ola/Uber and pay for it using FamCard. You can order food online on Swiggy and pay for it using FamCard. You want to buy something for mom on Amazon - yes, you guessed it right! You can use FamCard. The 16-digit number that Famcard does not carry is stored on your app. So just copy it from your app and paste it on the payments page, along with validity (mm/yyyy) and CVV which is also available on the app. Voila, there you go!

Wow, this is great. How does it look when it arrives?

Haha! We won't answer this one for you, we will show you how our GenZs have unboxed their FamCard!!

I'm convinced, how can I get one? 😍

If you are a teen, download our app, get the KYCs done and apply for the card! If you are a parent of a teen, get your teen their first card!

If you are neither a teen nor a parent of a teen, fret not, just download our app with your family, and enjoy the world of digital payments. Though our numberless card is exclusively available to teenagers only, we'll soon launch it for you too. 🚀

Since the economic downturn of 2022, startups must prioritise profitability and sustainable growth and operate more like traditional businesses, focusing on increasing earnings and reducing costs. For a FinTech startup, Cloud spending, a significant recurring expense, grows with scale, making cost-saving crucial in this area

$1 saved monthly will lead to $12 savings annually

FamApp is a fin-tech application enabling seamless UPI & Card payments for the next generation. AWS forms the backbone of our tech stack empowering our application to run at scale for millions of users.

Being a fintech startup with increasing scale and cost, last year we set out to define goals for cloud spending to keep it in check. We started utilising AWS services for spend analytics and taking measures to reduce the ever increasing cost and root out inefficiencies.

In this blog, we will mainly focus on AWS cloud cost, as that’s the biggest recurring tech cost for us. Here majority of the cost comes from Databases, Cache and EC2 servers running stateless backend applications.

How?

What is measured, can be improved — Peter Drucker

With a team of talented engineers, the best way is to define ambitious goals that are objectively measurable.

Non Goal

• Reducing platform reliability by not having redundancy.
• Increasing latency via using cheaper hardware.

Defining Goal

The first question that comes to our mind before we start defining the goal is:

• Where does our revenue come from?
• What makes our revenue scale?

For example, if our user base increases, this will lead to more potential customers entering the top of the funnel, which is likely to result in higher revenue from the goods and services provided on the platform.

Following this approach, we had three ways to link revenue numbers with the scale:

1. MAU → Monthly Active Users
   1. Count of users who opened the app at least once in a month
2. MTU → Monthly Transacting Users
   1. Count of users who did at least one payment in a month
3. MT → Monthly Transaction Count
   1. Total number of successful payments in a month

Here we agreed on → How many users make payment in a month ie. Monthly Transacting Users (MTU) as a factor.

Why MTU ?

How do we create value for the user? When user uses our platform to make payments

If we were to choose MAU as a factor, this would mean there would users using our platform but value creation is not guaranteed there. For the 3rd factor, ie. total transactions, this would result in value creation but cannot guarantee the scale of per user value creation as implied in the Pareto Principle.

The Pareto principle states that for many outcomes, roughly 80% of consequences come from 20% of causes.

Example

Let’s say our AWS cost is $80,000 per month and have 1M MTU. With $1 = 83.9 INR, AWS spends per transacting user would be

Based on unit economics, to have sustainable business, how much can you afford to spend on cloud ? We decided to pursue 1 INR / MTU as our north star metric for cloud cost.

Thus, we need to reduce cost ~85%. Engineers are now looking into business metrics, as the target is directly related to it, enforcing product-minded engineering.

Dissect spends

Strategy - Always start from $0 - what can we do to spend nothing ? Pick up low hanging fruits.

By Engineering Team

1. Frontend: ~7% - AWS
2. Mobile (Android & iOS: 3% - Firebase
3. Backend: 90% - AWS

Note: these are not exact numbers.

Since we’re a Y Combinator funded start up, we tried to utilise investor credits wherever we could.

Making frontend spend come down to $0

1. Via migrating to cloudflare pages. Here, technically, we needed to serve only pre-built js, css, html static files.
2. Convert Server-Side-Rendering (SSR - Next.js app) → CSR.
   1. We wanted to skip running node.js server. Moving to static apps made it easy and efficient to deploy.
   2. We utilised cloudflare workers where server side logic was needed.

Making Mobile spend <1%

Most of the cost came from firebase realtime database, so we opted for a different strategy to serve the same use case. We used this for only basic static config, so it was relatively strait-forward.

Backend

Backend isn’t just backend application cost, it includes security and data analytics cost as well. We consider everything as backend cost. Since this was the biggest pie, we divided this further.

By product feature

1. Chat
2. Feed
3. Transaction

Based on backend API requests per month to serve specific features.

What value are we providing to the user via having this specific feature? How many users would come back asking for the specific feature if it gets removed?

Based on the above, we decided to sunset features that didn’t provide value to the user. This was one of the biggest levers for us and helped us reduce cost by roughly ~30%.

Being a startup, we iterate heavily and over the course of 4 years we accumulated several features that were already sunset. However, from backend, computation required for those was still being done.

We may call this as tech debt. Having feature sunset process would help here, so that when the product team decides to discontinue, the backend team would be aware about changes as it gets added to backlog.

So far we didn’t need to have specific instrumentation in place to be able to reduce spends as these metrics were already available.

By Business unit

We needed a deeper understanding on what exactly we’re spending on, and how much. For this, AWS provides a feature called user defined cost-allocation tags.

What is a tag?

We can assign Key - Value pair to AWS resource.

Name: "backend_api"
// Key = Name
// Value = "backend_api"

Using AWS cost explorer, we can plot graph that shows you cost ($) by Tag_Key

As you may recall from the story behind our tech stack, from the start we bet on infrastructure automation by using pulumi to define cloud infrastructure as code.

This allowed us to instrument existing and new infrastructure with ease. We also concluded to have cost-center and business-unit tag on each resource.

const commonTags = {
	"Name": "msk-cluster",
	"Environment": curEnvironment,
	"cost-center": "CoreEng",
	"business-unit": "Engineering"
};

/*
Name => resource name
Environemnt => PROD | STAG 
business-unit => Product | FinOps | Support | Risk | Recon | CoreEng
cost-center => 
*/

Define Cost-Center

• For product, services required for given use case to work. Since for given use case we need to touch multiple services, we opted to use cost-center value as service-name
• For common infra where it was not possible to assign direct product function, we use CoreEng as business unit and use case = logging as cost center.

Bulk tagging of resources

We built in-house tooling to attach tags in bulk for services that were created directly using console.

-- Store AWS resources
CREATE TABLE IF NOT EXISTS resources (
  resource_arn TEXT PRIMARY KEY,
  tags_json TEXT,
  account_id TEXT,
  business_unit TEXT,
  cost_center TEXT,
  service TEXT,
  created_at DATETIME
)

INSERT OR REPLACE INTO resources (
	resource_arn, tags_json, account_id, created_at, business_unit, cost_center, service
) VALUES (?, ?, ?, ?, ?, ?, ?)

-- Store rules
SELECT
  "rules"."resource_arn" AS "resource_arn",
  "rules"."pattern" AS "pattern",
  "rules"."business_unit" AS "business_unit",
  "rules"."cost_center" AS "cost_center",
  "rules"."is_active" AS "is_active"
FROM
  "rules"
WHERE
  "rules"."is_active" = 1
  and ("rules"."account_id" = ? OR account_id is null)

-- Fetch resource 
SELECT
  "resources"."resource_arn" AS "resource_arn",
  "resources"."tags_json" AS "tags_json",
  "resources"."created_at" AS "created_at"
FROM
  "resources"
WHERE
  "resources"."business_unit" = ''
  AND (LOWER("resources"."tags_json") LIKE ? OR "resources"."resource_arn" LIKE ?)
  AND "resources"."account_id" = ?

Steps:

1. Fetch & store all AWS resources in SQLite
2. Define rules table which can have regex or specific resource id and value for cost-center and business_unit

Go through active rules and apply tags.

	for _, r := range rules {
		if r.arn != nil {
			applyTags(ctx, *r.arn, *r, svc)
		} else if r.pattern != nil {
			processPattern(db, r, svc)
		} else {
			log.Warn("rule does not have pattern or arn", "rule", *r)
		}

Common Optimisation Areas

1. Optimising Cloudfront and Load Balancers
   1. We saw a 99% reduction in cost by utilising cloudflare edge caching with cache hit ratio of 99.5%
   2. Utilised Cloudflare R2 for common public assets. Here, add aggressive edge caching policy and make resources immutable.
2. Instance Volume Type and AMD Instances
   1. Use c6a, m6a - AMD instances
   2. Use gp3 volume for all instances and RDS storage type, instead of provisioned IOPS (io2)
   3. Use spot instances when you can, if not commit minimum compute spends to get discount. Use reservation and saving plan tab in cost explorer for suggestions.
3. Inter-AZ Communication
   1. Understanding of data transfer costs between Availability Zones. You can utilise cost-explorer here.
   2. Keeping majority of the instances in the same zone as primary db and cache nodes
4. Hibernation of Development Servers: We were able to reduce spend by 80%. We plan to write about this in detail in the future, stay tuned!
   1. In micro service environment for testing, we launch all the dependant services for each feature
      1. Automatically stopping servers when unused via using request logs did wonders. The learning here is to automate when you can.
      2. Here hibernated servers become live within 5 mins when someone tries to use the endpoint.
   2. Utilise postgres logical database to have one server for all micro-services in development environment.
5. RDS Snapshots and EC2 Volumes
   1. Remove unattached unused volumes in EC2.
   2. Archive older snapshots - RDS snapshot cost is ~100$ per TB
6. S3 Objects
   1. Setup data archiving policy
   2. In case you have versioning enabled and deleted objects, they’ll use storage space.
      1. Setup deletion policy for older transient data
7. Effective Use of Karpenter
   1. For EKS cluster, we strongly recommend to use karpenter and utilise spot instances and compact pod packing
   2. When pods have CNI attached to use AWS IAM roles for pods, there is a limit on instance, how many CNI can be attached which would cause node to stay underutilised.
      1. Increase pod cpu / ram requests to use bigger pod which would handle more requests. Eg. running 10 smaller pod would cost more than 3 big pods with equivalent compute capacity due to limit of CNI - container network interface
8. Rightsizing Container Resources & Ec2 Instances
   1. Use opensource tooling like kubecost to analyse effectiveness
   2. Compare workload wrt instance type. Eg. using c6a.large vs t3a.medium, by calculating count of instance * instance_type to run same workload.

Process

1. Bi-weekly calls to analyse spend data and impact of optimisation
2. Monthly update with INR cost per MTU with team
3. Cost analysis as part of technical review document when building new features

Future plans

1. Make tagging mandatory / 100% cost allocation tag coverage
2. Automatic detection on cost anomaly and alerting

Conclusion

• Define goals based on business metrics, instrument resources, and regularly look at spendings.
• Experiment with various options, keep iterating and analyse impact.
• Automate, automate, automate.

You've probably seen apps like Twitter, Snapchat, Zomato etc., which allow users to choose app icon of their choice, or they change it in background on special occasions. It adds a personalised touch to the customer experience and acts as a delight feature for users. At Fam, we were also eager to build this for our users and here’s how we went about it.

I started searching on internet about the same and went through many articles & stackoverflow buzz but the provided implementation everywhere causes the app to close on each app icon change. While the apps of Twitter, Snapchat, etc., only close once when changing the icon for the first time.

I eventually discovered the technique to accomplish the desired functionality. In this article, we’ll first see the basic implementation which talks about the engineering behind it that will close the app every time. Then, we’ll see how to achieve the desired behaviour, which will only close the app once, the very first time.

Overview

Unlike iOS, changing the app icon programmatically in Android is not very straightforward. Android doesn’t provide any official way of doing this. However, with the help of activity-alias we can achieve this.

Activity’s alias is like having a different identity of target activity. By creating an alias for our desired activity, we can assign it a different icon and even a different app name.

TL;DR - So basically, to change the icon at runtime, we’ll need to enable the alias representing an icon that we want to switch to and we’ll need to disable the currently enabled alias (i.e. SplashActivity in above example). Sounds easy-peasy, right?

Let’s have a look at Manifest file:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="<http://schemas.android.com/apk/res/android>">

    <application
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:roundIcon="@mipmap/ic_launcher_round"
        android:label="@string/app_name"
        android:theme="@style/Theme.Example">
        
        <!-- SplashActivity (Your Launcher activity) -->
         <activity
            android:name=".SplashActivity"
            android:exported="true"
            android:theme="@style/Theme.Example">
            <intent-filter>
		            <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
        
				<!-- Alias for SplashActivity with different icon -->
        <activity-alias
            android:name=".NewYearIconAlias"
            android:targetActivity=".SplashActivity"
            android:icon="@mipmap/ic_new_year"
            android:exported="true"
            android:enabled="false">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity-alias>
        
    </application>

</manifest>

Here, SplashActivity is our launcher activity and we’ve declared an activity-alias for it with a different icon which is disabled (enabled="false") by default. When the app is installed, the icon associated with the SplashActivity (i.e. application’s default icon) will be set automatically. And upon enabling the activity alias, the icon associated with it will be set.

Now let’s see the code to enable/disable the activity alias in runtime. We’ll use PackageManager class & it’s setComponentEnabledSetting(...) method

fun changeIcon() {
				// Enabling NewYearIconAlias, that represents new year icon - for example
        packageManager.setComponentEnabledSetting(
            ComponentName(
                this,
                "$packageName.NewYearIconAlias"
            ),
            PackageManager.COMPONENT_ENABLED_**STATE_ENABLED**,
            PackageManager.DONT_KILL_APP
        )

				// Disabling the SplashActivity (we can also have alias to disable if we're playing with multiple aliases)
        packageManager.setComponentEnabledSetting(
            ComponentName(
                this,
                "$packageName.SplashActivity"
            ),
            PackageManager.COMPONENT_ENABLED_**STATE_DISABLED**,
            PackageManager.DONT_KILL_APP
        )
        
        // Note: DONT_KILL_APP flag doesn't work if we disable the 
        // currently enabled alias at runtime.
}

Here in setComponentEnabledSetting(…) method, we are passing the component name of activity-alias and splash activity. And we’re changing activity-alias state to enabled i.e. COMPONENT_ENABLED_STATE_ENABLED and splash activity state to disabled i.e. COMPONENT_ENABLED_STATE_DISABLED.

This will enable our activity-alias representing a different icon and disable the SplashActivity which represents default app icon in our case. Yes! That’s pretty much it, our app icon has been changed.

BUT as mentioned before, this straightforward approach comes with a pain—it’ll close the app every time we change the icon :/ In contrast, apps like Twitter & Snapchat only close once, the very first time the icon gets changed.

Solution to prevent the app from closing every time

Activity/alias component have multiple states like:

• PackageManager.COMPONENT_ENABLED_STATE_ENABLED → This enables a component
• PackageManager.COMPONENT_ENABLED_STATE_DISABLED → This disables a component
• PackageManager.COMPONENT_ENABLED_STATE_DEFAULT → This takes component to it’s default declared state in Manifest (for ex: Enabled or Disabled)

By leveraging this behaviour of the Android system, we can simply enable the new alias and set the currently enabled alias to its Default state (which was declared as Disabled in the manifest). This won't result in the app being terminated. 😎

Implementation

We’ll create 3 types of aliases:

• DefaultIconAlias: It’ll represent the default icon of our app. It’ll be enabled (enabled="true") by default in manifest
• CloneDefaultIconAlias: This will ****act like a clone of DefaultIconAlias (you will see its uses later). It’ll be disabled (enabled="false") by default

Both DefaultIconAlias & CloneDefaultIconAlias will represent the app’s default icon

• Rest of the other aliases: These will represent different icons and these must be disabled by default, you can declare these as many as you want!

Let’s have a glimpse of Manifest

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="<http://schemas.android.com/apk/res/android>">

    <application
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:roundIcon="@mipmap/ic_launcher_round"
        android:label="@string/app_name"
        android:theme="@style/Theme.Example">
        
        <!-- Your Launcher Activity (SplashActivity in our example) -->
				<activity
            android:name=".SplashActivity"
            android:screenOrientation="portrait"
            android:theme="@style/OnboardingTheme"
            android:exported="true">
            <intent-filter>
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
        
        <!-- This is enabled by default -->
        <activity-alias
            android:name=".app_icon_alias.AppIconsAlias.DefaultIconAlias"
            android:enabled="true"
            android:icon="@mipmap/ic_launcher"
            android:targetActivity=".SplashActivity"
            android:exported="true>
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity-alias>

				<!-- This is disabled by default -->
        <activity-alias
            android:name=".app_icon_alias.AppIconsAlias.CloneDefaultIconAlias"
            android:enabled="false"
            android:icon="@mipmap/ic_launcher"
            android:targetActivity=".SplashActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity-alias>

				<!-- This is disabled by default -->
        <activity-alias
            android:name=".app_icon_alias.AppIconsAlias.NewYearIconAlias"
            android:enabled="false"
            android:icon="@mipmap/app_icon_beach"
            android:targetActivity=".SplashActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity-alias>

				<!-- This is disabled by default -->
        <activity-alias
            android:name=".app_icon_alias.AppIconsAlias.MembershipIconAlias"
            android:enabled="false"
            android:icon="@mipmap/app_icon_basket_ball"
            android:targetActivity=".SplashActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity-alias>
        
				<!-- You can keep declaring as many alias as requried... -->
        
    </application>

</manifest>

Now to change the icon for the first time we’ll disable the DefaultIconAlias (which will terminate the app) and enable a new alias that represents a different icon. This will result in an app icon change but as mentioned app will be closed for the first time since we’re changing the alias state from enabled to disabled in runtime.

Now to change the icon next time we’ll set the currently enabled alias to its default state (i.e. disabled (enabled="false") and as discussed earlier, this transition won’t terminate the app). And now we’ll simply enable the new alias. This will result in an app icon change without the app getting terminated. We’ll keep doing the same for all the consequent icon changes—your app won’t get closed! 🎉

Now, to reset to the default icon, we will set the currently enabled alias state to default (i.e. disabled) and we’ll enable CloneDefaultIconAlias which represents the default app icon too. We’ll always enable CloneDefaultIconAlias in such cases (not DefaultIconAlias) as it’s default state in manifest was disabled. Hence we can always set it to it’s default state in order to change the icon again without terminating the app. We can’t do this with DefaultIconAlias as it’s default state was set as enabled in manifest.

Yay! We’re done, this was it. Now you know the trick behind the apps of Zomato, Twitter, Snapchat and so on. Happy Coding!!

Please note 🚨

• You need to have all the different icons that you want to switch between included in your app's resources beforehand. Each icon needs to be specified in the manifest file and associated with an activity alias. Therefore, this method isn’t practical if you want to change the app icon to something that wasn't included in the app at the time of installation.
• You can also change the icon in the background. This way, even on the first change, app will be killed when user puts it in the background and if he reopens it from the background, then it will be started over from the beginning. Depending on your use case, this might still look better (Zomato also does similarly). On the other hand, we show an app termination warning when user changes the icon for the first time and then we change it right away.

It is safe to say that the COVID-19 pandemic has introduced a mixed bag of pop-culture into everybody's lives, including GenZs. From frothy dalgona coffee, sleeping through online classes, late-night 'among us' sessions to continually existing in PJs, the whole experience hasn't been anything short of a roller-coaster ride. 🤷🏻‍♀️

FamPay, being engrossed in all-things-GenZ, has noted an exciting endeavor that the teen community is taking up with fervor, now that distance-learning and flexible hours have given them the opportunity to explore their interests and opportunities. As always, being the most tech-savvy, ambitious and experimental group, the GenZ are starting young to become business-owners on Instagram. 🤩

An iconic character once said, "If you are good at something, never do it for free". Although this piece of advice, coming from a legendary 'villain', should be taken with a pinch of salt, he's not entirely wrong.

It's 🔥 LIT 🔥that teens are discovering things that they enjoy doing, and monetizing their talents, while churning out drool-worthy products and services. 🤤

If you're a fellow teen who's looking for a know-how of your peers getting the 'bijnes class' experience on Instagram, you're at the right place!

What is on the virtual shelves of GenZ Instagram Shops? 🔍

Well, you can monetize almost anything that you are skilled in, and teens are proving just that! 🧙🏻‍♂️

There are so many categories to choose from! Want to know what the possibilities are? Leggo! 🏃🏻‍♀️

1. Accessories: Do you have an eye for intricate designs and the latest fashion trends? Well, owning an accessory business is the thing for you! Be it polymer clay jewelry, beaded necklaces, or even cute scrunchies, teens are doing it all! 🔥 Fam tip: Offer customized pieces to amp up customers' shopping experience.
2. Apparel: GenZs are the ones who wear absolutely fire fits, so...unsurprisingly, many teens are using their artistic talent to sell apparel! 👕 Be it tie-dying, embroidery, or using their customizing abilities to beautify clothes, Instagram businesses have it all! 🔥 Fam tip: With sustainable fashion in the limelight, opening an online thrift store is a great idea.
3. Food: Does your cooking leave your fam licking their fingers? Well, an Instagram business is the most exciting opportunity for a young aspiring chef or baker enhance your skills. Another treat? You get to roll the dough to roll in 'dough'! 😉 💸 From brownies and cakes to savory treats like pizzas, you can sell it all. 🔥 Fam tip: Don't forget to register your business with FSSAI.

Remember, if your interest doesn't fit in these categories, it's okay! There are so many niche products that would be adored on the IG market.

Why choose Instagram as your marketplace? 🤷🏻‍♀️

Now that you have a fair idea of what our young businesspersons are selling on Instagram, you might wonder why you should set up shop at Instagram. 👀

Well, long story short: Instagram is a gold mine of opportunities for a business. 🌟 We'll tell you why.

1. Ease of usage: If you're not a big IG fanatic, you don't have to worry about a steep learning curve. Setting up your business page on Instagram is easy, and makes your social media handling accessible! Business pages can link their accounts from other social platforms to Instagram, and publish content for all of them at the same time. 👌🏼
2. Great features: With Instagram, GenZs have been able to channel their creative abilities to create a beautiful catalog-like experience for customers. Use stories and highlights to shed light on great topics such as your business story, customer reviews, customization and teasers for new releases, and get on top of the your business game! 🤩
3. Analytics tools: Instagram Insights is a truly commendable feature. Decided to post something and can't gauge how fire your post is? Analytics will give you easy and cohesive stats to look at, which makes it so easy to understand which posts are pushing your business forward. 🔎
4. Creative Freedom: Instagram lets young business owners paint their business canvas however they like. There are pages with different themes, making them look intriguing and fun. If you're inclined towards a particular theme, you can incorporate a cohesive feed, definite color scheme and tone of your page! This is your chance to be unique and experimental: do what you enjoy and have fun doing it!  🌈

🔥 Fam tip: Instagram has been a big supporter of businesses during the pandemic, even showing solidarity and introducing a sticker called "Support Small Business". Instagram Users can share their favorite small brand, improving the brand's visibility!

Is there a blueprint you can follow? 📘

While we strongly believe in being unique and doing things your way, there are some baselines that will help you establish your Instagram Business smoothly. 📊 Let's throw light on the things that ensure a prepared entry of your business in the IG marketplace. 💪🏽

1. Find your niche: The most important step would be to find what you'd like to monetize. It can be products, services or a mix of both. Out of the box ideas are always great, but even if your product is simple, it can turn out to be simply amazing! ✨
2. Market Research: We know, heavy word alert! 😓 Don't worry, it's not as tricky as it sounds. Doing some basic market research would involve looking at other businesses that might sell similar products, noting their prices and customer demographic. 📝
3. Making samples: To launch your business, it would be a great idea to make some samples beforehand. This will give you an idea about the time, material, and cost involved in making your product. You can get even get feedback from family or squad and decide on the prices and range that you'd like to offer. 🤑
4. Shoot creatives: Channel your photography and editing skills to create online content around your products! If you have a theme in mind, follow it. If you're experiencing some creative block, draw inspiration from other pages and sync it with your uniqueness. 📸
5. Build a following: Once you've made your Instagram Business Account and posted some introductory posts, it's time to get a customers! Woohoo! Use that market research to follow relevant people, and engage with them. 🔥 Fam tip: What if we told you there's a community of 7K+ teens, waiting to hear about your business? Well, join FamPay's discord community: 'Friends of Fam', promote your business on the self-promotions channel, and see your followers grow! 📈
6. Manage your Money: Setting up a robust Payments System is essential for a business. As a business-owner, you'll not only receive money through sales, but also expend it on things like courier services, packaging and material. 💸🔄 Using your parent's account is a no-go, since you need 24x7 access to keep track of your finances, initiate refunds or check a customer's payment status. 🙅🏻‍♀️ Fret not, FamPay is here to help! You can set your own FamPay account and handle your finances smoothly, be it earning or spending. The best part? You don't need a bank account, and you get so many rewards for simply using the app. All this while being a business-owner? Now THAT'S the life! 😎

🔥 Fam Tip: You are the biggest asset to your business. Add a personal touch to the brand and packaging, share your story, customer feedback and BTS shenanigans! Don't forget to be proud of owning a business.

Who's thriving on the Instagram Marketplace? 🌱

To end things on an inspiring note, here are some wonderful Instagram based Small Businesses that will prove to you that the journey is going to be equal parts adventurous, informative and rewarding! 🤩

1. Smitten unicorn: instagram.com/smitten.unicorn/
2. Shahrlifestyle: instagram.com/shahrlifestyle/
3. The Minervy: instagram.com/theminervy/
4. Artsiify: instagram.com/artsiify/
5. Nish Hoops: instagram.com/nish.hoops/

Have further questions, suggestions or feedback? Write to me on arohi.kaushal@fampay.in! 🌈

Hello Fam,

In today's digital landscape, when all your spending needs are driven online, safeguarding your money is crucial. At Fam, we always consider protecting your money as a non-negotiable and the most important to us over all other responsibilities you have trusted us for!

Until today, you could login to your FamX account with One Time Password (OTP) which we agree is quite easy but allow us to tell you how it compromises with the safety of your money.

The previous OTP method left users vulnerable to social engineering tactics. We have seen many cases where FamApp users receive a message on WhatsApp from an attacker claiming to be an employee at FamApp, offering a reward of Rs. 10K or GPRC give away. The "representative" requests personal details, including an their mobile number & the OTP sent to their phone. They assumed it's legitimate and got tricked. Next thing you know, the attacker enters their account, accessed their FamX account and took out all their money.

Understanding Social Engineering:

Social engineering is a psychological manipulation technique used by cybercriminals to trick individuals into divulging confidential information. It preys on human vulnerabilities, such as trust and curiosity, to gain unauthorized access to accounts or sensitive data.

To prevent this to happen to any of our FamApp users, and to make sure your money is completely safe, we're rolling out Two-Factor Authentication (2FA) on FamApp, because protecting your hard-earned money is non-negotiable. Let's delve into why this step is crucial and how it works.

Understanding 2FA:

2FA or Two Factor Authentication is a security process that requires two authentication methods to gain access to an account. It adds an extra layer of protection beyond just a password. Think of it as having both a key and a combination lock on your vault.

How It Works on FamApp:

1. SIM and Device Binding: This involves uniquely binding your device to registered phone number. This involves sending an SMS from your registered phone number to us to verify your identity.
2. Email Verification: As part of additional security step we verify your email id too.

Why 2FA Is Your Shield:

1. Enhanced Security: By requiring multiple forms of authentication, 2FA significantly reduces the risk of unauthorized access. Even if a hacker obtains your phone number, they'll still need access to your SIM card and email to breach your account.
2. Protecting Your Assets: Your FamApp account houses your financial resources. Implementing 2FA ensures that your funds remain secure and inaccessible to malicious actors.
3. Combatting Social Engineering: 2FA acts as a barrier against social engineering attacks. Even if you're tempted by enticing offers or urgent requests for information, the additional authentication step provides an extra layer of defense.

FAQs

What happens if I don't have access to my SIM card or email during login?
In such cases, you will encounter difficulties accessing your account. It's essential to ensure that you have access to both your SIM card and email for seamless authentication. Even during the OTP login system, you would still need access to your sim card to enable UPI payments on FamApp, so that hasn't changed. We have just introduced this step during the entry-point to keep your funds safe.

Can I disable 2FA if I find it inconvenient?
At FamApp, we prioritize the security of your account. Disabling 2FA is not an option, as it significantly enhances the protection of your funds and personal information and is just a one-time action.

I'm having trouble receiving the silent SMS. What should I do?
If you're experiencing issues with receiving the silent SMS on iOS, ensure that your device has an active internet connection and try sending the SMS again. If the problem persists, reach out to our support team for assistance.

Is 2FA mandatory for all users?
Yes, 2FA is mandatory for all users on FamApp. We're committed to ensuring the highest level of security for our users, and 2FA is a crucial component of our security measures.

Can I use the same email address and mobile number for multiple FamApp accounts?
No, each FamApp account must be associated with a unique phone number & email address. You can only use one account on your device and the same person cannot have more than one account.

What should I do if I suspect unauthorized access to my account despite having 2FA enabled?
If you suspect unauthorized access to your account, immediately change your password, revoke access to any connected devices, and contact our support team for further assistance. We take security incidents seriously and will investigate the matter promptly.

I've lost my phone with the SIM card linked to my FamApp account. What should I do?
If you've lost your phone with the linked SIM card, contact your mobile service provider to deactivate the SIM card. Additionally, reach out to our support team to assist you in securing your account and updating your authentication methods.

Remember, if you have any further questions or concerns regarding 2FA or any other aspect of FamApp, don't hesitate to reach out to our dedicated support team at support@famapp.in. We're here to help ensure a secure and seamless experience for all our users.

Until next time. Till then, Stay Vigilant, Stay Secure.

For starters

Before diving into investing in any commodity, it's crucial to understand the dynamics of 'buy' and 'sell' prices, price spreads, and the rationale behind them.

Whether you have prior experience in investment or not, when engaging in precious metals investment or commodity trading such as DigiGold, you'll encounter two key parameters: the 'sell' and 'buy' prices.

What do these prices signify, and why is the 'sell' price consistently lower than the 'buy' price across all commodities? Let's delve into it.

Understanding 'Buy' and 'Sell' Prices

The 'buy' or 'bid' price is what you pay to acquire a share or any commodity, while the 'sell' or 'ask' price is what you receive upon selling that share or commodity.

The 'buy' price is what you'll pay when you wish to buy some gold. It's like the price tag on that PS5 you've been eyeing.

Now, the 'sell' price is what you'll get when you decide to part ways with your digital gold. It's like selling your old pokemon cards to make some extra cash.

Price Spread

The difference between the 'buy' and 'sell' prices of DigiGold represents the commission paid to brokers or intermediary entities facilitating your trades, known as the 'spread'. You know, like when you order food delivery and there's a small extra charge? Same idea here.

Despite electronic connectivity between buyers and sellers, human involvement in this trade invokes compensation. The spread typically centres around the market price, which falls between the buy and sell prices.

The 'buy' price of your DigiGold will always exceed its 'sell' price, with the price you pay or receive fluctuating slightly from the market price due to this spread.

Illustrating the Spread with an example

Imagine you're at your school fair where all the students are trading snacks. You have a delicious chocolate bar you want to sell, and your friend is interested in buying it.

The 'buy' price is what your friend is willing to pay you for the chocolate bar. Let's say they offer you 20 rupees.

Now, if you decide to sell the chocolate bar to your friend, you'll agree on a 'sell' price, which might be a bit lower than what they're willing to pay. So, let's say you agree to sell it for 15 rupees.

The difference between what your friend is willing to pay (20 rupees) and what you agree to sell it for (15 rupees) is the 'spread'. In this case, it's 5 rupees.

Now, why is the 'sell' price lower than the 'buy' price? Well, think of it this way: when you're selling something, you want to make it attractive to buyers, so you might offer a slightly lower price to encourage them to buy it. On the other hand, when you're buying something, you're willing to pay a bit more to get what you want.

So, in the end, the 'spread' helps to balance the interests of both the buyer and the seller in a trade.

Just like at the school fair, in the financial world, there are similar 'buy' and 'sell' prices for different things like stocks, gold, or even digital items in online games. Understanding these prices and the spread between them can help you make smart decisions when buying or selling things in the future!

But if the sell price is always lower than the buy price, how is it a beneficial commodity to invest in? This is not always the case. The buying and selling prices for digital gold are carefully regulated to make sure everything's fair and square.

Let’s understand this using an example -

Imagine you're trading Pokémon cards with your friends. You've got your Charizard, and someone else has a Pikachu. You both agree to trade, but maybe you throw in a couple of extra cards to sweeten the deal. That's kinda how buying and selling digital gold works – it's all about finding that fair exchange.

And just like in the Pokémon world, prices can go up and down depending on all sorts of things. Maybe there's a new game coming out that everyone is hyped about, or maybe there's a limited edition card that everyone is scrambling to get. Same deal with digital gold – supply, demand, and other market factors can all influence the prices. Note that the demand grows when buyers outnumber sellers, and prices rise as a result. When the number of sellers outnumber the number of buyers, supply rises while demand and price fall.

Factors Affecting Price Spread in Gold

Gold, like any traded commodity, experiences a buy-sell spread influenced by factors such as price volatility, supply, external market conditions, and additional expenses like GST and handling fees in digital gold transactions.

Closing Thoughts

Understanding the dynamics of buy and sell prices, price spreads, and their implications across various commodities is crucial for informed investing and trading decisions.

Hope you found this useful, Happy trading!

Hi, my name is Shifa and I work in the Customer Success team at FamPay. A typical day for our team involves resolving user queries, answering product related questions and using the user feedback to improve the product. BTW, we have recently delivered our 50,000th FamCard. Woohoo!

Most of you teens want to know more about our star product- FamCard, and I have decided to answer some of the top questions on FamCard we receive on our customer chat, here goes!

💳 What is FamCard?

FamCard is a prepaid card specially designed for FamPay users. As soon as you create an account with us, you'll be able to access your card in the app for all your online purchases. To swipe the card at offline merchants, you need to place an order for the physical card.

Watch my debut video here:

⭐ How is it different from a debit/ credit card?

FamCard is just like a debit card. It is prepaid, so you have to add money into your FamPay account (or you can get your parents to add it for you) and then you can use the card to spend that money online/offline. You can even track your expenses on the app!

It is not a credit card, that means you won’t be able to use it if the payment amount exceeds your account balance. But there are some credit card features that we have enabled 🤩. We have introduced something so rewarding just for you - FamCoins  - so every payment you do from the FamCard will get you a chance to earn FamCoins! (pretty much the rewards of a credit card, right?!)

What's more? Unlike other debit/credit cards, this is Numberless - meaning, 16 digit card number and CVV is not printed on the physical card. Instead, they are available only on the app, making it safe from misuse just in case you lose the card! Extra secure, right? You can block/pause your card on the app if lost/stolen.

🤩 Can I customize my FamCard?

Of course, you can! Go crazy on the personalization. Before you place the card order, personalize your card and if you wanna be named Batman, then you get a card with that name!

🚛 How can I order a FamCard

Easy-peasy! You can order the card from the app. Just go on the card screen, click on order card, fill in your details and we'll deliver it at your doorstep.

⏲ How much time does it take to deliver a FamCard?

We try to ensure your FamCard reaches you in 10-14 working days. But sometimes, the courier team might take extra time, because they really work hard and have a lot of deliveries to do!

🖲 How can I track my FamCard?

You can do that on the app! You will be able to track your FamCard on the card screen. Just click on Track order on that screen and you can track your FamCard until it reaches your doorstep.

📇 Where can I use the FamCard?

All our cards are registered on the RuPay network. FamCard can be used everywhere in India where RuPay cards are accepted online and offline (across 40+ million merchants)

For those who were waiting for FamCard to be swiped at non-RuPay terminals, here's a good news coming soon for you!

You can swipe your FamCard in person or transfer money digitally on all your favourite sites, such as Amazon, Zomato, Swiggy, Uber, etc.

Book your movie tickets, get a cab, buy a gift, grab a snack! Wherever there's a fun-way, there's FamPay!

⚡ Where can I view the Card Number and CVV?

Every card has a unique 16-digit number called the card number and a 3 digit CVV code. Your FamCard's number and CVV is stored in your app and can be found in the virtual card section of the app. Just click on the eye symbol and enter your phone passcode and you can view the CVV.

🔢 Once I get a FamCard, How do I generate a pin?

Every FamCard comes with an instruction leaflet with steps to activate it. You would ideally set the PIN for your FamCard while activating the card itself.. Don’t worry, if you forgot the PIN, you can go to card settings and click on ‘Change PIN’ to set a new one.

🏧 Can I withdraw cash using a FamCard?

Nope, you cannot! You can always transfer the money in your FamPay account to any other bank account to withdraw money. But we strongly advocate avoiding cash to stay safe and contactless and also to promote the growth of India's digital payments! 🙌

If you already have a FamCard hope these questions help you navigate through the next steps. If you don’t have a FamCard yet, what are you waiting for?!!

Got some more questions on FamCard? Drop us an email at support@fampay.in

Hello there, new to KYC? We have compiled a list of Frequently Asked Questions and answered them to help guide your seamless onboarding process. Here it goes!

Why do you need to verify Aadhar KYC on FamPay?

It is simple & quick and allows you to get the best features with the best security. As we verify your identity, and also of everyone else who uses FamPay, it makes it all super secure! 🔒

That's not all of it!

On completing your KYC, you are entitled to all the premium features on the FamPay app, such as:

1. Payments via your FamCard 💳
2. Instant sharing of money with friends and family  💰
3. Shop at your favourite stores 🛍
4. Access to rewards, exciting challenges and discounts on the app! 🤑

Learn more about the benefits in our blog!

Additionally, KYC is also a legal and regulatory requirement to prevent fraud, identity theft, etc.

To make the process fully secure, FamPay does not store any information that you provide us to verify yourself. Hence, you can be at ease while enjoying all the cool features on the app!

Since you've got all the necessary details on Aadhar KYC now, let's try to solve some of the issues surrounding it 💪🏼

I'm not sure which mobile number📱 is linked to my Aadhaar

Follow the steps below to clear the confusion!

Step 1: Visit the Aadhaar Website 📲

Step 2: Enter your Aadhaar number 🤳🏽

Step 3: The page will show 'Verification Complete!', and the last 3 digits of the number linked to your Aadhaar. 💯

My Aadhaar is linked to a mobile number which is no longer in use

No worries! Here is what you can do:

Step 1: Visit your nearest Aadhaar Centre 🛺
( Tip: Use the search by 'State' option to get a list of all centres in your city)

Step 2: Ask for Update or Correction form 🔖  (or download from here)

Step 3: Carry your original Aadhaar Card for verification. Yes, no other documents required!

Step 4: Submit the form and verify your biometric details. (Yes, the thumb impression!) 👍

Step 5: Collect the acknowledgment slip and wait for 10 days for it to get updated

Step 6: Treat yourself to an ice-cream 🍦 You deserve it 😉

Tip: You can also visit your nearest telecom operator store 🏪  . Please check with your nearest store if they have the facility to get this done :)

My Aadhaar is not linked to a mobile number yet

This process is exactly the same as updating your linked number. Here's what you need to do:

Step 1: Visit your nearest Aadhaar Centre 🛺
( Tip: Use the search by 'State' option to get a list of all centres in your city)

Step 2: Ask for Update or Correction form 🔖  (or download from here)

Step 3: Carry your original Aadhaar Card for verification. Yes, no other documents required!

Step 4: Submit the form and verify your biometric details. (Yes, the thumb impression!) 👍

Step 5: Collect the acknowledgment slip and wait for 10 days for it get updated

Step 6: Treat yourself to an ice-cream 🍦 You deserve it 😉

Tip: You can also visit your nearest telecom operator store 🏪  . Please check with your nearest store if they have the facility to get this done

Umm, I'm still not clear 😕

Not an issue. Our support will come to your rescue! Say hello@fampay.in  🤓

You can also dial ☎️  1947 for any kind of Aadhaar Help, or visit their website 📲   for more details

Bengaluru, India, Jul 29th, 2021- After the successful launch of their numberless FamCard, FamPay has launched India’s first Visa Prepaid Card for teenagers with personalized doodles on it. The card will allow teens to make NFC-enabled contactless payments on the Visa network in India. The card will be available in two different designs - the FamCard and FamCard Me. Teens will be able to design their own card to reflect their personality, playing with names, fonts and doodles.

With FamPay, teens can make online and offline payments using the FamCard and the FamPay App. The launch of FamCard Me marks yet another innovation in the fintech  and card industry, being the first ever doodle card in India. FamPay crossed 2 million registered users within 8 months of its launch and recently raised a Series A funding of $38 Million with Elevation Capital and Sequoia Capital as lead investors.

“If there's trustworthiness and style in a product, it's very hard for GenZ to resist it. After launching India's first numberless card, we decided to up our game in terms of innovation and personalization. Our new series of FamCards powered by Visa would be the most rewarding, sleek, and secure cards in the market for teens”, says Kush Taneja, Co-founder, FamPay.

The FamCard Me will be the first doodle card in India. It will also be the first time Visa forays into numberless cards. Teens can select from a range of 200+ doodles and signature fonts to create unique designs on their FamCard Me. They can also choose to put any name on the card, making it their own card, their own design. Added benefits of the card include 4x rewards on every spend, complimentary subscriptions of teen popular brands and exclusive Visa specific offers.

TR Ramachandran, Group Country Manager, India and South Asia, Visa said, “We are delighted to partner with FamPay as they seek to innovatively solve for digital payments for young adults and teenagers who are digital natives, adept at using novel payment methods with ease. These youngsters today are seeking user experiences that are unique and personalized, with card products they can identify with. FamCard Me caters to this growing segment of discerning consumers and we see strong potential in the Indian market. These innovative, numberless payment cards with personalized doodles will appeal to a generation that is seeking the best of innovation and convenience for its payment experience.”

Explaining why FamPay chose doodles for their new FamCard Me, FamPay Co-founder, Sambav Jain says, “We’ve had a user-first approach since day one. Our team is closely connected with our teen community to understand their lifestyle and what they love the most. As GenZs are super unique and quirky - we wanted them to express their story through their card and hence chose doodles. We are calling it the FamCard "Me" as it's not just personalised, it is their personality.”

FamPay rolled out their virtual Visa Cards in May 2021, and more than 2,00,000 users have adopted it in just the first few weeks. Starting today, teens can order the FamCard once their account is set up on the FamPay app. In addition to being doodled and personalized, the FamCard Me also gives exclusive offers and subscriptions to its teen users, the details of which can be found on famcard.me. They can immediately start using their virtual FamCard for online payments, while they wait for their physical cards to arrive.  For every card sale, FamPay has  pledged a meal for a child in partnership with Feeding India by Zomato. They have also tied up with Give India Foundation to contribute towards Covid-19 relief initiatives, for every card purchased.

FamPay invests heavily in research and product design to ensure a teen’s personal finance journey is smooth sailing. With a number of in-app elements, their goal is to gamify and make the process interactive and fun. Like all other FamPay offerings, the FamCard and the FamCard Me are designed with style while keeping in mind the security of teens.

About Visa

Visa Inc. (NYSE: V) is the world’s leader in digital payments. Our mission is to connect the world through the most innovative, reliable and secure payment network - enabling individuals, businesses and economies to thrive. Our advanced global processing network, VisaNet, provides secure and reliable payments around the world, and is capable of handling more than 65,000 transaction messages a second. The company’s relentless focus on innovation is a catalyst for the rapid growth of digital commerce on any device for everyone, everywhere. As the world moves from analog to digital, Visa is applying our brand, products, people, network and scale to reshape the future of commerce. For more information, visit About Visa, visa.com/blog and @VisaNews.

About FamPay
FamPay is India's first online and offline card payments for teenagers. With FamPay and its numberless prepaid card, minors can successfully make online and offline payments without the need to set up a bank account. We aim to raise a new, financially aware generation of Indians who understand the fundamentals of personal finance and are capable of making decisions in their best long term interest.

FamPay was founded in 2019 by Indian Institute of Technology (IIT) Roorkee Graduates, Kush Taneja and Sambhav Jain while still in college, which makes them the youngest fintech entrepreneurs in India today. They have also been featured on the Forbes 30 under 30 Asia 2021 list. In June 2021, FamPay raised one of India’s biggest Series A funding round of $38 Million with Elevation Capital and Sequoia Capital as lead investors. In March 2020, FamPay raised seed funding of US $4.7Mn from Y Combinator, Venture Highway, Sequoia India and Global Founders Capital (GFC). Neeraj Arora, ex-WhatsApp, Twitch cofounder Kevin Lin, Robinhood cofounder Vladimir Tenev, CRED founder Kunal Shah, Pine Labs CEO Amrish Rau also participated in the round.

For more information, visit www.fampay.in

To know more about FamCard Me, visit famcard.me

Bengaluru, September 24th, 2021: FamPay, India’s first payments app for teenages, has been featured in LinkedIn’s Top Startups List of 2021. The annual LinkedIn’s Top Startups List covers the most sought after companies of the year, in terms of their work culture, customer experience, employee engagement and investor relations. Being India’s first payments App and Card exclusively for teens,  FamPay strives to provide financial freedom to GenZ,  opening the Fintech industry to a target audience that’s never been tapped before.

FamPay was launched in 2020 by Indian Institute of Technology (IIT) Roorkee Graduates, Kush Taneja and Sambhav Jain while still in college, making them one of the youngest fintech entrepreneurs in India today. A startup that was born in the pandemic, it’s seen a staggering growth since its inception with more than 3  million registered users, swiftly gaining the confidence and trust of Indian teens. The company recently completed one of India’s biggest Series A fundraise of US$38 million, led by Elevation Capital and major participation from existing investor Sequoia Capital India.

Commenting on their achievement, Kush Taneja, Co-Founder, FamPay, said, “We are immensely honoured to be on this list and truly believe that it wouldn't have been possible without our outstanding team, their constant strive for excellence and the culture they’ve created. These factors deeply encourage collective growth, capitalise on curiosity and are entirely led by customer-centricity.”

This prestigious feature is testimonial to all the innovation brewing at FamPay in recent times. In 2021, FamPay partnered with the Visa Network to launch the Visa FamCard - India’s first numberless Visa Card exclusively for teens. FamPay followed this successful launch by a set of cards that took personalization to a whole new level with the FamCard Me - India first and only doodle card for teens. To lead this product innovation and strategy, FamPay is looking to hire for multiple roles across various verticals.

Sambhav Jain, Co-Founder, said, “Kush and I have been following this prestigious list and the startups it has featured in the past since its inception. It is tremendously humbling for our entire Fam to be featured here. Over the past few months, we have welcomed some phenomenal leaders and passionate folks onto the team who have made this possible.”

Growing 10x from a 6 member team to today a 60+ members team, the common goal of enabling financial independence for teens is etched in the team’s work ethic. This recognition reaffirms FamPay’s belief in the mission and vision that drives the people and the culture of the company.

About LinkedIn Top Startup List:

The LinkedIn Top Startups list is derived from a blended score looking at factors including employment growth, engagement with the company and its employees, job interest, and the ability to attract top talent, and is informed by the billions of actions taken by more than 645+ million members on LinkedIn.

The Top Startups list is a part of the LinkedIn List franchise, an ongoing editorial series that celebrates professionals and companies making an impact in the professional world. To see the full list of the LinkedIn Top Startups, click here:

About FamPay:

FamPay is building India’s first neo-bank for teens. With FamPay and its numberless prepaid card, minors can successfully make online and offline payments without the need to set up a bank account. With our app and our numberless card, minors can safely and successfully make online and offline payments without the need to set up a bank account. We aim to raise a new, financially aware generation of Indians who understand the fundamentals of personal finance and are capable of making decisions in their best long term interest.

FamPay was launched in 2020 by Indian Institute of Technology (IIT) Roorkee Graduates, Kush Taneja and Sambhav Jain while still in college, which makes them one of the youngest fintech entrepreneurs in India today. They have also been featured on the Forbes 30 under 30 Asia 2021 list.

Media Contacts:

Priya Bellani, e: priyaa@80-db.com, + 91 9818151107

Anika Sahni, e: anika@80-db.com, +91 9810648763

For more information, visit www.fampay.in

Important Links:

App - get.fampay.in

Website - fampay.in

Hiring - join.fampay.in

A card app? For teens?!

We don't blame you (or your parents) for thinking twice about how much trust they can put in FamPay. 🤔 We all know just how important security is, especially when it comes to trusting someone, or something with your money. That's why we've written this blog.

Allow us to explain exactly why and how FamPay is the most safe and secure neo-bank for teens!

We are partnered with an RBI regulated entity PPI issuer 🏦

By partnering with a bank, we are allowing the best of the best payments and financial services to be provided through our app and prepaid card. As the bank takes care of important backend processes, we work on allowing our users to have the best experience with us.

FamPay doesn't require linking of bank account 🚫🔗

The FamPay account is reloadable and requires you to load money into your account before you can spend it. It is not linked with any bank account, meaning until you have loaded money into the FamPay app, you will not be able to spend it. The FamCard also works in the same way. This way, you can always be assured that extra money can never be deducted from your bank account, and that you have the liberty to set spending limits for yourself.

There are no hidden charges, and no minimum balance 🤑

With FamPay, you can have the assurance that your money won't magically disappear in the form of hidden charges! There is also no minimum balance that you are required to maintain in your FamPay account, which makes it all the more convenient.

The FamCard is numberless 💳

The FamCard has no numbers on the physical card, which makes it very secure. The card number and other details (expiry date, CVV) are stored securely within the FamPay app instead of being printed on the physical card. There’s no fear of card information getting misused in case it gets stolen or lost and the card can be paused, blocked and managed at your fingertips on the app. Additionally, the card details within the app can be accessed only with device lock such as fingerprint, face ID, pattern lock or PIN.

You can click here to know more about our numberless FamCard!

Built by IIT grads, believed by the best 👨‍💻👨‍💻

With an itch to inculcate the value of money in the youth of India, and lead them towards financial literacy, Sambhav Jain and Kush Taneja founded FamPay immediately after graduating from IIT Roorkee. The founding team started with 6 IITians, and has now encompassed over 50 members from across the country. FamPay is also backed and trusted by Sequoia, Y Combinator, and several noteworthy investors such as Kunal Shah (Founder of Cred), Kevin Lin (Co-founder of Twitch), Neeraj Arora (Ex-WhatsApp), and more!

Read more about our founders' journey here.  

Our team is constantly working on handling errors 🦹‍♀

The reconciliation team works tirelessly to take care of any transactions that get stuck. We are aware of how frustrating such a situation can be, which is why we've got our best minds solving such issues. In case of any payment issues, our team takes care of the payment manually, so you can be assured that your money is still safe. This includes refunding any failed transactions within 5-7 working days.

Click here to know more about payment issues and how our team works on fixing them.

Why do online payments get stuck and what can you do? 🤔

Why do online payments get stuck and what can you do? Tiara from Finance at FamPay is here to help you understand this.

UnRead by FamPayTiara D’Souza

Our Customer Support is here to help 🦸‍♀️

If you ever face any issues, do not worry as our customer support is always available and ready to assist you.

For basic queries, you can refer to the FAQs section found in the app, as well as on our website. In case you are stuck and your query is still not solved, you can reach out to us on email (support@fampay.in), or talk to us through chat support available on the app.

And that's it! Now you can take comfort in the fact that your money and information will always be safe with FamPay. ❤️ Go ahead and share this piece with your friends and family to help ease any anxiety they may have in relation to making payments on our app. You'd be doing them a favour. 🤗