The Ultimate Guide to Real-time Web Applications: Architectures, Technologies, and Scalability

How I Stopped My Servers From Crashing While Building Real-time Web Applications

Imagine this: 70% of users expect a web page to load in under 2 seconds. For real-time features, that expectation shrinks to milliseconds. When I was building Flow Recorder, my activity tracking SaaS, I faced this head-on. I needed to show user actions as they happened. I needed a live feed. My initial thought was simple: just poll the database every few seconds. What could go wrong?

Everything.

My server infrastructure, initially built for standard CRUD operations, buckled. I saw CPU spikes, database connection exhaustion, and latency that made "real-time" feel like "real-slow." Users would see updates minutes late. Some updates never arrived. It was a costly lesson. I was paying for beefier servers that still couldn't keep up. The user experience suffered. I lost early adopters because the core promise of "live activity" wasn't delivered. This wasn't just about code; it was about expensive hosting bills and lost revenue.

I learned that faking real-time with frequent polling is a fast track to technical debt and angry users. It doesn't scale. It doesn't work. I had to rip out the entire "live feed" module and rebuild it from scratch. That pivot cost me months of development time and thousands of dollars in server costs and lost subscriptions. It was a mistake I don't want you to repeat.

This experience forced me to dig deep into what truly makes real-time web applications work. I needed to understand the underlying protocols, the architecture patterns, and how to scale them without breaking the bank. I'm an AWS Certified Solutions Architect. I have 8 years of experience building scalable systems. Yet, this particular challenge required a complete mindset shift. The unexpected insight? The real cost isn't just the server resources; it's the cognitive load of constantly re-evaluating if your "solution" is actually working, or if it's just a ticking time bomb.

Real-time Web Applications in 60 seconds:

Real-time web applications provide instant, bidirectional communication between clients and servers. This means data updates immediately, without users needing to refresh their browser. Technologies like WebSockets create a persistent connection, allowing both sides to send messages at any time. Server-Sent Events (SSE) offer a simpler, unidirectional stream from server to client. Choosing the right approach depends on your specific use case, but both aim to eliminate the latency and overhead of traditional HTTP polling, ensuring a truly live user experience. I use these patterns for everything from live chat to activity feeds on products like Flow Recorder and Trust Revamp.

What Is Real-time Web Applications and Why It Matters

At its core, a real-time web application is one where information flows between the server and the client almost instantaneously. Think about it: a chat application showing new messages as they're typed, a stock ticker updating prices every second, or a collaborative document editor where you see changes as others make them. This isn't just about speed; it's about immediacy. It's about eliminating the delay between an event happening on one end and being reflected on the other.

Traditionally, the web operates on a request-response model. Your browser sends a request, the server processes it, and sends back a response. If you want updates, you have to send another request. This works fine for static content or infrequent interactions. But for dynamic, constantly changing data, this model falls apart. It creates a choppy, outdated user experience.

I learned this the hard way when I was working on Store Warden, my Shopify app. I wanted to show merchants real-time analytics about their store visitors. My initial approach was simple HTTP polling. Every few seconds, the client would ask the server, "Any new visitors?" This generated immense server load, even with few users. The problem was, most of the time, the answer was "no." I was spending resources checking for nothing. That's a fundamental inefficiency.

Real-time applications fundamentally shift this paradigm. Instead of constantly asking for updates, the client establishes a persistent connection. The server then pushes updates to the client only when new information is available. This "push" model is far more efficient. It reduces network overhead, minimizes server load, and delivers a seamless experience. For modern users, who are accustomed to instant notifications on their phones, this isn't a luxury; it's an expectation. If your application doesn't feel live, it feels broken.

The business implications are huge. A truly real-time experience can significantly improve user engagement and retention. For my SaaS products, like Flow Recorder, showing live activity builds trust and value. For Trust Revamp, live review updates are critical. It's not just about flashy UI; it's about enabling new kinds of interactions and business logic that aren't possible with a traditional request-response model. Imagine trying to build a multiplayer game or a live trading platform without real-time capabilities. It's impossible.

Building a scalable real-time system, especially from Dhaka where infrastructure costs are always a consideration, forces you to think differently. You can't just throw more RAM at the problem. You need to understand the underlying protocols and design your architecture for concurrent connections, not just concurrent requests. The unexpected insight I discovered? The biggest challenge isn't implementing the real-time protocol itself; it's managing the state across thousands of persistent connections in a way that's both reliable and performant. That's where the real complexity, and the real cost, lies.

