Mastering Technical Debt: A Strategic Playbook for Scalable Web Applications

The Silent Killer: How I Lost Months and Thousands to Unmanaged Technical Debt in My SaaS

Did you know that technical debt costs software companies an estimated $3 trillion annually? That's not just some abstract number; I've felt a piece of that cost directly. I built Flow Recorder, my Shopify app, to help store owners capture user sessions. When I first launched it, speed was everything. I needed to ship fast. So, I took some shortcuts, particularly around how I handled event processing and database indexing for user session data. I knew it wasn't perfect, but I thought I'd clean it up later. That "later" almost killed the product.

The mistake was simple: I prioritized feature velocity without a clear technical debt strategy. I had a mental note to refactor, but no concrete plan. As Flow Recorder grew and processed millions of events daily, those initial shortcuts turned into massive bottlenecks. Database queries slowed to a crawl. Ingesting new data became a race against time. My servers, which were initially cost-effective on AWS, started struggling under the load. I was paying hundreds of dollars extra each month just for higher-tier instances trying to keep up, and even then, performance suffered.

Customers started complaining about slow loading times for their session recordings. Some even churned, telling me the app wasn't reliable enough. I spent almost three full months, not building new features, but desperately refactoring the core event processing engine and re-indexing the entire database from scratch. This wasn't just fixing bugs; this was a deep, painful excavation of architectural decisions I had made years prior. Those three months cost me not only direct server expenses and customer churn, but also the opportunity cost of what I could have been building instead. I could have launched two new features. I could have started marketing a new product. Instead, I was just trying to keep the lights on.

This experience taught me a hard lesson: ignoring technical debt isn't just about messy code. It's about real money, lost time, and a direct hit to your product's credibility. You cannot scale a SaaS product or any complex web application effectively if you let technical debt fester. As a developer who has shipped over six products from Dhaka to a global audience, I've learned that managing technical debt isn't optional; it's a critical part of your growth strategy. You need a deliberate approach.

technical debt management in 60 seconds: Technical debt management is the conscious, continuous process of identifying, prioritizing, and systematically addressing shortcomings in your codebase and architecture. It involves treating technical debt not as "bad code," but as an investment decision: when to incur it strategically, and when to pay it down to prevent future costs. You'll quantify its impact, prioritize based on business value and risk, and integrate its resolution into your regular development sprints. This isn't about perfection; it's about maintaining velocity and scalability without crippling your team or product.

What Is technical debt management and Why It Matters

Let's cut through the jargon. Technical debt isn't a nebulous concept. It's a tangible outcome of past decisions that makes future development harder, slower, or more expensive. Think of it like this: I needed to build a new feature for Store Warden, my Shopify app for automating product updates. I had two ways to implement a critical data synchronization module: one quick, simple way that hardcoded some logic, and another more robust, modular way that would take an extra week to build. I chose the quick way to hit a deadline. That's a deliberate technical debt. I knew I was taking a shortcut.

But technical debt isn't always deliberate. Sometimes, it's accidental. When I was working on Trust Revamp, a review management platform, the initial database schema seemed fine. As the product scaled and user behavior evolved, we realized some core relationships weren't optimal for the complex queries we now needed. The schema itself became a form of technical debt—not because of a shortcut, but because our understanding of the problem space evolved. The original design was good for its time, but now it was slowing us down.

At its core, technical debt arises from a mismatch between the current state of your code/architecture and what it should be to efficiently meet business needs. It manifests in several ways:

• Increased Development Time: Every new feature takes longer to build because you're navigating spaghetti code or working around existing limitations. When I added new reporting features to Paycheck Mate, I spent more time trying to understand and extend the old, monolithic PHP backend than actually writing new business logic.
• Higher Bug Count: Fragile codebases are prone to unexpected side effects. Fixing one bug often introduces two more. This was a constant headache when I maintained an older WordPress plugin. A minor update to one function would break unrelated features elsewhere on the site.
• Reduced Scalability & Performance: As your user base grows, those quick fixes or suboptimal designs buckle under pressure. My Flow Recorder example perfectly illustrates this. What worked for 100 users absolutely broke for 10,000.
• Developer Morale & Churn: No developer wants to spend all their time untangling a mess. It's frustrating and drains motivation. I've seen teams struggle when they're constantly fighting the codebase instead of building exciting new things.

