DEV Community: Pritesh Kiri

Understanding System Reliability: The Foundation of Modern Infrastructure

Pritesh Kiri — Tue, 23 Dec 2025 01:15:36 +0000

Imagine waking up to discover that your company's main application is down. Customer calls are flooding in. Revenue is bleeding away at $100,000 per hour. Your team is scrambling, but you don't know where to start.

This isn't a nightmare scenario, it's reality for 98% of organizations at some point. The question isn't if systems will face stress, but how they'll respond when they do. That's reliability.

What is Reliability?

Reliability isn't just about keeping systems online. It's fundamentally about how your applications and services deal with stress and disruptions gracefully.

Think of reliability as a promise, a promise that your system will perform its intended function correctly and consistently when users need it. It's not about individual components never failing. In fact, in complex distributed systems, component failures are inevitable. What matters is how the system responds.

According to AWS's Well-Architected Framework, reliable systems share a critical characteristic: they're designed to recover from failure quickly rather than preventing every possible failure.

A System-Wide Property

Reliability is a property of your entire system, not just isolated parts. Your application might have rock-solid code, but if your database crashes and there's no failover, your system isn't reliable. This holistic view is essential site reliability engineering (SRE) practices emphasize that reliability must be considered across all layers of your infrastructure.

The Three Pillars of Reliability

Reliability rests on three fundamental pillars:

1. Availability

Availability represents the fraction of time your service is usable and accessible. When we say a system has 99.9% uptime, we're talking about less than 9 hours of downtime per year. The difference between 99.9% (three nines) and 99.99% (four nines) might seem small, but it translates to roughly 52 minutes versus 5 minutes of acceptable downtime annually, a tenfold difference.

Organizations often establish Service Level Agreements (SLAs) that codify availability expectations, creating accountability between service providers and users.

2. Latency

Latency measures how long it takes for your system to respond to requests. Here's the critical insight: users don't just care about average response times. A system that responds in 50 milliseconds on average but makes 5% of users wait 1,000 milliseconds has a serious reliability problem.

This is why percentile-based latency metrics (p50, p95, p99) are more meaningful than averages. Google's research shows that tail latency, the slowest requests, often indicate systemic issues that impact user experience disproportionately.

3. Performance

Performance encompasses your system's ability to handle load efficiently. This includes throughput, resource utilization, and how gracefully your system degrades under stress. A reliable system doesn't just work under normal conditions, it has predictable behavior even when pushed to its limits.

Performance engineering helps identify bottlenecks before they become critical failures, ensuring systems can scale to meet demand.

Why Reliability Matters: The Business Case

The business impact of poor reliability is staggering. Research shows that in 2017, 98% of organizations reported that a single hour of downtime would cost over $100,000. For larger enterprises and critical services, costs can reach millions per hour.

But the impact extends beyond immediate financial losses. Every outage breaks customer trust, and in today's competitive landscape, users have alternatives a click away. Studies show that 88% of online consumers are less likely to return to a site after a bad experience.

The Paradox: Embracing Failure to Achieve Reliability

Here's the thing: achieving high reliability doesn't mean preventing every failure, that's impossible and economically unviable. Instead, it means building systems that fail gracefully, recover quickly, and maintain acceptable service levels even when components fail.

Companies like Netflix and Google have embraced this philosophy. They deliberately inject failures into production systems through chaos engineering to ensure their systems can handle real-world disruptions. Netflix's famous Chaos Monkey randomly terminates instances in production to verify that services can tolerate instance failures.

They've learned that experience with failure is a prerequisite for creating reliable systems. As the Principles of Chaos Engineering state: "Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system's capability to withstand turbulent conditions in production."

Building for Reality, Not Perfection

Modern reliability practices recognize several key truths:

Failure is normal: In distributed systems with thousands of components, something is always broken. The question is whether your system can continue functioning despite individual failures.

Redundancy matters: Multiple layers of redundancy—from application instances to data centers to geographic regions—ensure that single points of failure don't cascade into total outages.

Observability is essential: You can't improve what you can't measure. Comprehensive monitoring, logging, and tracing enable teams to understand system behavior and respond quickly to issues.

Automation accelerates recovery: Automated remediation and self-healing systems reduce mean time to recovery (MTTR) from hours to minutes or seconds.

The Path Forward

Reliability isn't a feature you add at the end—it's a fundamental property you architect from the beginning. Organizations that treat reliability as an afterthought inevitably face costly outages and erosion of customer trust.

The journey to highly reliable systems requires:

Clear service level objectives (SLOs) that balance reliability with development velocity
Failure mode analysis to understand potential breaking points
Regular chaos experiments to validate assumptions about system behavior
A culture that treats incidents as learning opportunities rather than blame opportunities

In our next video, we'll explore resilience: the system's ability to withstand and recover from those inevitable failures. Because in distributed systems, it's not about if things will break, it's about when, and how prepared you are to handle it.