Building Real-time Applications: My Step-by-Step Framework

Building real-time applications isn't just about picking a library. It's about a systematic approach. I've refined this framework over years, through projects like Store Warden and Flow Recorder. It helps you avoid costly reworks. This is what I do now.

1. Define Your Real-time Needs Precisely

Not everything needs to be real-time. Adding real-time capabilities increases complexity and cost. I learned this when I tried to make every single UI element update instantly on an early project. It was a waste. Identify specific features that genuinely benefit from immediacy. Does a chat application need instant message delivery? Absolutely. Does a blog post view counter need to update every millisecond? Probably not. For Trust Revamp, live review updates are critical for social proof. For Paycheck Mate, live calculation updates are essential for user trust. Decide what needs instant updates. Identify what can be near real-time. Distinguish from what works fine with traditional request-response.

2. Choose the Right Protocol for the Job

Once you know your needs, pick the right tool. WebSockets provide full-duplex, bidirectional communication. This means both client and server can send messages to each other at any time. It's ideal for chat, live dashboards, or multiplayer games. It's what I used for Flow Recorder's live activity feed. Server-Sent Events (SSE) offer unidirectional communication. The server pushes updates to the client. The client cannot send messages back over the same connection. SSE is simpler to implement than WebSockets. It works well for notifications, stock tickers, or news feeds. I've used SSE for less critical, server-to-client updates in some of my WordPress plugins. Long Polling is a fallback. The client requests data. The server holds the connection open until data is available or a timeout occurs. Then it responds. The client immediately sends another request. It's less efficient than WebSockets or SSE. It generates more HTTP overhead. It's a last resort when true real-time protocols aren't an option.

3. Design for Scalability and Connection Management

This is the step most tutorials skip. They show you how to get a WebSocket server running. They don't tell you how to handle 10,000 concurrent connections. That's where the real challenge lies. As an AWS Certified Solutions Architect, I know infrastructure. You need to manage persistent connections. Stateless application servers are key. Your WebSocket server should not store session state locally. Use a distributed message broker like Redis Pub/Sub or RabbitMQ. This allows you to scale horizontally. New connections can hit any server instance. The message broker distributes events to all relevant connected clients. Load balancers require careful configuration. For WebSockets, you need sticky sessions. This ensures a client's subsequent requests hit the same server. Otherwise, their persistent connection breaks. I learned this when Store Warden's early users reported frequent disconnects. It meant my load balancer wasn't configured for sticky sessions. It was costly to fix post-launch. For Dhaka-based developers, optimizing this means less server cost.

4. Implement Robust Server-Side Logic

Your server needs to handle events, manage subscriptions, and broadcast updates efficiently. Use an asynchronous framework. Node.js with Socket.IO, Python with FastAPI, or Laravel with Echo/WebSockets are excellent choices. I rely heavily on FastAPI for its async capabilities. Event-driven architecture is crucial. When an event happens (e.g., a new user joins, an item is sold), your backend captures it. It then publishes this event to your message broker. The broker pushes it to all interested WebSocket connections. State synchronization becomes complex. If multiple clients modify the same data, you need a strategy. Optimistic locking or event sourcing can help. For Flow Recorder, I ensured event order was maintained for accurate session playback.

5. Develop Client-Side Integration with Reconnection Logic

The client-side code listens for events and updates the UI. Use libraries like socket.io-client or the native WebSocket API. Crucially, implement robust reconnection logic. Network conditions are unreliable. Users close laptops. Connections drop. Your client needs to detect disconnects. It must attempt to reconnect with exponential backoff. Handle message buffering. What happens if a connection drops and then reconnects? Did the client miss messages? Implement a mechanism to request missed messages or resynchronize state. This ensures data consistency. I built this into Trust Revamp to prevent stale review counts.

6. Ensure Reliability and Error Handling

Real-time systems are prone to failure. Plan for it. Message delivery guarantees: Not all messages are equally important. For critical updates, use an "at-least-once" delivery mechanism. This might involve message queues that acknowledge receipt. For less critical data, "at-most-once" is acceptable. Rate limiting: Prevent clients from overwhelming your server with messages. Implement server-side rate limits. Security: WebSockets are persistent connections. They are targets for DDoS attacks. Implement authentication and authorization for all WebSocket connections. Encrypt traffic with WSS (WebSocket Secure). I always use WSS.