You might hear people say, "just write good code from the start!" That's a nice thought, but it's anti-real-world. In the real world, especially when you're a founder-developer like me, you're constantly balancing speed, resources, and quality. Shipping a product (like my Custom Role Creator plugin for WordPress) means making trade-offs. The unexpected insight here is that technical debt is not inherently bad; it's a necessary byproduct of shipping software in a dynamic environment. What is bad is ignoring it.

Think of it like money: you might take out a loan (incur debt) to start a business or buy a house. That's strategic debt. It helps you achieve a goal faster. But if you keep taking loans without a plan to pay them back, or if you ignore the interest building up, you'll eventually face bankruptcy. Technical debt works the same way. It's a tool, a lever. You can use it to your advantage, but you must manage it actively. As an AWS Certified Solutions Architect, I've seen countless systems, from small startups to large enterprises, struggle because they treated technical debt as an afterthought. It's a strategic concern that impacts your bottom line and your ability to innovate.

A Practical Framework for Strategic Technical Debt Management

Managing technical debt doesn't happen by accident. It needs a structured approach. I've seen too many teams, including my own in earlier days, just react to debt instead of proactively managing it. This is how you end up in a constant state of firefighting. The unexpected insight here? Technical debt management isn't just a technical problem; it's a strategic business decision. You must connect code issues directly to business impact.

Here's the framework I use, honed over 8 years of building and scaling applications:

1. Identify and Quantify Your Debt

You can't fix what you don't measure. Don't just say, "this code is messy." Pinpoint the specific areas. Quantify the impact.

When I was scaling Flow Recorder, I identified a specific database query in the reporting module. It took 5 seconds to generate reports for 100 customer records. This was acceptable initially. But when we hit 1,000 records, the query time shot up to 30 seconds. For 5,000 records, it often timed out, blocking essential data for users. That's a quantifiable problem. I also tracked the number of bug reports originating from that module. It was consistently 2-3 critical bugs per month.

2. Prioritize by Business Impact

Not all debt is equal. Some debt is costing you money right now. Other debt is just annoying. Focus on the debt that directly impacts your users, revenue, or security.

For that slow Flow Recorder query, I knew it directly affected user retention. Customers couldn't get their data. This was a higher priority than refactoring a small, rarely used admin UI component that had some inconsistent styling. I estimated the slow reports were costing us 5-7 user cancellations per month. Fixing it meant stopping that revenue loss.

3. Allocate Dedicated Time (Debt Sprints)

You can't "fix it as you go" if you want to make real progress. Technical debt needs dedicated attention. This means explicitly scheduling time for it.

When I build Shopify apps like Store Warden or Trust Revamp, I learned to allocate 15-20% of each sprint specifically to technical debt. This isn't always easy to push through, especially with demanding product roadmaps. But it's essential. For example, during one 2-week sprint for Store Warden, I dedicated 3 days to improving the database indexing and query optimization. This reduced average API response times by 300ms across the board. That's a direct improvement for every user.

4. Implement Guardrails (Prevent New Debt)

The best way to manage debt is to stop incurring new, unnecessary debt. This means putting processes in place that prevent future issues.

For Trust Revamp, I introduced mandatory code reviews with clear guidelines. I also enforced unit test coverage requirements for all new features and bug fixes. Before these changes, we saw a new bug introduced for every 5 features shipped. After, new bugs in existing features dropped by 30%. I also integrated static analysis tools like PHP_CodeSniffer into our CI/CD pipeline. This catches common issues automatically before code even gets reviewed.

5. Educate Your Team and Stakeholders

This is the step most guides skip, but it's essential for long-term success. Your developers need to understand why debt management matters. Your product managers and business stakeholders need to understand the costs of ignoring it.

I once showed my team how a particular API bottleneck in Flow Recorder wasn't just slowing down the app; it was directly increasing our AWS server costs by $200 per month. When they saw the financial impact, not just the technical one, their motivation to fix it went up significantly. I also explained to my product manager that delaying a specific architectural refactor meant that the next 3 features they wanted would take twice as long to build. Translating "technical debt" into "lost revenue" or "delayed features" makes the problem real for everyone.

6. Monitor and Re-evaluate