Ready to start your chaos engineering journey? Explore LitmusChaos to begin testing your system's reliability today.

Making Chaos Conversational: A Beginner-Friendly Guide to the LitmusChaos MCP Server

Pritesh Kiri — Thu, 20 Nov 2025 19:04:06 +0000

Modern software systems are becoming more distributed, more complex, and more dependent on reliability than ever before. But reliability isn’t something you bolt on at the end, it’s something you test deliberately. That’s exactly where chaos engineering comes in: by intentionally injecting controlled failures, teams can understand how their systems behave under stress and make them more resilient.

LitmusChaos has been one of the most widely adopted open-source frameworks for cloud-native chaos engineering. But even with its intuitive UI (ChaosCenter), CRDs, and CLI, we know that YAMLs and APIs can still feel intimidating, especially for teams just starting out.

So, how do we make chaos engineering easier, faster, and more accessible?

This is where the LitmusChaos MCP Server comes in.

What Is MCP and Why Does It Matter?

MCP (Model Context Protocol) is a new standard that allows AI assistants (like Claude or other LLM-powered tools) to communicate with external systems through structured, well-defined tools.

Think of MCP as a bridge that lets your AI assistant:
• List chaos experiments
• Run experiments
• Stop them
• Check statuses
• Explore infrastructures
• Build probes

Using just simple natural language.

So instead of writing YAML or navigating multiple UI screens, you can simply ask:

“Run a pod-delete experiment in my staging environment.”

And the MCP Server will take care of it.

Why Did LitmusChaos Build an MCP Server?

Chaos engineering is powerful, but sometimes feels “too technical” or “too risky” for new practitioners. The LitmusChaos MCP Server solves this problem by:

Lowering the barrier to chaos. Anyone on your team can run chaos with natural language — no CRDs required.
Improving speed and accessibility. Fast discovery, instant experiment triggers, quick monitoring — all via an AI assistant.
Integrating chaos into existing workflows. Teams already using AI agents can now tie chaos steps directly into operational workflows.
Enforcing safe, scoped access. MCP tools only expose specific, controlled actions. Tokens and namespaces ensure safe execution.
Making chaos collaborative. Experiment reviews, run summaries, and probe outputs become conversational and easy to share.

Ultimately, this brings chaos engineering closer to everyday development and reliability workflows.

Check out our LitmusChaos MCP Server YouTube Playlist for a detailed guide.

Setting Up the LitmusChaos MCP Server

Below is a simple guide to getting the MCP Server running on your cloud desktop or local system.

Prerequisites

You will need:
• Go 1.21 or newer
• Access to an existing LitmusChaos ChaosCenter
• A valid project and API token
• Any MCP-enabled AI client (e.g., Claude Desktop)

Clone the repository

git clone https://github.com/litmuschaos/litmus-mcp-server.git
cd litmus-mcp-server

Build the binary

make build

Getting Your Credentials

Chaos Center Endpoint: URL of your LitmusChaos installation
Project ID: Found in Chaos Center project settings
Access Token: Generate from Chaos Center → Settings → Access Tokens

Connecting it with your MCP Client (Using Claude here)

{
  "mcpServers": {
    "litmuschaos": {
      "command": "/path/to/litmuschaos-mcp-server",
      "env": {
        "CHAOS_CENTER_ENDPOINT": "http://localhost:8080",
        "LITMUS_PROJECT_ID": "your-project-id",
        "LITMUS_ACCESS_TOKEN": "your-token"
      }
    }
  }
}

Available Tools

The server provides 17 comprehensive tools for chaos engineering operations:

Experiment Management

list_chaos_experiments - List all chaos experiments with filtering
get_chaos_experiment - Get detailed experiment information
run_chaos_experiment - Execute experiments immediately
stop_chaos_experiment - Stop running experiments

Execution Monitoring

list_experiment_runs - List experiment execution history
get_experiment_run_details - Get detailed run information with logs

Infrastructure Management

list_chaos_infrastructures - List all registered infrastructures
get_infrastructure_details - Get detailed infrastructure information
register_chaos_infrastructure - Register new Kubernetes infrastructures

Environment Organization

list_environments - List all environments
create_environment - Create new environments for the organization

Resilience Validation

list_resilience_probes - List all configured resilience probes
create_resilience_probe - Create HTTP, CMD, K8s, or Prometheus probes

Discovery & Analytics

list_chaos_hubs - List available ChaosHubs
get_chaos_faults - Browse available chaos faults
get_experiment_statistics - Get comprehensive platform statistics

Examples

These are real-world prompts you can use once your MCP server is connected:

List all experiments

Show me all chaos experiments available in my staging environment.

Trigger an experiment

Run the pod-delete-basic experiment and share the run ID.

Check experiment status

Show me the timeline and probe results of run <RUN_ID>.

Stop running chaos

Stop the currently running pod delete experiment.

Explore ChaosHub

List all Kubernetes pod-level faults from the ChaosHub.

Build a probe