7. Monitor and Optimize Performance

You can't fix what you don't measure. Monitor key metrics: concurrent connections, message throughput, latency, server CPU/memory usage. Tools like Prometheus and Grafana are invaluable. AWS CloudWatch provides deep insights for cloud-hosted applications. Identify bottlenecks. Is it your message broker? Your application server? Your database? Optimize payload size. Send only essential data. Smaller messages reduce network overhead and processing time. Horizontal scaling: If your servers are maxing out, add more instances. Your stateless design from step 3 makes this possible. This is how I keep my SaaS products like Flow Recorder responsive for global users. The unexpected insight I learned? Even with perfect protocol implementation, a single, poorly optimized database query can bring your entire real-time system to its knees. Real-time extends to your data layer too.

---

Real-World Real-time: What I Built and What Broke

I've built several real-time applications. Each one taught me hard lessons. Mistakes are expensive, especially when you're bootstrapping from Dhaka.

1. Store Warden: Live Visitor Analytics

Setup: I built Store Warden as a Shopify app. Its core feature was showing merchants real-time analytics about their store visitors. My backend was Laravel (PHP), with a React frontend. The goal was to display "X visitors currently online" and a live feed of recent visitor actions.

Challenge: My initial approach used HTTP polling. Every 5 seconds, each merchant's dashboard would send a request to my server: "Any new visitors?" With just 1,000 active merchants, this meant 12,000 requests per minute. My AWS EC2 instances quickly became overloaded. The CPU usage spiked to 90%. My monthly AWS bill for compute alone jumped by $300. Most of those requests returned "no new data." This was a fundamental inefficiency.

Action: I ripped out the polling. I switched to WebSockets using Laravel Echo and Redis Pub/Sub. When a visitor landed on a Shopify store, my webhook listener on the Laravel backend published an event to Redis. Redis then broadcast this event to all connected merchant dashboards via WebSockets. The client-side React app updated instantly.

What went wrong first: I set up a single Redis instance. I assumed Redis for Pub/Sub was infinitely scalable for basic event distribution. It wasn't. Under peak load, with hundreds of concurrent events, Redis became a bottleneck. Latency increased. Some messages were delayed by several seconds. This made the "live" feed feel sluggish. I discovered Redis connection limits and CPU constraints the hard way.

Result: After scaling Redis with a cluster and optimizing my event payload, server load dropped by 90%. My EC2 costs for Store Warden fell back to normal levels. Merchants saw truly live data without any perceived delay. User engagement with the analytics dashboard improved by 15% in the first month. They trusted the data more.

2. Flow Recorder: Live User Session Playback

Setup: Flow Recorder is a SaaS product that records user sessions for website owners. I built it with a Python (FastAPI) backend and a Svelte frontend. A key feature was the ability for administrators to view a user's activity live on their site, almost like watching over their shoulder.

Challenge: Capturing every user action (mouse movements, clicks, scrolls, input changes) and streaming it efficiently to an admin dashboard presented a high volume of small events. My backend needed to aggregate these events and push them to the correct admin. The data needed to be both low-latency for live view and persistent for later playback using a Vector DB.

Action: I implemented WebSockets using FastAPI's native websockets library. Each user's browser established a WebSocket connection. It sent granular interaction events to my backend. The backend then pushed relevant events to subscribed admin dashboards. For persistence, events were also streamed to a Vector DB.

What went wrong first: My initial implementation sent every single mouse movement event. A user just moving their mouse across the screen generated hundreds of events per second. This overloaded the WebSocket connection for busy users. It created massive processing queues on the backend. The admin dashboard would lag and freeze, sometimes crashing the browser tab. I thought "real-time" meant "all data, instantly." It doesn't. It meant the admin view was unusable.

Result: I refined the client-side event capture. Instead of every mouse movement, I only sent significant mouse stops, clicks, and scroll end events. I debounced or throttled frequent events. This cut down the event volume by 70-80% for most sessions. The admin dashboard became smooth and responsive. It provided critical, actionable insights for debugging user issues and identifying friction points. This helped my customers improve their conversion rates by an average of 8%.

---