Technical debt is not a one-time fix. It's a continuous process. Your system evolves, requirements change, and new debt will always appear. You need to keep an eye on it.

I set up automated performance monitoring for Paycheck Mate's critical API endpoints. If response times exceeded 500ms for more than 15 minutes, it triggered an alert to my team. This allowed us to quickly identify new bottlenecks as user load increased or new features were deployed. We caught a memory leak in a new reporting service within hours, preventing a full outage.

Technical Debt in Action: My Battles and Wins

I've learned about technical debt the hard way. I've made mistakes. I've also found practical ways to dig out of the mess. The unexpected insight here is that sometimes the "fix" isn't a rewrite of bad code; it's a strategic architectural pivot that renders entire sections of old debt irrelevant.

Flow Recorder's Scaling Nightmare

• Setup: Flow Recorder started as a passion project. It automated browser flows using a simple PHP script running on a single server. I chose PHP because it was fast to develop with.
• Challenge: When Flow Recorder grew past 5,000 daily active users, the monolithic PHP backend and a single MySQL database couldn't cope. Database locks became frequent, causing cascading failures. Page loads went from a snappy 200ms to a frustrating 2-3 seconds for many users. I saw a 15% drop in user engagement and an increase in support tickets related to performance. My server costs were also spiraling upwards due to constant resource contention.
• Failure: My first instinct was to optimize individual PHP functions and SQL queries. I spent a full week tuning complex SQL queries, adding indexes, and refactoring small PHP modules. This improved page load times by maybe 100ms in some areas, but the fundamental single-server, monolithic architecture was still the bottleneck. The core problem remained. I was patching over a systemic issue.
• Action: I realized I needed a more drastic change. I decided to decouple the heaviest processing tasks (browser automation execution) from the main application. I migrated these tasks to a separate Node.js microservice deployed on AWS Lambda. This allowed for parallel, serverless execution, scaling automatically without needing to provision more servers. I also moved the main MySQL database to AWS RDS with read replicas for reporting, offloading the main instance. Finally, I implemented a caching layer with Redis for frequently accessed data.
• Result: The transformation was significant. Critical browser automation tasks, which previously took 10-15 seconds and hogged server resources, now completed in 2-3 seconds on Lambda. Average page load times for the main application dropped to under 150ms. The system easily handled 10,000+ daily active users without breaking a sweat. Server costs, despite using more AWS services, actually decreased by 25% because Lambda's pay-per-execution model was far more efficient than over-provisioning a single server. This freed up my time to build new features, not just maintain the old ones. You can learn more about my approach to scaling my SaaS applications.

Trust Revamp's Feature Freeze

• Setup: Trust Revamp helps businesses collect and display customer reviews across various platforms. Early on, I built a custom ORM (Object-Relational Mapper) in PHP because I thought it would give me more control.
• Challenge: Adding new review platforms (like Google, Yelp, Facebook) or implementing complex filtering options became a major headache. Each new integration required deep changes to my custom ORM, often breaking existing integrations. A new platform integration that should have taken 1 week consistently took 3-4 weeks. This meant new features were delayed by months. My competitors were shipping new integrations and features much faster. I estimated a loss of 2-3 potential new clients per month because Trust Revamp lacked support for a specific review platform they needed.
• Failure: I kept trying to extend my custom ORM with more and more custom logic for each new integration. This just made the codebase more brittle and complex. A bug fix for one review platform's API integration once inadvertently broke another platform's integration for 4 hours, causing customer support to light up. I spent 2 full days just trying to untangle the spaghetti of conditional logic.
• Action: I made a tough decision: replace the custom ORM entirely. I refactored the data layer to use Laravel Eloquent, a battle-tested and well-maintained ORM. This was a 4-week project, but it was planned and executed with dedicated effort. I also introduced a proper service layer to abstract the external API integrations, making them independent of the core data logic. This was part of my broader strategy for building Shopify apps with Laravel.
• Result: The change was transformative. New integrations now take 3-5 days to implement, a 75% reduction in development time. Feature delivery improved by 60%. In the next quarter, I was able to ship 4 major new features and integrate with 3 new review platforms. This directly contributed to a 20% growth in Monthly Recurring Revenue (MRR) due to increased customer satisfaction and market reach.

Pitfalls I've Stumbled Into (So You Don't Have To)