Create an HTTP probe that checks /health returns 200 within 2 seconds.

Add a new environment

Create a new environment called chaos-lab.

Why use MCP?

As systems become more distributed and reliability becomes more critical, we need chaos engineering tools that integrate into everyday workflows.

The LitmusChaos MCP Server delivers:

Ease of use → chaos through natural language
Faster adoption → no need to learn CRDs or YAML
Better collaboration → experiments become team-friendly

The LitmusChaos MCP Server is more than just a technical integration, it’s a new way of practicing chaos engineering. Making chaos accessible through natural language removes barriers and encourages teams to adopt reliability as a mindset, not a one-time activity.

LitmusChaos October Highlights - Hacktoberfest, Meetups & More!

Pritesh Kiri — Wed, 05 Nov 2025 04:14:40 +0000

October has been one of the most exciting and eventful months for the LitmusChaos community. With Hacktoberfest 2025 in full swing, we went all in, from hosting community-driven events to supporting contributors, shipping releases, and celebrating amazing open-source contributions.

Hacktoberfest 2025 (The Month of Open Source)

Hacktoberfest has always been special for LitmusChaos, and this year, we made it even bigger. The community came together to contribute to LitmusChaos and Litmus Docs, improving the project’s security, user experience, and accessibility with Litmus 4.0.

Here’s what we achieved together in October:

GitHub Stars: 112 new stars
LitmusChaos Issues: 42 created → 27 closed (PRs merged), 15 in progress
Litmus Docs Issues: 34 created → 31 closed (PRs merged), 3 in progress
New Contributors
- 23 new contributors to LitmusChaos
- 18 new contributors to Litmus Docs

These numbers reflect the incredible passion our contributors showed throughout Hacktoberfest. A big shoutout to everyone who helped strengthen LitmusChaos through code, docs, and discussions!

Release Spotlight: LitmusChaos MCP Server

One of the biggest highlights of October was the release of the LitmusChaos MCP (Model Context Protocol) Server, a major step toward making Chaos Engineering more accessible and intelligent.

The Litmus MCP Server allows users to interact with chaos experiments using natural language, bridging the gap between developers and automation. Imagine simply asking, “Run a pod-delete experiment on the checkout service,” and seeing it happen seamlessly — that’s the power MCP brings to the Litmus ecosystem.

Adoption Continues to Grow

LitmusChaos continues to see strong adoption within the cloud-native ecosystem.

October Installation Trends:

Mid-month spike: around 5.2K installations (Oct 6–7)
End-of-month range: roughly 3.8K–4K installations
Average daily installations: around 3.5K–4K

It’s heartening to see teams worldwide continue to adopt ChaosCenter to build more resilient systems.

New Blog of the Month

We published a new blog this month:

Pritesh Kiri for LitmusChaos

Oct 28 '25

Making Chaos Engineering Accessible: Introducing the LitmusChaos MCP Server

#mcp #chaosengineering #litmus #litmuschaos

Comments

3 min read

The post dives into how the Model Context Protocol (MCP) is bringing natural language interfaces to chaos engineering, making it easier than ever to design and execute experiments using LitmusChaos.

Growing Our Content & Community Reach

We’ve been consistent in sharing knowledge, updates, and community stories across our platforms.

YouTube

13 new videos published:

Community & Contributor Calls
Getting Started with Litmus” — a 10-part video series
16 new subscribers joined our channel

Twitter

+12 new followers and some great engagement on Hacktoberfest updates

+51 new followers — welcome to all the new faces joining the chaos community!

Slack

42 new members joined our community Slack Community

October Offline Meetups

We hosted two exciting in-person meetups in October to celebrate Hacktoberfest and connect with our amazing contributors!

📍 LitmusChaos x Hacktoberfest Meetup — Bangalore (Oct 4)

We kicked off October with a bang at the Harness Bangalore office, where 130+ attendees joined us to celebrate open source and learn about chaos engineering.

📍 Hacktoberfest Hyderabad Meetup — in Collaboration with DigitalOcean (Oct 11)

Next up, we partnered with DigitalOcean for the Hyderabad Hacktoberfest meetup, proudly sponsored by Harness.

Community & Contributor Calls

Our monthly calls were buzzing with energy and participation!

Community Call

Topics we discussed:

Release of Litmus v3.22.0
Active Hacktoberfest activities and contributions
Introduction to Litmus MCP

Contributor Call

Highlights included:

Recap of community contributions during Hacktoberfest
Open PRs discussion and shoutouts to active contributors
Contributor best practices and guidelines

These calls continue to be a great space for collaboration, feedback, and celebrating progress together.

Wrapping Up

October was nothing short of amazing — full of learning, contribution, and connection.
From new contributors joining the fold to community-driven meetups and continuous adoption growth, LitmusChaos continues to thrive, powered by its community ❤️

As we move into November, we’re excited to keep the momentum going. More releases, new experiments, and continued community engagement await!

🔗 Join the conversation on Slack and follow us on LinkedIn, YouTube, and Twitter for the latest updates.