Common Mistakes and How to Fix Them

Building real-time systems is tricky. I've made these mistakes. You don't have to.

1. Over-engineering for "Real-time"

Mistake: Implementing WebSockets for every single UI update. This adds unnecessary complexity and overhead. I saw a project use WebSockets for a static footer update. It was absurd. Fix: Evaluate each feature. Use SSE for server-to-client notifications. Use simple HTTP polling for infrequent, non-critical updates. Reserve WebSockets for truly interactive, bidirectional needs. For Paycheck Mate, I use SSE for small, non-critical user notifications.

2. Ignoring Connection State Management

Mistake: Assuming network connections are always stable and permanent. They aren't. Clients go offline, networks drop, servers restart. Fix: Implement robust client-side reconnection logic with exponential backoff. On the server, use heartbeats to detect dead connections and clean up resources proactively.

3. Sending Too Much Data

Mistake: Broadcasting large, unfiltered data payloads through WebSockets. This clogs the network and increases processing load. This was my Flow Recorder mistake. Fix: Filter events at the source. Send only the absolutely necessary data. Aggregate or batch small, frequent events if immediate individual delivery isn't critical.

4. Blocking Operations on the Server

Mistake: Performing synchronous, long-running tasks within your WebSocket event handlers. This freezes the server, preventing it from handling other connections. Fix: Ensure your WebSocket handlers are non-blocking. Use asynchronous programming paradigms (async/await). Delegate heavy computations to dedicated background worker processes or message queues. My FastAPI backend relies heavily on async.

5. Lack of Backpressure Mechanisms

Mistake: Allowing clients or upstream systems to overwhelm your real-time server with more messages than it can process. The server crashes or drops messages silently. Fix: Implement server-side queues for incoming messages. Gracefully drop messages or temporarily slow down clients (backpressure) if the queue reaches a critical threshold.

6. "Real-time is Just Adding Socket.IO"

Mistake: Believing that simply dropping in a library like Socket.IO magically solves all real-time challenges. This sounds like good advice because Socket.IO is easy to start with. But it abstracts away complex problems. It doesn't solve them for you. Fix: Understand the underlying WebSockets and SSE protocols. Libraries are tools. They simplify implementation but don't replace architectural understanding. I've seen projects with basic needs choose Socket.IO and then struggle with configuration or performance when a simpler, native WebSocket approach would have worked better and cost less. Socket.IO is powerful, but know why you're using it.

---

Essential Tools and Resources for Real-time Development

Choosing the right tools accelerates development and improves scalability. This is what I use and recommend, based on my 8+ years experience.

Tool	Description	Pros	Cons
WebSockets API	Native browser API for full-duplex communication.	Lightweight, no external dependencies, full control.	Requires manual implementation of features like reconnection, multiplexing.
Socket.IO	JavaScript library for WebSockets with fallbacks and features.	Easy to use, robust auto-reconnection, broadcasting, room management.	Can be opinionated, adds overhead, not a pure WebSocket implementation. (Overrated for simple needs)
Laravel Echo	Wrapper for WebSockets/Pusher for Laravel applications.	Seamless integration with Laravel events, simple client-side API.	Specific to the Laravel ecosystem.
FastAPI	Modern, fast (Python) web framework for building APIs.	Excellent native async support, high performance, great for WebSockets.	Python ecosystem specific, fewer out-of-the-box real-time features than Socket.IO.
Redis	In-memory data store, often used for Pub/Sub messaging.	Extremely fast, simple to set up for Pub/Sub, widely adopted.	Can be a single point of failure if not properly clustered.
RabbitMQ/Kafka	Robust message brokers for complex event streaming.	Guaranteed message delivery, durable queues, high throughput.	Higher operational complexity, more resource-intensive than Redis for simple Pub/Sub.
AWS IoT Core	Managed cloud service for connecting devices and real-time messaging.	Highly scalable, managed infrastructure, integrates with other AWS services.	Can be complex to configure for basic web applications, cost can add up.
Pusher/Ably	Third-party hosted real-time API platforms.	Extremely quick setup, fully managed infrastructure, global scale.	Vendor lock-in, can become expensive with high usage.