I've been building software for over 8 years, from WordPress plugins like Custom Role Creator to complex SaaS platforms. I've made every mistake in the book regarding technical debt. Here's what I learned, so you can avoid my pain. The unexpected insight here is that the "always refactor" mantra, while sounding good, can be a major trap. Sometimes, good enough is good enough.

1. Ignoring It Completely

• Mistake: "We'll fix it later." This is the most common and dangerous mistake. Debt compounds. What's a small patch today becomes a major rewrite tomorrow. I did this with an early version of Paycheck Mate's reporting module. I knew it was clunky, but I kept pushing new features. Eventually, adding any new report took days, not hours.
• Fix: Allocate 15-20% of your sprint capacity specifically for technical debt, starting now. Make it a visible, prioritized backlog item.

2. Over-Engineering Solutions

• Mistake: Building perfect, scalable architecture for a problem that might not even exist yet. You spend weeks on an elaborate microservices architecture when a simple monolithic API would have shipped the feature in days. This is "pre-debt," debt you incur before you even have a validated product. I've been guilty of this when starting new projects, trying to make everything "future-proof."
• Fix: Prioritize the simplest solution that solves the immediate business problem. You can refactor or re-architect after you validate the need.

3. Treating All Debt Equally

• Mistake: Refactoring a minor UI bug that affects 0.1% of users with the same priority as a critical performance bottleneck that impacts 80% of your user base. Not all debt carries the same weight.
• Fix: Rank technical debt by its direct impact on users, revenue, security, or developer productivity. Focus on high-impact debt first.

4. "Just Write Good Code From the Start" (The Smart Trap)

• Mistake: This sounds like great advice. In theory, if you always wrote perfect, clean, testable code, you'd have no debt. But in the real world, especially when you're a founder-developer like me, you're balancing speed, resources, and quality. Shipping a product like my Custom Role Creator plugin means making trade-offs. Striving for perfection from day one often means you never ship at all.
• Fix: Embrace strategic debt early for speed to market. Get your product out, validate it, and then deliberately plan to pay down that debt as the product matures. This is a crucial lesson for founder-developer insights.

5. Lack of Communication with Stakeholders

• Mistake: Engineers see the messy code and understand the problem. Business stakeholders just see delays and don't understand why. This leads to frustration on both sides and debt never getting prioritized.
• Fix: Translate technical debt into business impact. Explain how fixing an old module will reduce server costs by $X, or enable new features to ship 50% faster, or prevent customer churn.

6. Not Automating Prevention

• Mistake: Relying solely on manual code reviews or developer vigilance to catch new debt. Humans make mistakes and get tired.
• Fix: Implement linters (like ESLint for JavaScript, PHP_CodeSniffer for PHP), static analysis tools, and mandatory unit/integration tests in your CI/CD pipeline. Catch issues before they even reach a reviewer. This is a core part of my CI/CD pipeline for rapid development.

My Go-To Tools for Technical Debt Management

You don't need a huge budget to start managing technical debt effectively. The best tools are often the ones you already use or simple, accessible options. The unexpected insight here is that the best tool isn't always the most expensive or complex one; sometimes it's a simple shared spreadsheet that fosters transparency.

Here are some tools I've used across my projects:

Tool Category	Example Tools	Best For	Why I Use It
Project Management	Jira, Asana, Trello	Task tracking, prioritization	Keeping debt visible and prioritized like any other feature. I used Jira for Flow Recorder's larger refactors.
Code Quality Analysis	SonarQube, Code Climate	Static analysis, code smells, complexity	Catching issues (duplicate code, high complexity) before they merge, enforcing coding standards.
Performance Monitoring	New Relic, Datadog, AWS CloudWatch	Runtime issues, bottlenecks, error rates	Pinpointing performance bottlenecks and errors in live systems like Store Warden. Essential for reactive debt management.
Linters & Formatters	ESLint, PHP_CodeSniffer, Prettier	Code style, syntax issues, basic errors	Catching syntax and style issues automatically during development and in CI. Reduces review burden.
Security Scanning	Snyk, Dependabot, OWASP ZAP	Vulnerability detection in code & dependencies	Identifying and fixing known security flaws in both my code and third-party libraries. Crucial for any public-facing app.
Documentation	Confluence, Notion, Google Docs	Knowledge sharing, architecture decisions	Documenting why certain technical debt exists or why a specific architectural decision was made. Prevents future teams from repeating mistakes.