Making Chaos Engineering Accessible: Introducing the LitmusChaos MCP Server

Pritesh Kiri — Tue, 28 Oct 2025 03:56:16 +0000

Chaos Engineering has always been about one thing: building resilient systems. But let’s be honest, while the idea sounds great, getting started with chaos experiments has never been easy.

YAMLs, CLI commands, complex setups, and a fear of “what if I break something?” often stop developers and SREs before they even begin. Even with tools like LitmusChaos, which simplify a lot of this, there’s still a learning curve, especially for those new to resilience testing.

That’s exactly what the LitmusChaos MCP Server aims to change.

The Challenge with Chaos Engineering

Chaos Engineering helps you intentionally inject failures into your systems to test how they respond.

But here’s the catch for many teams: it feels too technical, too complex, or too risky.

You need to understand multiple CRDs and YAML definitions.
You have to set up and manage chaos infrastructures.
You have to know how to interpret experimental results.

And if you’re a developer or DevOps engineer already juggling deployments, observability, and CI/CD, adding “run chaos experiments” to that list can feel overwhelming.

Where LitmusChaos Fits In

LitmusChaos was built to solve exactly that. To make Chaos Engineering simpler, more organized, and more collaborative.
With ChaosCenter, you get a single pane of glass to:

Run and manage chaos experiments.
Track resilience scores.
Monitor chaos infrastructures (agents).
Visualize experiment runs and results.

It has helped teams integrate chaos into their CI/CD pipelines and production workflows.

But… even with all these features, there’s still one big barrier left: You still need to know how to use it.

Now imagine if you could talk to your system and say:

“Run a pod-delete experiment on the payment service in production.”

And it just does it.

That’s exactly what LitmusChaos MCP Server enables. It turns Chaos Engineering into a conversational experience.

No YAMLs. No CLI. No UI clicks.

Just natural language.

LitmusChaos MCP Server

The LitmusChaos MCP Server is a Go-based Model Context Protocol (MCP) server that connects your AI assistant (like Claude) directly to your ChaosCenter.
It provides a complete interface to:

Manage experiments
Control infrastructures
Organize environments
Run and monitor resilience probes

All through natural language interactions.

In simple words, the MCP Server acts as a bridge between your AI assistant and your Chaos Engineering setup, letting anyone perform chaos operations just by asking.

What You Can Do With It?

Here are some examples of what the MCP Server can handle through natural language:

1. Experiment Management

“List all chaos experiments.”
“Run the pod-delete experiment on the frontend pods.”
“Stop the network latency experiment.”
You can trigger, stop, or describe chaos experiments instantly.

2. Infrastructure Operations

“List all active chaos infrastructures.”
“Show me the status of the production infra.”
You get a complete overview of all connected Litmus agents.

3. Environment Organization

“Create a new environment called staging.”
“Show me all experiments in the PROD environment.”
Organize chaos operations by environments for better structure.

4. Resilience Probes

“Create an HTTP probe that checks the payment API every 5 seconds.”
“List all existing probes in my project.”
You can validate steady-state conditions or system health with simple requests.

5. Analytics & Monitoring

“Show me all failed experiments last week.”
“What’s the resiliency score of my production environment?”
It makes chaos data easy to access and interpret.

Getting Started with MCP Server

You can get up and running in just a few minutes.
Quick setup

# Clone and build
git clone https://github.com/litmuschaos/litmus-mcp-server.git
cd litmus-mcp-server
make build

Now, just add it to your Claude or any other MCP Host, and you’re ready to talk to your ChaosCenter through natural language.

Follow this guide to learn more about setting up the Litmus MCP server.

Why It Matters

The MCP Server is more than just a new integration; it’s a mindset shift for chaos engineering.

For Developers: No more YAML confusion. Learn chaos the easy way.
For SREs: Run, monitor, and analyze chaos experiments faster.
For DevOps Teams: Automate resilience testing with AI-driven workflows.
For Organizations: Empower every engineer, not just chaos experts, to build resilient systems.

It lowers the barrier of entry so that anyone, regardless of chaos experience, can perform meaningful resilience testing.

The Future of Accessible Chaos Engineering

The LitmusChaos MCP Server marks a big step forward, where Chaos Engineering meets AI-driven accessibility.

It makes resilience testing approachable, interactive, and intuitive.
The future of chaos isn’t about running YAML files; it’s about asking the right questions, getting answers, and improving system resilience effortlessly.

So go ahead, try it out, connect your assistant, and let’s make Chaos Engineering something everyone can do.

LitmusChaos Community Highlights - September 2025 Recap

Pritesh Kiri — Thu, 23 Oct 2025 11:00:52 +0000

September was an exciting month for the LitmusChaos community!

From insightful discussions in our calls to strong GitHub activity and growing engagement on social platforms, the community continued to thrive as we geared up for Litmus 4.0 and Hacktoberfest. Here’s a look at what happened in September.