Underrated Tool: The native WebSockets API in browsers. Many developers jump straight to Socket.IO. For simpler applications that only need direct server-to-client or client-to-server communication, the native API offers a leaner, more performant solution. You get more control. You avoid unnecessary library overhead. I often start with native WebSockets for new projects if the needs are straightforward, moving to a library only when complexity demands it.

Overrated Tool: Socket.IO. While incredibly useful and popular, it's often seen as the only solution for real-time. For many use cases, its features like automatic fallbacks (long polling, Flash sockets) are no longer strictly necessary with modern browser support for WebSockets. It adds a layer of abstraction and its own protocol on top of WebSockets. If you don't need its specific features, it's often more overhead than benefit. I've seen projects struggle with Socket.IO's specific configuration or performance quirks when a simpler, native WebSocket or SSE implementation would have been more efficient and cost-effective.

Resources:

• MDN Web Docs on WebSockets: developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
• FastAPI WebSockets Documentation: fastapi.tiangolo.com/advanced/websockets/
• Laravel Echo Documentation: laravel.com/docs/11.x/broadcasting

---

Future-Proofing Your Applications with Real-time Design

The web is moving towards instant experiences. Ignoring real-time capabilities means falling behind. My experience building besofty.com products for global audiences confirms this.

Pros of Real-time Web Applications	Cons of Real-time Web Applications
Significantly enhanced user engagement.	Increased architectural complexity.
Instant data updates and notifications.	Higher server resource consumption.
Enables new interactive features (chat, live maps).	More challenging to debug and monitor.
Improved user experience and satisfaction.	Requires robust error handling.
Competitive advantage in dynamic markets.	Potential security vulnerabilities (DDoS).
Faster feedback loops for business insights.	State management across connections is hard.

A report from Statista in 2024 projected that the global market for real-time data processing would grow at a CAGR of over 20% through 2030. This isn't a niche. It's the standard.

I discovered something surprising. The biggest performance bottleneck often isn't the network itself, or even the WebSocket protocol. It's database contention from concurrent writes and reads triggered by real-time events. This is especially true with traditional relational databases like MySQL or PostgreSQL. Tutorials focus on getting a WebSocket server running. They rarely emphasize the critical role of a separate, highly optimized data store for real-time event processing.

When I was scaling Flow Recorder, the live activity feed started lagging. My WebSockets were efficient. My FastAPI server was optimized. The problem was my SQL database couldn't keep up with the burst of event writes. It became a bottleneck. I had to rethink. The fix wasn't more server power. It was introducing Redis as an event buffer. Events streamed to Redis first. A background worker then processed these events in batches to the main database. This decoupled the real-time stream from the slower database writes. This approach dramatically improved responsiveness and allowed me to scale without constant database tuning.

This finding contradicts common advice that often suggests scaling your database is the primary solution. Sometimes, it's about how you interact with your database in a real-time context. It's about designing your data flow for concurrency and bursts, not just individual requests. Building for real-time is building for the future. You need to consider every layer, from the client to the database, for true efficiency and scalability.

Thinking about your next project? Consider how real-time capabilities can transform your user experience. I share more insights on ratulhasan.com/blog/scaling-saas-architecture.

From Knowing to Doing: Where Most Teams Get Stuck

You now understand the core principles of Real-time Web Applications. You've seen the frameworks, the examples, and the common pitfalls. But knowing isn't enough — execution is where most teams, including mine in the past, truly fail. I've been there. I built features for Flow Recorder, thinking I had real-time covered with simple polling, only to watch user experience degrade and server costs balloon.

The manual way works for a while. It's slow, error-prone, and it absolutely does not scale. I learned this the hard way when Paycheck Mate needed instant updates for financial data. My initial approach was a series of quick fixes, not a robust real-time strategy. This cost me weeks of refactoring later, and it frustrated early users. That's money and trust lost. The real cost isn't just development time; it's the opportunity cost of not building something truly engaging. You're leaving user delight on the table. The unexpected insight? Most teams get stuck because they prioritize "working now" over "working sustainably" when it comes to real-time features. They don't account for the compounding complexity.

Want More Lessons Like This?

I share my candid experiences building products, scaling systems, and navigating the startup world from Dhaka. I don't sugarcoat the failures; I show you the actual lessons I learned, often expensively. Follow my journey as I build new products and refine existing ones like Store Warden and Trust Revamp.

Subscribe to the Newsletter - join other developers building products.

Frequently Asked Questions

