diff --git a/src/markdoc/layouts/Category.svelte b/src/markdoc/layouts/Category.svelte
index dcdf9c3611..8ed88a96a7 100644
--- a/src/markdoc/layouts/Category.svelte
+++ b/src/markdoc/layouts/Category.svelte
@@ -1,5 +1,6 @@
 <script lang="ts">
 	import { Article, FooterNav, MainFooter } from '$lib/components';
+	import { page } from '$app/stores';
 	import { Main } from '$lib/layouts';
 	import { getContext } from 'svelte';
 	import type { PostsData, AuthorData } from '$routes/blog/content';
@@ -9,9 +10,10 @@
 	export let name: string;
 	export let description: string;
 
+	const pageSlug = $page.url.pathname.substring($page.url.pathname.lastIndexOf('/') + 1);
 	const authors = getContext<AuthorData[]>('authors');
 	const postsList = getContext<PostsData[]>('posts');
-	const posts = postsList.filter((post) => post.category.includes(name.toLowerCase()));
+	const posts = postsList.filter((post) => post.category.includes(pageSlug));
 
 	const seoTitle = name + BLOG_TITLE_SUFFIX;
 	const ogImage = DEFAULT_HOST + '/images/open-graph/blog.png';
@@ -58,7 +60,7 @@
 				<div class="u-margin-block-start-48">
 					<ul class="aw-grid-articles">
 						{#each posts as post}
-							{@const author = authors.find((a) => a.name.includes(post.author))}
+							{@const author = authors.find((a) => a.slug.includes(post.author))}
 							{#if author}
 								<Article
 									title={post.title}
diff --git a/src/routes/blog/category/case-studies/+page.markdoc b/src/routes/blog/category/case-studies/+page.markdoc
new file mode 100644
index 0000000000..b2463f57ef
--- /dev/null
+++ b/src/routes/blog/category/case-studies/+page.markdoc
@@ -0,0 +1,6 @@
+---
+layout: category
+name: Case Studies
+description: Learn more about the product development and growth journeys of our best customers.
+---
+
diff --git a/src/routes/blog/post/case-study-kcollect/+page.markdoc b/src/routes/blog/post/case-study-kcollect/+page.markdoc
new file mode 100644
index 0000000000..b108c767d6
--- /dev/null
+++ b/src/routes/blog/post/case-study-kcollect/+page.markdoc
@@ -0,0 +1,68 @@
+---
+layout: post
+title: "K-Collect: Building a platform for 50,000 K-Pop fans"
+description: Learn how Appwrite helped K-Collect develop a scalable SaaS platform for K-pop photo card management and grow their audience to over 50,000 consumers while decreasing infrastructure costs by 700%.
+date: 2023-12-02
+cover: /images/blog/kcollect.png
+timeToRead: 5
+author: aditya-oberai
+category: case-studies
+---
+
+In 2019, Ryan O’Connor was a mere university student when he started exploring the world of Korean popular music, or K-pop. One of the areas within the K-pop fan ecosystem that caught his interest was the concept of photo cards. For those new to the K-pop community, K-pop photo cards are artist-specific collectible cards that are possessed and traded similarly to sports or Pokemon trading cards. These photo cards are produced and distributed by K-pop record labels and have developed a substantial interest and following over the last few years. 
+
+As Ryan immersed himself more in this ecosystem, he observed that the K-pop community needed a platform that helped them track, manage, and share their photo cards. Being a developer, Ryan decided to take on this challenge and thus began the journey of his product for K-pop photo card management, [K-Collect](https://kcollect.net/). 
+
+
+# Challenges faced with product development
+
+In 2019, the first iteration of K-Collect, an application that lets you find new artists, organize music collections, track orders, and show off K-Pop photo cards, was developed. However, K-Collect’s choice of technology stack led them to face multiple challenges.
+
+## Knowledge gaps around building mobile apps and backend
+
+Initially, K-Collect built native mobile applications for their product's client-side apps and a Node.js + Express API for the server-side app. The decision to develop mobile apps was made due to the high number of mobile app users in the K-pop ecosystem. However, Ryan happened to be a web developer by skills and trade. His lack of experience with native mobile applications and server-side apps led to several problems, such as:  
+
+  * State management on Android and iOS,  
+  * Cache handling and invalidation in mobile apps,  
+  * Sustaining high concurrency in Node.js APIs,  
+  * Managing database bottlenecks and overloading,  
+  * Backend API security, etc.  
+
+## Cost of managing application infrastructure
+
+Since K-Collect was building a proprietary server-side solution, it had to maintain and manage its infrastructure, featuring servers for its API, storage, and database. The various moving parts of the application led to the necessity of costly infrastructure to sustain even a small mass of consumers. This created a substantial financial burden for the product in the pre-revenue stage.
+
+To decrease these costs and remove the burden of building an efficient and secure backend, K-Collect started exploring Backend-as-a-Service (BaaS) platforms to implement a solution. They tried various options, including established BaaS platforms like Firebase; however, expensive pricing structures and the lack of transparency in the underlying code prevented them from implementing the same.
+
+
+# The power of an entire team
+
+Eventually, to increase K-Collect users' access to desktop-based clients and enable them to leverage their existing skill set, they pivoted to developing a SaaS-like web platform built with Next.js in January 2023. It was at this point that Appwrite was discovered. Adopting Appwrite provided several benefits:
+
+## Abundance of features impacting the product
+
+One of the most important aspects of any BaaS platform is the features and offerings it provides a developer. Appwrite was a boon for K-Collect, as it offered several features for their product. Currently, K-Collect is leveraging Appwrite Authentication to manage identity (and relevant functionalities) for the entire web platform. All information related to K-pop albums, stars, and photo card metadata that K-Collect uses is stored in Appwrite Databases. The photo cards themselves are stored and consumed through Appwrite Storage. K-Collect also implements Appwrite Functions to integrate external 3rd-party services (such as sending emails) and other event-driven tasks related to the other Appwrite offerings being used.
+
+At the moment, Ryan is developing an internal trading platform that will allow users to communicate with each other and buy/sell photo cards. For these features, Ryan will be returning Appwrite Functions for transaction management with a payments gateway and using a combination of Appwrite Databases and Appwrite Realtime for an internal chat platform.
+
+## Improved developer productivity due to easy SDK access
+
+Transitioning to Next.js made the K-Collect codebase consistent with one primary programming language, JavaScript. Since Appwrite offers SDKs for both JavaScript/TypeScript-based web applications and Node.js-based server-side applications with consistent interfaces, Ryan swiftly and smoothly transitioned his application from native mobile apps to a web platform.
+
+Additionally, having to not focus on developing a proprietary backend allowed Ryan to focus on new application functionality (such as the upcoming trading platform), improving the application’s user interface and experience, as well as building a team of 30 contributors who help with research and aggregation of upcoming K-pop music albums to maintain a release calendar.
+
+
+## Decrease infrastructure costs by ~700%
+
+In an internal meeting with the Appwrite team, Ryan shared that initially, with K-Collect’s initial proprietary solution, even after having implemented database replication and sharding with read-only nodes for a more reliable and scalable architecture, K-Collect’s infrastructure was costing them £2000 per month while still running into bottlenecks, which was unsustainable for him as the sole developer. Since switching to Appwrite, including costs for storage, bandwidth (3.5TB of bandwidth served per month and 28 million monthly requests), and web app hosting, K-Collect’s infrastructural costs have decreased to £200-£300, which is approximately a 700% decrease in costs, while being able to triple their load-managing in terms of active users and helping scale total users to over 50,000.
+
+
+# Conclusion
+
+Overall, Appwrite has helped substantially improve software performance for K-Collect while simplifying its application architecture, increasing cost savings, and helping the K-Collect team scale to over 50,000 users from scratch since January 2023. Ryan and K-Collect strongly recommend [Appwrite Cloud](https://cloud.appwrite.io) to other developers and teams looking for a simple-to-implement, robust, cost-effective Backend-as-a-Service solution.  
+
+In Ryan's own words,  
+
+> "The switch to using Appwrite brought infinite value that I'm still discovering today, but a major impact that it made was the amount of time and stress that it saved me as it simply just works. There's no struggling with writing backend code and working with databases, as that's already taken care of."  
+
+Learn more about K-Collect by visiting their [website](https://kcollect.net/), and connect with their founder, Ryan O’Connor, on [Twitter](https://twitter.com/oconrdev) and [GitHub](https://github.com/oconr).
diff --git a/src/routes/blog/post/case-study-smartbee/+page.markdoc b/src/routes/blog/post/case-study-smartbee/+page.markdoc
new file mode 100644
index 0000000000..d774490724
--- /dev/null
+++ b/src/routes/blog/post/case-study-smartbee/+page.markdoc
@@ -0,0 +1,71 @@
+---
+layout: post
+title: "Smartbee: Revolutionizing coal mine monitoring in Colombia"
+description: Learn how Smartbee leveraged Appwrite to build a performant and robust system to monitor and aggregate gas level data in real-time for 7 coal mines in Columbia.
+date: 2023-12-02
+cover: /images/blog/smartbee.png
+timeToRead: 5
+author: aditya-oberai
+category: case-studies
+---
+
+In 2020, Sergio Ponguta and his brother started Smartbee, a company offering security and communications solutions for coal mining operations in Colombia. Both brothers, being formally educated in systems engineering, combined with a lack of fear of traversing down mines, felt comfortable launching this venture. 
+
+They launched their venture by installing security cameras for mines. A requirement of their customers resulted in them setting up a communications system for telephone stations located both outside and inside the mine. As they began growing their offerings, they discovered that the Ministry of Mines and Energy in Colombia made it mandatory for all coal mines to monitor and record gas levels inside. Smartbee took this as an opportunity and started importing gas sensors to provide them to coal mines in Colombia. To add extra value on top of the sensors, they started developing a platform that would aggregate sensor data in real-time and generate reports accordingly. 
+
+
+# Challenges revolving around the development of the platform
+
+As Smartbee started developing its monitoring system, it faced several challenges:
+
+## Mandatory regulations around sensor data collection
+
+In 2015, the Ministerio de Minas y Energía (Colombia) made it mandatory to have permanent and continuous monitoring systems of carbon monoxide, methane, and oxygen in underground coal mines via [Decreto 1886 de 2015](https://www.funcionpublica.gov.co/eva/gestornormativo/norma.php?i=65325). The ministry gave all coal mine owners a reasonable time frame to implement these systems. However, this time frame meant that Smartbee was working against a clock to be able to cater their platform to coal mine owners. Otherwise, Smartbee would see a substantial loss on investment. On top of that, due to the small team size at Smartbee and Sergio being the only experienced software developer, they were short on hands to accomplish this monumental task.
+
+## Performance issues of previous stacks
+
+For the initial iteration of their MVP, Smartbee started building an online platform, using a combination of PHP and Flask (Python) containers to help manage and synchronize data streamed from their sensors in mines. This solution faced several issues, especially with load management from perpetually streaming data, implementing offline-online synchronization, and security of their servers.
+
+To simplify and accelerate their development process, Sergio started looking for open-source Backend-as-a-Service platforms. He was aware of Firebase in the past; however, Smartbee needed a system that could also be self-hosted in the vicinity of the coal mines. He also came across Supabase; however, their high complexity to self-host turned him away.
+
+
+# Architecting their current solution 
+
+Amid this process, Sergio came across Appwrite. Appwrite’s high count of GitHub stars and highly active developer community were the primary validating factors for him to consider leveraging the product for his platform.
+
+Keeping Appwrite at the center of his solution, Smartbee began working on the platform. Their gas monitoring platform would have the following rungs in the ladder:
+
+1. **Gas monitoring sensors:** Each sensor is an IoT device that constantly monitors and transmits gas levels of Oxygen, Methane, and Carbon Monoxide in the mines
+2. **Local coal mine servers:** Each local mine server accepts the data stream from the sensors in a Python container. This data is stored in a local Appwrite instance in a database collection. The local Appwrite instance also has a storage bucket where CSV reports are generated and updated for daily, weekly, and monthly data using a Python-based Appwrite function. The local server also transmits information every 10 seconds (with a check added for internet availability) to a remote server that constantly aggregates all the data and reports using a Python-based Appwrite function. This server is accessed by the team of each coal mine.
+3. **Remote aggregation server:** The remote Appwrite instance constantly aggregates information from all local coal mine servers. This server is accessible to teams of all the coal mines Smartbee supports (each team only has permission to access their data). The remote server can also restore data from the database collection to the local coal mine server using a Python-based Appwrite function.
+4. **Client application:** The client application is built with Flutter and allows the teams of all the coal mines to view and manage data from their coal mines. Flutter was specifically selected because of its cross-platform nature and high support from the Appwrite team. Smartbee is currently transitioning this application to a SvelteKit web application so it can also be used through the browser.
+
+# The power of an entire team
+
+Using an Appwrite-based stack enabled several benefits for the Smartbee team:
+
+## Solving performance and security problems of a self-developed stack
+
+In the initial MVP that Smartbee built, they faced several performance issues due to their custom Flask-based solution. The solution could barely manage the load from sensors in 2 coal mines. Since transitioning to an Appwrite-based stack, Smartbee is currently sustaining a substantially higher throughput:
+
+1. **Database:** 35 million documents are added from a total of 70 sensors each month
+2. **Bandwidth:** 500GB of bandwidth is transmitted between the IoT sensors, local coal mine servers, and the remote server each month
+3. **Function execution:** 4 million function executions to synchronize data and generate and update the CSV reports each month
+
+## Improved developer productivity due to SDKs, Functions runtimes, and CLI
+
+A significant factor in accelerating Smartbee’s developer productivity was Appwrite’s developer experience. The Appwrite CLI helped Smartbee quickly set up and manage all the local coal mine Appwrite instances and the remote server. Appwrite’s pre-built API endpoints and SDKs meant that Smartbee did not have to re-create any services to support the monitoring platform. They only had to swap in the function calls from Appwrite’s SDK for Python and replace the synchronization and CSV report management scripts with Python-based Appwrite functions. One of the most significant benefits that Smartbee received was our Storage offering. In the past, Smartbee used an FTP server to store and manage reports, which had severe performance deficits, considering the high data stream from Smartbee’s IoT sensors. Appwrite pre-built storage buckets and SDK allowed a simpler-to-implement yet performant alternative. In fact, Sergio learned Flutter and chose it for their client application because of the well-supported Appwrite SDK and learning resources available around the same.
+
+## Support from a highly active and helpful virtual community
+
+Aside from the GitHub stars, the other primary factor that enabled Smartbee to choose Appwrite was our highly active developer community on Discord. The Discord community allowed Sergio to get support from Appwrite whenever he needed it, which enabled him to build the platform successfully. Sergio actively gives back to the Appwrite community today, too, by participating as a voluntary moderator in our Discord server.
+
+# Conclusion
+
+In summary, Smartbee's adoption of Appwrite not only allowed them to address their performance issues but also significantly boosted developer productivity, resulting in a scalable and efficient monitoring platform that they have now catered to 7 coal mines in Colombia.
+
+In Sergio’s own words,
+
+> Just go for it, don’t think twice. Try Appwrite, and you will love it!
+
+Learn more about Smartbee by visiting their [website](https://smartbee.com.co/).
\ No newline at end of file
diff --git a/static/images/blog/kcollect.png b/static/images/blog/kcollect.png
new file mode 100644
index 0000000000..a901ca516c
Binary files /dev/null and b/static/images/blog/kcollect.png differ
diff --git a/static/images/blog/smartbee.png b/static/images/blog/smartbee.png
new file mode 100644
index 0000000000..8dd2322589
Binary files /dev/null and b/static/images/blog/smartbee.png differ