GitHub updates

The community remained active on GitHub throughout September:

Stars gained: 35 ⭐
Issues: 9 total (6 open, 3 closed)
Pull Requests: 7 total (4 open, 3 merged)

The activity shows steady engagement from contributors and continued momentum in maintaining and improving LitmusChaos.

Litmus Installations

Here is the graph showing our installation chart for September:

Mid-month spike: Around 1.2K installations
End-of-month jump: Roughly 3.6K installations on Sep 30
Average daily installations: ~300–350

This surge indicates growing interest in LitmusChaos as more users start experimenting and running chaos experiments.

New Videos & Resources

We released 4 new videos in September to help the community stay informed and get started with LitmusChaos:

1) “New Look of Litmus” – a fresh tour of Litmus features

2) Community Call – discussions on releases and upcoming events

3) “Learn Litmus in 20 Minutes” – a quick-start tutorial

4) Contributors Call – recap and guidance for contributors

Community and Contributor Calls Recap

Community Call Highlights

Litmus v3.21.0 release updates
Upcoming events: Hacktoberfest & meetups
GitHub activities & contributions
Sneak peek into Litmus 4.0 and Litmus MCP

Watch the full video here

Contributors Call Highlights

Recap of community contributions so far
Review of open PRs and recent contributions
Best practices for contributing
Hacktoberfest introduction and contribution planning
How to start contributing to LitmusChaos and follow the contributor guidelines

Watch the full video here

Social & Community Growth

September also saw engagement across our social platforms:

LinkedIn: 20+ new followers
Slack: 15+ new members
Twitter: 5+ new followers

We shared the new videos and key discussions across these channels, encouraging more people to join the community and participate in LitmusChaos.

Join the Litmus Community

If you’re passionate about open source and want to help improve developer experience, we’d love to have you!
Here’s how you can get involved:

Star the LitmusChaos GitHub repo — it really helps!
Join our Slack community to chat, ask questions, or collaborate.
Subscribe to our YouTube channel for tutorials, community calls, and updates. Recently released the "Getting Started with LitmusChaos" Playlist.

What’s next?

October is shaping up to be another exciting month:

Hacktoberfest is around the corner. Get ready to contribute!
More updates from Litmus 4.0 and Litmus MCP
Continued growth in community engagement and learning resources

Stay tuned, keep experimenting, and let’s continue building chaos together! ⚡

I improved the Developer Experience of Litmus Documentation

Pritesh Kiri — Wed, 22 Oct 2025 12:05:12 +0000

I recently made my first contribution to the LitmusChaos documentation, and it was all about improving the developer experience.

This was also my first ever contribution after joining Harness as a Community Manager for the LitmusChaos community.

In this blog, I want to share the story behind it, what I worked on, why developer experience matters, and how small changes in docs can make a big difference.

A little about my background

Before joining LitmusChaos, I had the opportunity to work with many developer tools and open source projects.
During that time, I noticed one thing: developers don’t just care about features; they care about how easy it is to use them.

And that’s what we call Developer Experience or DX.

What exactly is Developer Experience?

Developer Experience (DX) is all about how developers feel when they interact with your product from the first line of documentation to the final deployment.

A good developer experience means:

Developers can find what they need quickly.
Docs are clear and easy to follow.
The setup is smooth, and errors are explained well.
It feels effortless to get started and contribute.

Think of it like user experience (UX), but for developers.

When the docs are confusing or poorly structured, it can lead to frustration and wasted time. But when the docs are intuitive, developers become more confident and productive, and that’s how projects grow faster.

What I noticed in the old docs

When I explored the existing documentation, a few things felt a little tricky:

The docs were not very easy to navigate.
The top navigation bar had a version manager, but switching between versions was confusing. And it was a bit cluttered.
The version selector felt disconnected from where users actually manage versions.

And many more things.

What I improved

After exploring the docs and discussing with a few contributors, I decided to focus on improving navigation and structure, so developers could find things faster and with less confusion.

Sidebar redesign

The new sidebar is more readable. You can now see the entire content structure at a glance. It’s easier to find the section you’re looking for.

Before

After

Version manager fix

Moved the version display next to the version manager.
Now, switching versions feels more natural and intuitive.

Top navigation improvements

Rearranged items on the right-hand side for better clarity.
Replaced text-based action items with icons.
Added a Call-To-Action (CTA) button for important actions. i.e., the "Try Litmus" button.

Announcement bar

Finally, I added an announcement bar at the top of the docs.
It provides quick access to our GitHub repository, making it easier for contributors and users to explore, open issues, or star the project ⭐.

Why These Changes Matter

Documentation is often the first place a developer visits when they’re trying out a project.

If that experience is smooth, they’ll likely:

Try the tool,
Recommend it to others, or even
Become long-term contributors.

That’s the real power of good documentation — it doesn’t just explain your project; it helps grow your community.

Join the Litmus Community

If you’re passionate about open source and want to help improve developer experience, we’d love to have you!
Here’s how you can get involved:

Star the LitmusChaos GitHub repo — it really helps!
Join our Slack community to chat, ask questions, or collaborate.
Subscribe to our YouTube channel for tutorials, community calls, and updates. Recently released the "Getting Started with LitmusChaos" Playlist.
Contribute to docs — whether it’s fixing typos, improving content, or adding new pages, every contribution counts.

Wrapping up

This contribution was not just about changing the UI. It was about improving how developers interact with our docs. Even small improvements can make a big difference in usability.

Thanks for sticking with me till the end! I’m excited to continue making Litmus docs even better.

I’ll keep sharing more behind-the-scenes stories about what we’re building in the Litmus community, so stay tuned 🚀

Building an Ed-Tech Sales CRM using ToolJet 📈

Pritesh Kiri — Tue, 11 Jun 2024 12:33:52 +0000

Introduction

An effective Customer Relationship Management (CRM) system can help Ed-tech companies streamline their sales processes, maintain customer information, and enhance customer interactions.

In this tutorial, we will guide you through the process of building an Ed-tech sales CRM using ToolJet and ToolJet Database.

Here is a quick preview of the CRM that we’ll be building in ToolJet.

Prerequisites:

ToolJet (https://github.com/ToolJet/ToolJet): An open-source, low-code business application builder. Sign up for a free ToolJet cloud account or run ToolJet on your local machine using Docker.
Basics of JavaScript: Basic knowledge of JavaScript can be handy for implementing dynamic functionality in your ToolJet applications.

Setting up the ToolJet Database

This section will teach you how to set up the database for our CRM app. We will be using ToolJet Database for this application.

Log in to your ToolJet account and click on the ToolJet Database icon in the left sidebar. We will be creating two tables, one will be for the sales_revenue and other for sales_executives. Let's start by creating the database tables.

Create a new table with the following columns and rename it to sales_revenue:

id (primary key/auto-generated)
course(varchar)
number_of_courses_sold (int)
discount (varchar)
customer_name (int)
customer_email (varchar)
customer_country (varchar)
customer_age_group (int)
revenue (int)
se_name (varchar)
profession (varchar)
sale_date (varchar)

Create a new table with the following columns and rename it to sales_executives:

id (primary key/auto-generated)
name(varchar)
email (varchar)
phone (varchar)

We recommend adding some dummy data to the table so that we have something to work with when we begin the app development process.

UI Development

Once you are done setting up the database, click on the Apps in the sidebar and create a new app with the name Ed-Tech Sales CRM. After the successful creation of the App, you will land on the App-Bulider page.

Now we can drag and drop ToolJet's pre-built components to build the app's UI quickly.

Here is the structure of the app that we will be building:

Header
Tabs
- Overview
- Sales Executives
- Revenue

Let us start will building the Header:

Drag and drop a Container component on the canvas from the components library on the right and rename it to header. Containers are used to group related components in the App-Builder.
Resize it and change its color to #2E425A and border radius to 8.
Inside the Container component, add two Text component for and rename it to brandName and CRMTitle.
In the brandName component change the Data to TOOLJET and change the color to white, font size to 20, font weight to bolder and letter spacing to 6.
In CRMTitle component, change the Data to Ed-Tech Sales CRM and change the color to white, font size to 18.

Renaming components can be useful as the application grows, allowing easy reference to component-related values throughout various parts of the application.

Drag and Drop the Tabs component and change the tab names to Overview, Sales Executives and Revenue.
In Revenue tab, add a Table component which will contain the data from the sales_revenue table in the database.
Now add a Modal component, place it above the table, and rename it to saleDetails. In properties change the title to Sale Details, Trigger button label to Add sale and change the color of button to primary color ( #2E425A ).

Now we need to add input fields in this modal. Here we will be dividing the modal into two parts, first is Customer Details and Revenue Details.
In Customer Details, add Text Input component for Name and Email, Dropdown component for Country, Course and Sales Executive name, Radio button component for the Age group and profession and a Date component for the Sale date.
For the Country dropdown you can add the following data in Option values and labels:

{{ ["Argentina", "Australia", "Brazil", "Canada", "China", "Egypt", "France", "Germany", "Greece", "India", "Indonesia", "Italy", "Japan", "Mexico", "Netherlands", "New Zealand", "Russia", "Saudi Arabia", "South Africa", "South Korea", "Spain", "Switzerland", "Thailand", "United Kingdom", "United States"]
}}

For the Courses dropdown you can add the following data in Option values and labels:

{{ ["Marketing Management", "Data Science Fundamentals", "Financial Accounting", "Introduction to Psychology", "Business Ethics", "Digital Marketing Strategy", "Creative Writing Workshop", "Computer Programming Basics", "Public Speaking Mastery", "Introduction to Economics", "Full Stack Web Development"]
}}

For the Sales Executive dropdown, we will be fetching data from the sales_executives table in the database.
Here is the quick preview of salesDetails modal UI, you can change the design at your convenience.

In salesDetails modal, as you can see we have the dynamic UI elements that will show the values of Revenue without discount and Total revenue generated based on what they choose in Courses sold and Discounts offered. The HEX color codes for both of these Text components are #4A90E2 and #9013FE respectively.
To build these dynamic text elements we need to add on change event handlers on Courses sold and Discounts offered.
We will run a script that will calculate both of these revenues and then will populate those details in the Text components.
Open the Query Manager and add a Javascript query. Name it updateRevenue.
Add the following code to this query. This will return the values that we can use in the Revenue without discount and Total revenue generated in UI respectively. Make sure you rename the number input component to courses and the radio button component to discount.

const revenue = components.courses.value * 2000 * (100 - components.discount.value) * 0.01
const revenueWithoutDiscount = components.courses.value * 2000

return {revenue, revenueWithoutDiscount}

Events in ToolJet are used to run queries, show alerts, and other functionalities based on triggers such as button clicks or query completion.

Update the Data property of the Revenue without discount text component: {{queries.updateRevenue.data.revenueWithoutDiscount ? queries.updateRevenue.data.revenueWithoutDiscount : 0}}
Update the Data property of the Total revenue generated text component: {{queries.updateRevenue.data.revenue ? queries.updateRevenue.data.revenue : 0}}

Once you do these updates, just add on change and on select event handlers in Course sold number input and Discount offered radio button input respectively and add updateRevenue query.
In Sales executive tab also, we will be adding a modal and a table, so drag and drop both of these components in the tab.
Change the modal size to small and height to 300px. Also change the color of trigger button to #2E425A.
Now add three text components for Name, Email and Phone and a submit button in the modal. Change the color of submit button to #2E425A.

In the Overview tab, add three Statistics components. Hide the secondary value and change the primary color to #F28585 for all three components.
Set the primary value labels to Total revenue, Total courses, and Total customers. Keep the primary values as default for now. We will be update it later once we add the data.
Now add seven Chart components from the component library. Set the chart type to pie for five of them and to bar for the remaining two.
Change the background color of all the charts to #F1F4FC. For the two bar charts, set the marker color to #2A77B4.

We have completed building UI, now let's quickly create queries and add functionality to our app.

Data Fetching

With ToolJet, we can easily connect the UI elements to the data sources and fetch data by creating queries in the Query Manager.

We will be adding queries for Revenue, Sales Executive and Overview tabs. We will start with Sales Executive tab, as we will need that data in the modal for adding sales in the revenue tab.

1. Sales Executive Tab

Here, we will need two queries, one will be to add the data to the database and one will be to show the data in the table.

Open the Query Manager at the bottom, click on Add, and then click on the ToolJet database. Rename the query to getSalesExecutives.
Select the table name as sales_executives and operation as List rows. In settings, turn on Run this query on application load? toggle to run this query every time the app reloads.
Once you are done with this, you can click on Preview to check the data.
Let's link this query to the table. Click on table and add {{queries.getSalesExecutives.data}} in the data. You will see your data from the database in the UI.

Now we need to add another query to add the data in sales_executives from the modal component.

Click on Add in the Query Manger and then click on the ToolJet database. Rename the query to addSalesExecutive.
Select the table name as sales_executives and operation as Create row. Then select name, email and phone in the column.
Now we need to add the data from UI to these columns in the keys input. Add {{components.seName.value}}, {{components.seEmail.value}}, {{components.sePhone.value}} in the respective columns in the keys input.
Here seName, seEmail and sePhone are the component names. Make sure you rename them before adding them to the query.
Open the modal and select the submit button. In properties, click on New event handler and add on click event, select action as Run query and select the addSalesExecutive query.
The last thing we need to add is the event handlers in the query. You can add these three events - close modal, success prompt and run getSalesExecutives query.
Try adding the data in the inputs components and submit it. You will see the that data populating in the table.

2. Revenue Tab

In this tab also, we will be needing two queries, one will be to add the data to the database and one will be to show the data in the table.

Open the Query Manager at the bottom, click on Add, and then click on Run Javascript code. Rename the query to getRevenueDetails.
Select the table name as sale_revenue and operation as List rows. In settings, turn on Run this query on application load? toggle to run this query every time the app reloads.
Once you are done with this, you can click on Preview to check the data.
Let's link this query to the table. Click on table and add {{queries.getRevenueDetails.data}} in the data. You will see your data from the database in the UI.

Now we need to add another query to add the data in sale_revenue from the Modal component.

Click on Add in the Query Manger and then click on the ToolJet database. Rename the query to addRevenueDetails.
Select the table name as sale_revenue and operation as Create row.
Add and the columns and then add the data from UI to these columns in the keys input. Add {{components.name.value}}, {{components.email.value}} and all other items from the modal based on names you have added for all the input components.
Open the modal and select the submit button. In properties, click on New event handler and add on click event, select action as Run query and select the addRevenueDetails query.
You can add these three events - close modal, success prompt, and run getRevenueDetails to your query.
Try adding the data in the inputs and submit it. You will see that data populating in the table.

3. Overview Tab

In this tab, we will be calculating all the data to be added in all the Chart and Statistics components using Javascript.

Open on the Query Manger at the bottom, click on Add and then click on Run Javascript code. Rename it to analytics.
You can paste the following code which calculates all the data that you can put inside of all the charts and statistics components.

await queries.getRevenueDetails.run(); 

let data = queries.getRevenueDetails.getData(); 

const totalRevenue = data.reduce((acc, obj) => acc + obj.revenue, 0);
const totalCourseSold = data.reduce((acc, obj) => acc + obj.number_of_courses_sold, 0);
const totalCustomers = Array.from(new Set(data.map(obj => obj.customer_email))).length


const countryCounts = data.reduce((counts, obj) => {
  counts[obj.customer_country] = (counts[obj.customer_country] || 0) + 1;
  return counts;
}, {});

const customerCountryData = Object.keys(countryCounts).map(state => ({ x: state, y: countryCounts[state] }));

const ageRangeCounts = data.reduce((counts, obj) => {
  counts[obj.customer_age_group] = (counts[obj.customer_age_group] || 0) + 1;
  return counts;
}, {});

const ageRangeData = Object.keys(ageRangeCounts).map(state => ({ x: state, y: ageRangeCounts[state] }));

const discountCounts = data.reduce((counts, obj) => {
  counts[obj.discount] = (counts[obj.discount] || 0) + 1;
  return counts;
}, {});

const discountData = Object.keys(discountCounts).map(state => ({ x: state, y: discountCounts[state] }));

const professionCounts = data.reduce((counts, obj) => {
  counts[obj.profession] = (counts[obj.profession] || 0) + 1;
  return counts;
}, {});

const professionData = Object.keys(professionCounts).map(state => ({ x: state, y: professionCounts[state] }));


const courseCounts = data.reduce((counts, obj) => {
  if (obj.course) {
    counts[obj.course] = (counts[obj.course] || 0) + 1;
  }
  return counts;
}, {});


const courseData = Object.keys(courseCounts).map(course => ({ x: course, y: courseCounts[course] }));

const revenueByExecutive = data.reduce((acc, obj) => {
  if (obj.se_name) {
    acc[obj.se_name] = (acc[obj.se_name] || 0) + (obj.revenue || 0);
  }
  return acc;
}, {});


const teamData = Object.keys(revenueByExecutive).map(executive => ({ x: executive, y: revenueByExecutive[executive] }));

// Aggregate revenue by year
const revenueByYear = data.reduce((acc, entry) => {
    const year = parseInt(entry.sale_date.split('/')[2]);
    if (!acc[year]) {
        acc[year] = 0;
    }
    acc[year] += entry.revenue;
    return acc;
}, {});

// Format the data
const yearRevenueData = Object.entries(revenueByYear).map(([year, revenue]) => {
    return {
        y: revenue.toString(),
        x: parseInt(year)
    };
});

// Sort the data by year (y) in increasing order
yearRevenueData.sort((a, b) => a.y - b.y);



return {totalRevenue, totalCourseSold, totalCustomers, courseData, teamData, customerCountryData, ageRangeData, discountData, professionData, yearRevenueData};

You can preview and check the data. Now we will be connecting the query to all the components in this tab.

Select the Total Revenue component and add {{queries.analytics.data.totalRevenue}} in the Primary value.
Select the Total Course component and add {{queries.analytics.data.totalCourseSold}} in the Primary value.
Select the Total Customers component and add {{queries.analytics.data.totalCustomers}} in the Primary value.
Select the Customer location chart component and add {{queries.analytics.data.customerCountryData}} in the chart data.
Select the Courses chart component and add {{queries.analytics.data.courseData}} in the chart data.
Select the Age range chart component and add {{queries.analytics.data.ageRangeData}} in the chart data.
Select the Team revenue chart component and add {{queries.analytics.data.teamData}} in the chart data.
Select the Profession chart component and add {{queries.analytics.data.professionData}} in the chart data.
Select the Discounts chart component and add {{queries.analytics.data.discountData}} in the chart data.
Select the Year Vs Revenue chart component and add {{queries.analytics.data.yearRevenueData}} in the chart data.

Once you are done connecting all queries to your components, turn on Run this query on application load? toggle in the settings, to run this query every time the app reloads.

Conclusion

Congratulations, your Ed-tech sales CRM application is now fully functional! By leveraging Tooljet and the ToolJet Database, you've created a powerful and efficient CRM tailored to the unique needs of the Ed-tech industry. Your application can now effectively manage leads, track sales activities, and analyze performance metrics, all within a user-friendly interface.

We hope this guide has been helpful and inspires you to explore further capabilities and integrations with ToolJet. To continue exploring, check out the official ToolJet docs or connect on Slack for queries and doubt-solving.