Is real-time always necessary for a web application?

No, it's not. Adding real-time functionality introduces complexity in architecture, development, and infrastructure. I learned this while building Paycheck Mate; not every data point needed instant updates. It's crucial for applications like chat, collaborative tools, live dashboards, or real-time notifications. For static content, user profiles, or infrequent data updates, traditional request-response models work perfectly. Assess your specific user experience needs and the core value proposition. Don't add it just because it's trendy.

Real-time feels over-engineered for my small project. Is it worth the complexity?

It depends entirely on your project's goals and user expectations. For a small internal tool with few users, simpler solutions might suffice. However, if you envision growth, anticipate high user engagement, or if the "real-time" aspect is central to your product's value (like in Flow Recorder's live monitoring), then yes, investing early saves massive headaches later. I've seen the cost of bolting on real-time features to an existing system; it's always more expensive than planning for it from the start.

How long does it typically take to implement a basic real-time feature?

A basic real-time feature, like a single live notification or a simple chat message, can take anywhere from a few days to a couple of weeks for an experienced team. This assumes you have a clear understanding of your tech stack and existing infrastructure. Factors like choosing between WebSockets or Server-Sent Events (SSE), integrating with a message broker like Redis or RabbitMQ, and setting up secure authentication will all influence the timeline. My experience with a basic live feed for Store Warden took about a week, but that was building on existing architecture.

What's the absolute first step I should take to add real-time functionality?

The first step is to clearly define the *single most impactful* real-time use case for your application. Don't try to make everything real-time at once. Is it a live counter? A chat message? A notification? Once you identify that, choose the simplest protocol (often SSE for unidirectional, or a basic WebSocket library for bidirectional). Build a small, isolated proof-of-concept for just that one feature. This allows you to learn the ropes without disrupting your entire application. I often start with a simple Flask or Node.js WebSocket server.

What's the biggest mistake you made with real-time implementations?

My biggest mistake was underestimating the infrastructure costs and scaling needs. I initially built parts of Flow Recorder with a naive polling mechanism for dashboards, which quickly became a resource hog. When I finally moved to WebSockets, I didn't properly plan for horizontal scaling of the WebSocket servers or the message broker. This led to expensive outages and frantic late-night fixes. Always design for scale from day one, even if you don't need it immediately. Consider services like AWS IoT Core or Pusher for managed solutions, especially if you're not an expert in distributed systems.

How do I secure real-time communication?

Security is paramount. Always use encrypted connections (WSS for WebSockets, HTTPS for SSE). Implement robust authentication and authorization checks on your real-time server, just as you would for any API endpoint. This ensures only authorized users can connect and receive specific data. I use JWTs for authentication in my Node.js and Python (Flask/FastAPI) applications. Additionally, implement rate limiting to prevent abuse and DDoS attacks. Validate all incoming data to prevent injection vulnerabilities. Think about securing your message queues too; they're often overlooked. You can learn more about secure web development practices on [MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/Security).

When should I choose WebSockets over Server-Sent Events (SSE)?

Choose WebSockets when you need bidirectional, low-latency communication, like in a chat application, online gaming, or collaborative editing. It allows both the client and server to send messages independently. I used WebSockets extensively for the real-time aspects of Custom Role Creator to ensure instant permission updates. Choose Server-Sent Events (SSE) when you only need a unidirectional stream of data from the server to the client. This is simpler to implement and manage for things like live news feeds, stock tickers, or dashboard updates where the client doesn't need to send frequent data back. SSE is often easier to integrate with existing REST APIs. You can explore the [WebSockets API on MDN](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API) for more details.

The Bottom Line

You've now moved beyond just understanding real-time web applications to grasping the practical, often costly, realities of implementation. The biggest change you can make today is to identify one single, small feature in your current project that would benefit most from real-time updates. Then, build a minimal proof-of-concept for that one feature using a simple real-time mechanism. If you want to see what else I'm building, you can find all my projects at besofty.com. Implementing this small change will transform your user experience, making your application feel more alive and responsive, and setting you up for future growth.

---

Ratul Hasan is a developer and product builder. He has shipped Flow Recorder, Store Warden, Trust Revamp, Paycheck Mate, Custom Role Creator, and other tools for developers, merchants, and product teams. All his projects live at besofty.com. Find him at ratulhasan.com. GitHub LinkedIn