Underrated Tool: A Simple "Tech Debt Backlog" Spreadsheet. When I was starting out with my WordPress plugin, Custom Role Creator, I didn't have fancy tools. I used a simple Google Sheet. It was just a list of "things I need to fix someday" with a priority (High, Medium, Low), estimated effort, and a link to the relevant code. This kept my technical debt from being invisible. It was low-tech, but highly effective for prioritizing and tracking. It proves you don't need to overcomplicate things.

Overrated Tool: Complex, AI-powered "tech debt calculators." You'll see tools that promise to give you a single, magic "technical debt score." I tried one for an early version of Store Warden. It analyzed the codebase and gave me a number. The problem? That number often didn't align with actual business impact. A module with "high debt" according to the AI might be rarely used, while a "medium debt" module was causing critical customer churn. These tools often oversimplify complex issues. I prefer clear, actionable metrics directly tied to business value, not an abstract score.

The Strategic Imperative of Technical Debt Management

Many developers, including my younger self, think of technical debt as purely a coding problem. My 8+ years of experience, and especially my work as an AWS Certified Solutions Architect building and scaling systems globally from Dhaka, has taught me that it's often a people and process problem first. The "bad code" is frequently a symptom, not the root cause. This was a surprising finding for me, contradicting the common developer advice of "just write clean code." You can write the cleanest code in the world, but if the business keeps changing requirements weekly without a proper feedback loop, you'll accumulate debt regardless.

Technical debt isn't just about messy code; it's about the bottom line. Ignoring it has real, measurable costs.

Here's a look at the stark contrast:

Aspect	Proactive Technical Debt Management	Ignoring Technical Debt
Development Speed	Faster feature delivery (e.g., shipping features 20% faster)	Slower, constant firefighting (e.g., new features take twice as long)
Code Quality	Higher quality, fewer bugs (e.g., 30% reduction in critical bugs)	Brittle, bug-ridden code (e.g., 2-3 new bugs introduced with every major release)
Scalability	Architecture evolves with growth (e.g., Flow Recorder handled 10x users)	Systems buckle under load (e.g., Flow Recorder struggled beyond 5,000 users, leading to 15% user engagement drop)
Developer Morale	Engaged, productive team (e.g., happier developers, lower churn)	Frustrated, high churn (e.g., developers leave because they're constantly fixing old messes)
Business Agility	Quick adaptation to market changes (e.g., Trust Revamp shipped 4 new features in one quarter)	Stagnation, missed opportunities (e.g., competitors outpace you due to slow delivery, losing 2-3 clients per month)
Cost	Strategic investment, lower long-term costs (e.g., 25% lower server costs for Flow Recorder)	Hidden costs, expensive fixes (e.g., higher server bills, increased support burden, lost revenue from customer churn)

A study by McKinsey in 2021, "The next frontier in digital innovation: Tackling technical debt," highlighted this clearly. They found that companies that actively manage technical debt see a significant increase in developer productivity and a reduction in time-to-market for new features. Specifically, they reported a 10% increase in developer productivity and a 20% reduction in time-to-market for new features for companies effectively tackling their debt. That's not just a technical win; it's a massive business advantage.

Effective technical debt management isn't about writing perfect code from day one. It's about making deliberate choices, understanding the trade-offs, and having a plan to address the consequences. It’s about building sustainable products that can adapt and grow. If you treat it as a strategic concern, you'll build better software and a more successful business. Learn more about my product development philosophy at besofty.com.

From Knowing to Doing: Where Most Teams Get Stuck

You now understand what technical debt management involves. You know the frameworks, the metrics, and the tools. But knowing isn't enough — execution is where most teams fail. I’ve seen it repeatedly in Dhaka and with remote teams globally. We talk about the problem, we identify the solutions, but then we just... don't do it.

The manual way works for a bit. You might manually review code, or manually track issues. But it's slow, it's error-prone, and it absolutely does not scale. When I was building out Flow Recorder, a tool for capturing user flows, I saw this firsthand. We started with manual checks for code quality. Every new feature introduction felt like a game of whack-a-mole with new bugs and performance regressions.

The real shift happens when you bake debt management into your daily workflow, making it impossible to ignore. It’s not about finding a magic bullet. It's about setting up guardrails that gently nudge you towards better practices. My unexpected insight here is that the most effective technical debt strategy isn't a grand refactor; it's a relentless, automated trickle of small improvements. It’s the constant, small pressure from a CI/CD pipeline flagging a linter error that prevents a mountain of debt later. That's how you move from just knowing to actually doing.

Want More Lessons Like This?

I share practical lessons from my 8 years of building scalable applications and managing complex systems, from Shopify apps like Store Warden to custom SaaS platforms. If you're a developer looking for real-world strategies that cut through the noise, join my journey.

Subscribe to the Newsletter - join other developers building products.

Frequently Asked Questions

How does technical debt management fit into an agile workflow?

Technical debt management doesn't sit outside your agile sprints; you integrate it directly. I always advocate for dedicating a small, consistent percentage of each sprint – say, 10-15% – to addressing existing debt or preventing new debt. This isn't just for bug fixes. It's for refactoring, updating dependencies, or improving test coverage. For example, during a sprint for Trust Revamp, we'd allocate time for improving database query performance on older modules, treating it like any other feature story. It ensures you chip away at debt without derailing new feature development.

I'm a solo developer / small team. Is technical debt management really worth my time?

Absolutely, it's even more critical for you. As a solo developer or a small team, your time and resources are finite. Technical debt, left unchecked, will slow you down exponentially. It will make every new feature harder to build and every bug fix take longer. Consider the time spent debugging a poorly structured module versus the small upfront investment in automated linters or a clear coding standard. I learned this building Paycheck Mate on my own; neglecting small issues early on meant slower progress later. Proactive debt management is a force multiplier for small teams.

How long does it typically take to see results from technical debt management efforts?

You can see initial results quickly, often within weeks, but significant impact takes months. For example, implementing a new linter rule in your CI pipeline will immediately flag new violations, preventing future debt. You'll see cleaner code in new commits right away. However, tackling a large backlog of existing debt or improving overall system architecture will show major benefits in deployment speed or reduced bug reports over 3-6 months. The key is consistency; continuous effort over time yields the most substantial, lasting improvements.

What's the absolute first step I should take to start managing technical debt today?

Start small and automate. Don't try to fix everything. My advice: identify one small, nagging piece of technical debt that causes recurring pain. Maybe it's inconsistent code formatting, or a missing docstring standard. Then, find an automated tool that detects this specific issue. Integrate it into your pre-commit hooks or your CI/CD pipeline. For instance, I'd add Prettier and ESLint to a project if they weren't there, and make their output block a commit. This immediately prevents new debt of that type and gives you a clear path to fix existing instances.

What's the biggest mistake teams make when tackling technical debt?

The biggest mistake is attempting a "big bang" refactor or trying to fix all technical debt at once. This approach often leads to massive projects that stall, get deprioritized, or introduce new bugs due to the sheer scope of changes. Instead, I advocate for an incremental approach. Just like I approach building features for Shopify apps, you break down the problem into small, manageable chunks. Prioritize based on impact and frequency of pain. Fix the most impactful, frequently touched areas first. This way, you deliver value continuously and avoid overwhelming the team.

When should I prioritize fixing technical debt over building new features?

You should prioritize fixing technical debt when it directly impacts your team's ability to deliver new features efficiently, reliably, or securely. For instance, if a specific module's complexity is causing frequent bugs, delaying new features, or making deployments risky, then addressing that debt becomes a higher priority. It's a balance. If the technical debt is a minor inconvenience, you might defer it. But if it's a bottleneck for your team's velocity or introduces significant risk, like a security vulnerability in a core dependency, you address it immediately. As an AWS Certified Solutions Architect, I know the cost of ignoring critical infrastructure debt.

The Bottom Line

You've moved from being reactive to proactive, understanding that technical debt isn't a problem to ignore, but a strategic asset to manage. The single most important thing you can do today is pick one manual, repetitive task in your development workflow and write a script to automate it, or add one new, impactful linter rule to your project. This small action will immediately prevent new debt and give you momentum. If you want to see what else I'm building, you can find all my projects at besofty.com. Start small, stay consistent, and you'll stop dreading code changes. You'll ship faster, with less stress, and build more robust products.

---

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