DEV Community: Nelly Mogere

Analysing 8 Years of Femicide in Kenya with Excel - A Data Story

Nelly Mogere — Sat, 04 Jul 2026 01:48:46 +0000

Content Warning: This article discusses femicide, the murder of women and girls. The data covers real cases of gender-based violence. If this is a sensitive topic for you, please take care.

Femicide isn't just a statistic. Every row in the dataset I worked with was someone's daughter, sister, wife, or friend.
When I came across the Femicide in Kenya (2016-2023) dataset on Kaggle, I knew I wanted to do more than scroll through it. I wanted to let the data speak, clearly and loudly. So I built a full analysis pipeline in Excel: cleaning, enriching, analysing, and visualising 507 documented cases over eight years.

This is the story of how I did it, what I found, and why it matters.

Where the Data Came From

The dataset lives on Kaggle and was compiled from multiple verified public sources:

Investigative journalism and news media
Activist platforms and gender-based violence tracking organisations
Social media reports and community alerts

Each row represents one unique femicide case. The columns cover:

Field	What it tells us
Date	When it was reported
Victim Name / Age	Who was targeted
County / Town	Where it happened
Suspect Relationship	Who did it
Type of Femicide	Intimate or Non-intimate
Mode of Killing	How it was done
Murder Scene	Where specifically
Case / Court Status	What happened legally

Before I could analyse any of this, though, the data needed serious cleaning.

Cleaning the Data in Excel Power Query

I loaded the raw file into Excel's Power Query Editor, my go-to for structured, repeatable data transformations. Here's the exact cleaning process I followed, step by step.

Step 1: Remove Duplicates

The first thing I always do. Removed all duplicate rows upfront so every case was counted once and only once.

Step 2: Standardise the Author Name Column

The author names had inconsistent casing, some all caps, some all lowercase. I applied the PROPER function to fix this, so JOHN DOE and john doe both become John Doe.

Step 3: Clean the Medium (News Source) Column

Replaced all null and empty values with "Not Provided".
Removed the (Kenya) suffix that was appended to source names. Since every entry is already Kenya-specific, this was just visual clutter making filters messy.

Step 4: Fix the Type of Murder Column

This one was subtle but important. The column had both femicide and Femicide as separate values - Excel treats them as distinct, which would split my pivot counts in two. I standardised everything to Femicide.

Step 5: Clean the Victim Name Column

Some entries had "unnamed" as the victim's name, others were blank. Both were replaced with "Not Provided" for consistency.

Step 6: Fix the Suspect Relationship Column

Two entries had trailing noise:

Stranger had "/Unknown relationship" appended - redundant. Removed it.
Friend had "/known to the victim" appended - also redundant. Removed it.

These kinds of notes make sense in a notes field, not in a category column you'll filter on.

Step 7: Fill Remaining Nulls Across Text Columns

A blanket step - replaced all remaining null and empty cells in text columns with "Not Provided". This ensures no blank filter entries appear in pivot slicers.

Step 8: Apply PROPER to More Columns

Repeated the PROPER text function across other columns (county names, relationship types, etc.) to prevent capitalisation variants from appearing as duplicate filter options.

Data Enrichment - Adding a Region Column

Once the data was clean, I needed to go one level higher than county for geographic analysis. Kenya has 47 counties - grouping them into the 8 administrative regions would give cleaner, more readable charts.

I built a separate Mapping sheet with each county mapped to its region, then used this XLOOKUP to create a new Region column:

=XLOOKUP(U2, Mapping!$A$2:$A$48, Mapping!$B$2:$B$48, "Unknown County")

This had a bonus effect: it doubled as a spell-checker for county names. Any misspelled county would return "Unknown County" - which flagged it for correction in the source data. A clean, self-validating approach.

Building the Dashboard

With clean, enriched data, I built Pivot Tables for every question I wanted to answer, then assembled everything into a single interactive Excel dashboard with slicers for filtering by county, region, murder scene, relationship type, and more.

Here's what the final dashboard looked like:

The Numbers at a Glance

KPI	Value
Total Cases	507
Most Affected County	Nairobi
Counties Affected	45 out of 47
Intimate Partner Cases	83%
Most Vulnerable Age Range	26-36 years
Minor Victims	20
Most Common Method	Stabbing
Most Common Scene	Home

What the Data Revealed

1. The Home Is the Most Dangerous Place

This was the finding that hit hardest. The majority of femicide victims were killed at home, not on the streets, not in unknown locations, at home.

We talk about home as a place of safety. The data dismantles that assumption.

2. 83% of Cases Involved Intimate Partners

Boyfriends. Husbands. Ex-partners.

8 in 10 femicide cases in this dataset were committed by someone the victim was in, or had been in, a relationship with. Intimate partner violence isn't just a contributor to femicide in Kenya. It is, overwhelmingly, the cause.

3. The Most Targeted Age Group Is 26-36

These are women in the prime of their adult lives, building careers, raising families, living independently. The data shows they are the most at-risk group.

Twenty victims were minors. Twenty children.

4. Stabbing and Strangulation Dominate

The two most recorded methods of killing were stabbing and strangulation. Both require physical proximity. This is not random or opportunistic violence - it is violence by someone close to the victim, in spaces familiar to her.

5. This Is a National Crisis, Not a Nairobi Story

Yes, Nairobi had the highest case count. But 45 of Kenya's 47 counties recorded at least one femicide case in this dataset. The geographic spread is a clear signal: this is a nationwide systemic problem.

6. The Justice System Is Failing These Women

When I looked at the court verdict breakdown, the majority of cases never reached a guilty verdict. Many were ongoing. Some suspects were never brought to trial at all. The impunity is visible in the data.

7. Arguments Over Food

I'll be honest, this stopped me in my tracks. Going through case descriptions, several murders were triggered by domestic arguments. One recurring trigger: food.

Arguments over food. Women losing their lives over arguments about food.

That's not just a data point. That's a reflection of what happens when control, anger, and access to violence exist in the same home.

Why I Built This

I'm a data analyst. My tools are spreadsheets, formulas, and charts. But tools don't choose what they illuminate, we do.

I chose to work on this dataset because the story it tells is important, and because too often data on gender-based violence gets buried in PDFs or left uncleaned on data platforms. I wanted to take it out of the raw and make it readable, visual, and undeniable.

If you're a researcher, journalist, policymaker, or just someone who cares, I hope this analysis gives you something useful.

Tools I Used

Microsoft Excel - Power Query for cleaning, XLOOKUP for enrichment, Pivot Tables for aggregation, Charts for visualisation, Dashboard for presentation

That's it. No Python. No SQL. No Power BI. Just Excel used thoughtfully and thoroughly.

Access the Files

The full project, including the raw dataset, cleaned file, and dashboard, is on GitHub:

(https://github.com/pinkleather221/kenya-femicide-analysis.git)

Final Note

Behind every row in this dataset is a name. A face. A life that was ended by violence that could have been prevented.

If this analysis can contribute, even a small amount, to better policy, stronger advocacy, or clearer public understanding of the femicide crisis in Kenya, then it was worth building.

If you found this useful or have questions about the methodology, drop a comment below. And if you're working on similar social impact data projects, I'd love to connect.

From Dirty Data to Business Intelligence: Building an End-to-End Power BI Analytics Solution with PostgreSQL, Power Query, DAX, and Star Schema

Nelly Mogere — Fri, 03 Jul 2026 12:44:39 +0000

How I transformed a messy education dataset into an interactive Business Intelligence solution using PostgreSQL, Power Query, Data Modeling, DAX, and Power BI.

Introduction

Every dashboard tells a story.

But before the charts, KPIs, and colorful visuals come into existence, there's usually something much less exciting a spreadsheet full of inconsistent, duplicated, incomplete, and poorly structured data.
That was exactly the challenge my team received during our Power BI training.
Instead of being handed a perfectly structured dataset ready for visualization, we were given what many data professionals encounter in real organizations: a single flat dataset filled with inconsistencies that needed to be transformed into a reliable source of business intelligence.
Our assignment wasn't simply to create attractive charts.
Our assignment wasn't simply to create attractive charts.

We were expected to complete the entire Business Intelligence workflow, including:

Extracting data from a PostgreSQL database
Establishing a secure database connection using SSL certificates
Cleaning messy data using Power Query
Designing a dimensional data model
Creating relationships between tables
Writing DAX measures
Building interactive dashboards
Producing meaningful business insights

Although this was an educational project, the workflow closely mirrors what Business Intelligence developers and Data Analysts do every day.

In this article, I'll walk through that journey from start to finish.

Understanding the Business Problem

The dataset represented an education management system containing information about:

Students
Schools
Teachers
Subjects
Academic performance
Payments
Locations

At first glance, everything appeared to exist inside one large table. While this may seem convenient, storing everything in a single table quickly creates problems.

Some of the issues included:

Duplicate information
Repeated school names and teacher details
Inconsistent county names and spelling
Mixed capitalization
Missing values
Incorrect data types and invalid numerical values

These are exactly the kinds of data quality issues that reduce trust in business reports. Our brief required us to clean the data, normalize it into logical tables, build relationships, and answer business questions through an interactive Power BI dashboard.

Why We Used PostgreSQL Instead of Importing a CSV

Many Power BI tutorials begin by importing an Excel or CSV file. While this works for demonstrations, most organizations do not store operational data inside spreadsheets.

Instead, business data is typically stored inside relational databases such as PostgreSQL, SQL Server, MySQL, or Oracle.

For this project, our dataset was hosted inside a PostgreSQL database, allowing us to simulate a real production environment where Power BI retrieves data directly from a database rather than from manually exported files.

This approach offered several advantages:

A centralized source of truth
Better data integrity
Easier scalability
Simplified data refreshes
A more realistic enterprise workflow

Configuring PostgreSQL for Secure Connections

One of the most interesting parts of this project happened before opening Power BI.

To establish a secure connection to PostgreSQL, I first had to install and configure the required SSL certificates. Many cloud-hosted PostgreSQL instances enforce encrypted connections to protect data while it travels across the network. Without the correct certificates, Power BI cannot establish a trusted connection.

The process involved:

Installing the PostgreSQL SSL certificate
Configuring the database connection
Verifying encrypted communication
Testing the connection before importing data

Although this step often receives little attention in beginner tutorials, it reflects what happens in production systems where database security is a priority.

Key takeaway: Understanding secure connectivity is just as important as understanding visualization, because no dashboard can exist without reliable access to trusted data.

Connecting PostgreSQL to Power BI

With the secure connection established, I opened Power BI Desktop and selected Get Data > PostgreSQL Database.

After providing the server name, database name, and authentication credentials, Power BI connected directly to PostgreSQL and displayed the available tables through the Navigator window.

Rather than importing every available object, I selected only the tables required for analysis. This is a small but important optimization, because importing unnecessary tables increases model complexity and refresh times.

First Look at the Dataset

The initial inspection confirmed what the assignment description had warned about. The dataset contained numerous quality issues, including duplicate records, null values, incorrect spellings, mixed casing, inconsistent location names, invalid numerical values, and poorly formatted dates.

Important lesson: At this point, jumping directly into building charts would have produced misleading results. A dashboard is only as reliable as the data behind it.

For this reason, data preparation became the next priority.

Cleaning the Data with Power Query

Power Query is one of Power BI's most powerful features. Instead of modifying the source database, Power Query allows analysts to transform incoming data while keeping the original source untouched. This creates a repeatable Extract, Transform, and Load (ETL) process that can be refreshed whenever new data becomes available.

Our cleaning process involved several key transformations:

Standardizing Text

Some records used uppercase values, others used lowercase, and some contained abbreviations or spelling mistakes. For example, a county could appear in several different forms, causing Power BI to treat them as different locations. We standardized these values to ensure consistency across the entire dataset.

Correcting Data Types

Columns representing numbers had occasionally been interpreted as text, and date columns contained inconsistent formats. Power Query made it possible to convert each column into its correct data type before analysis.

Why this matters: Proper data types are essential because DAX calculations depend on them. A number stored as text cannot be summed or averaged.

Handling Missing Values

Several fields contained null values. Rather than blindly deleting records, we evaluated each case individually. Depending on the context, we either replaced missing values, kept them for transparency, or excluded unusable records where appropriate. Documenting these decisions is an important part of responsible data preparation because every transformation influences the final analysis.

Removing Duplicates

Repeated records inflate KPIs and distort business insights. Duplicate students, schools, or teachers could easily lead to incorrect counts. Power Query enabled us to identify and remove duplicate records while preserving unique entities.

Renaming Columns

Clear naming conventions improve model readability. Instead of cryptic or inconsistent column names, we renamed fields using descriptive, business-friendly names. This makes DAX formulas easier to understand and simplifies collaboration.

Creating a Repeatable Transformation Pipeline

One of Power Query's greatest strengths is that every transformation becomes an Applied Step. Instead of manually repeating the cleaning process each time new data arrives, Power BI simply replays the transformation steps automatically during refresh. This makes the cleaning process reproducible, auditable, and significantly less error-prone.

Why We Did Not Keep Everything in One Flat Table

Once the data was clean, an important question emerged: should everything remain inside one giant table?

Technically, it could. Practically, it should not.

Flat tables work for small datasets, but as projects grow they become difficult to maintain. Repeated information wastes storage, complicates updates, and slows analytical queries. Instead of keeping one massive table, we normalized the data into a dimensional model that better represents how business entities relate to one another.

This decision laid the foundation for the next and arguably most important phase of the project: building a Star Schema.

Building a Scalable Data Model with a Star Schema

At this point, our data had been cleaned, standardized, and prepared for analysis. However, one major challenge still remained: the dataset still represented an operational system rather than an analytical one.

Operational databases are designed to store information efficiently. Business Intelligence systems are designed to analyze information efficiently. Those are two very different objectives.

If we had continued using one massive flat table, we would have encountered several problems:

The same school information repeated hundreds of times
Teacher information duplicated for every student
Location information stored repeatedly
Larger file sizes and slower report performance
More complex DAX calculations
Higher maintenance costs whenever data changed

Instead, we redesigned the model using one of the most widely adopted dimensional modeling techniques in Business Intelligence: the Star Schema.

Why Star Schema?

Before building the model, we briefly considered the three most common approaches:

Flat Table: Stores everything in one place. While it appears simple at first, it becomes increasingly difficult to maintain because every entity is repeated multiple times. Imagine a school with 800 students. The school's name would appear 800 separate times in the table.

Snowflake Schema: Introduces additional normalization by breaking hierarchical data into separate tables (Country > Region > County > Sub-county). This reduces redundancy further but also increases relationship complexity. For our assignment, this introduced unnecessary overhead.

Star Schema: Strikes an excellent balance between simplicity, performance, and scalability. The design consists of one central Fact Table surrounded by multiple Dimension Tables. Microsoft also recommends Star Schema as the preferred modeling approach for Power BI because it simplifies filtering, improves query performance, and makes DAX calculations easier to write.

Designing the Fact Table

The fact table became the heart of our analytical model. Unlike dimension tables, which describe entities, the fact table stores measurable events such as:

Student scores
Fee payments
Attendance records
Performance metrics

Every row in a fact table represents an event that can be analyzed. For example:

Notice that the fact table references other entities rather than storing all their descriptive information repeatedly. Instead of storing the teacher's county, school address, and contact details every time, it simply stores a key pointing to the Teacher table. This dramatically reduces redundancy.

Building the Dimension Tables

Once the fact table was identified, we separated descriptive information into dedicated dimension tables:

Student Dimension contained: Student ID, Student Name, Gender, Age, School, County

Teacher Dimension contained: Teacher ID, Teacher Name, Assigned School, Subject

School Dimension contained: School ID, School Name, Category, Location

Subject Dimension contained: Subject ID, Subject Name

Location Dimension centralized county and region information into a reusable table. This allows both schools and teachers to reference the same geographical information while maintaining consistency.

Understanding Primary Keys and Foreign Keys

One concept that finally clicked for me during this project was the relationship between primary and foreign keys.

A Primary Key uniquely identifies each record within a table. For example:

School ID	School Name
101	Green Hills Academy
102	Sunrise School

The School ID is unique. No two schools share the same identifier.

A Foreign Key references the primary key of another table. For example:

Student	School ID
Alice	101
Brian	102

Rather than writing the school name repeatedly, each student simply stores the corresponding School ID. Power BI then uses relationships to retrieve the descriptive information whenever required. This is one of the principles that makes relational databases so efficient.

Creating Relationships in Power BI

Once the tables had been separated, we connected them using relationships. Power BI supports several relationship types:

One-to-One: Every record matches exactly one record in another table. Valid but relatively uncommon in analytical models.

One-to-Many: This became the dominant relationship in our project. For example, one school has many students; one teacher has many student records; one subject has many assessment records. This relationship type reflects how educational data naturally behaves.

Many-to-One: Power BI often displays the same relationship from the opposite perspective. Many students belong to one school. The underlying relationship remains identical.

Understanding Cardinality

Cardinality determines how Power BI filters information across related tables. If relationships are configured incorrectly, visuals may return duplicated values or incorrect totals. Because our model followed a proper Star Schema, defining cardinality became much more straightforward, with most relationships naturally following a One-to-Many structure.

Filter Direction

Power BI allows filters to flow between related tables. Whenever possible, we maintained single-direction filtering, allowing filters to flow from the dimension tables toward the fact table. For example, selecting a county automatically filtered schools, students, teachers, and performance records. This simplified report behavior while reducing ambiguity during DAX calculations.

Why Normalization Matters

Dividing one table into several smaller tables might appear to make the project more complicated. Ironically, the opposite is true. Normalization makes the model easier to maintain, easier to understand, faster to query, less repetitive, and more scalable. As datasets grow, these benefits become increasingly significant.

Turning Data into Insights with DAX

After building the data model, the next step was teaching Power BI how to answer business questions. This is where Data Analysis Expressions (DAX) became essential.

Think of DAX as the language that teaches Power BI how to think. While relationships organize data, DAX transforms that organized data into business metrics.

Calculated Columns vs. Measures

One key lesson from this project was understanding the difference between these two approaches:

Calculated Columns compute values for every row and store the result in the model
Measures calculate results dynamically based on the filters applied by the user

Since dashboards are interactive, measures are generally the better choice because they recalculate automatically as users interact with slicers and filters.

Measures We Created

Total Students
Total Schools
Total Teachers
Average Student Score
Student Distribution
School Distribution

Where the dataset lacked complete information, such as revenue or outstanding balances, we intentionally avoided creating misleading measures. Instead, we documented the limitation and focused our analysis on the data that was available.

Important principle: Good analysts never invent data to satisfy a report.

Applying Business Logic with DAX

Beyond simple aggregations, DAX can encode business rules. Functions such as IF(), AND(), and OR() allow multiple conditions to be evaluated, while SWITCH(TRUE()) provides a cleaner alternative to long nested IF statements.

For example, a revenue classification measure could be written as:

Revenue Category =
SWITCH(
    TRUE(),
    ISBLANK([Revenue]), "Not Provided",
    [Revenue] > 500000, "High Revenue",
    [Revenue] > 100000, "Medium Revenue",
    [Revenue] > 0, "Low Revenue"
)

We also learned how CALCULATE() changes the filter context, enabling measures such as total students in a specific county or average scores for selected schools. This flexibility is one of the reasons DAX is such a powerful analytical language.

Designing the Interactive Dashboard

With the model and measures complete, the final step was presenting the insights.

Our dashboard combined several visualizations to answer the questions outlined in the project brief:

KPI Cards for key metrics
Bar and Column Charts for comparisons
Donut Charts for distributions
Slicers for filtering by school, county, teacher, subject, and gender
Tables for detailed records

Rather than filling the report with as many visuals as possible, we focused on clarity. Each chart answered a specific business question, and together they formed a cohesive analytical story.

Key Insights from the Project

Building the dashboard highlighted how quickly insights become accessible once data is properly prepared. Users could identify:

Schools with the highest student populations
Student distribution across locations
Gender distribution
Teacher allocation
Subject performance
Academic trends across schools and regions

More importantly, the project demonstrated that the quality of these insights depended entirely on the quality of the underlying data model.

Beyond Power BI Desktop

One topic we covered during training was what happens after a report is built.

Publishing a report to the Power BI Service allows organizations to:

Share reports securely with stakeholders
Schedule automatic data refreshes
Create email subscriptions that send report snapshots at scheduled intervals
Embed reports into web applications and organizational portals

We also explored Microsoft Fabric, Microsoft's unified analytics platform that brings together data engineering, data warehousing, real-time analytics, and business intelligence into a single ecosystem. Although our project was developed in Power BI Desktop, understanding how it fits within the broader Microsoft analytics platform provided valuable context for enterprise-scale solutions.

Lessons I Took Away

This project changed the way I think about dashboards.

Before, I assumed the most important skill in Power BI was creating attractive visualizations. I now realize that visualization is only the final stage of a much larger process.

The real work happens long before the first chart is created:

Connecting securely to data sources
Cleaning inconsistent data
Designing scalable data models
Building meaningful relationships
Writing reusable DAX measures
Delivering insights that decision-makers can trust

A visually impressive dashboard built on poor-quality data is still a poor dashboard.

Final Thoughts

What began as a classroom assignment became an excellent introduction to the complete Business Intelligence workflow.

Over the course of the project, I learned how to connect Power BI to a PostgreSQL database using secure SSL connections, transform messy data with Power Query, redesign a flat dataset into a Star Schema, create relationships between fact and dimension tables, write DAX measures, and communicate insights through an interactive dashboard.

More importantly, I learned that Business Intelligence is not about creating charts. It is about transforming raw, imperfect data into information that supports better decisions.

As I continue exploring data engineering and analytics, this project serves as a reminder that every reliable dashboard begins with a well-designed data pipeline, a thoughtful data model, and a commitment to data quality.

Resources

If you are learning Power BI, I would recommend exploring:

Connect With Me

If you are working on Power BI, data engineering, or analytics projects, I would love to connect and exchange ideas.

GitHub: https://github.com/pinkleather221/

How Excel is Used in Real-World Data Analysis

Nelly Mogere — Sat, 06 Jun 2026 06:57:21 +0000

Introduction

In today’s digital world, data is everywhere. Businesses, schools, hospitals and organizations collect large amounts of information every day. One of the most commonly used tools for organizing and analyzing this data is Microsoft Excel.

Before starting my data analytics journey, I viewed Excel as a simple spreadsheet application mainly used for typing tables and performing calculations. However, after learning more about it during my training at LuxDevHQ, I now understand how powerful and important it is in real-world data analysis.

What is excel

Microsoft Excel is a spreadsheet software developed by Microsoft that helps users:

Organize data
Perform calculations
Analyze information
Create charts and reports
Visualize trends and patterns

Excel is widely used because it is easy to learn, flexible, and useful in many industries.

Real-World application of excel in data analysis

1. Business decision-making
Businesses use Excel to track and analyze important information such as:

Sales performance
Inventory records
Employee performance
Customer trends

For example, a company can use Excel to identify which products sell the most and which products are underperforming. This helps managers make better business decisions.

2. Financial Reporting and Budgeting
Excel is heavily used in finance and accounting. Companies use it to:

Calculate profits and losses
Track expenses
Prepare budgets
Forecast future revenue

Functions like SUMIF and AVERAGEIF help analysts quickly calculate totals and averages based on specific conditions.

Excel Features and Formulas I Have Learned

So far, I have learned several useful Excel features and formulas that are commonly used in data analysis.

Features

Freeze Panes
This feature keeps important rows or columns visible while scrolling through large datasets.

Remove Duplicates
This helps clean data by removing repeated information, making datasets more accurate and organized.

Formulas

SUMIF
Used to calculate totals based on a condition.
Example:
Calculating total sales from a specific region.

AVERAGEIF
Used to find averages that meet certain conditions.
Example:
Finding the average marks of students in one class.

COUNTIFS
Used to count values that meet multiple conditions.
Example:
Counting customers from a certain city who purchased a specific product.

My Personal Reflection

At first, I thought Excel was something simple and easy. However, after attending classes and practicing different features and formulas, I now realize that Excel is a powerful analytical tool used in real-world industries.

Even with the few classes I have attended so far, I already feel more confident working with data. I can now:

Find insights from datasets
Calculate totals and averages
Clean messy data
Visualize information clearly

This learning experience has made me more interested in data analytics and I look forward to learning more advanced skills in the future.

Conclusion

Excel plays a major role in real-world data analysis because it helps people organize, analyze and understand data efficiently. From business reporting to financial analysis and marketing insights, Excel continues to be one of the most valuable tools in the world of data.

As a beginner in data analytics, learning Excel has given me confidence and a better understanding of how data can be used to solve real-world problems.

I Built a Cloud Platform That Does Absolutely Nothing (And It Works Perfectly)

Nelly Mogere — Mon, 06 Apr 2026 05:31:11 +0000

This is a submission for the DEV April Fools Challenge

What I Built

I’ve spent a ridiculous amount of time learning cloud architecture, Kubernetes, scaling systems… all the serious stuff.
So naturally, I decided to build something completely useless.
I present: Cloud Architect Simulator™ a platform that successfully deploys absolutely nothing… at scale.
You can:
Deploy apps that don’t exist
Auto-scale to infinity (with 0 users 💀)
Optimize your infrastructure using AI (which deletes everything for better performance)
Brew coffee via API (spoiler: I’m a teapot ☕)
There’s even a region selector with options like Mars (Beta) and Some Guy’s Laptop because… why not?
The whole idea was to poke fun at how complex and over-engineered cloud systems can get except here, all that complexity leads to absolutely no outcome.
And somehow… it still works perfectly.

Demo

pinkleather221.github.io

Everything is working exactly as it shouldn’t

Code

pinkleather221 / Cloud-Architect-Simulator-Deploying-Nothing-at-Scale-

Cloud Architect Simulator™ is a fake cloud platform where you deploy apps that don’t exist, scale to infinity with zero users, and optimize everything into nothing. Built for the DEV April Fools Challenge, it’s a playful take on over-engineered systems.

Cloud-Architect-Simulator-Deploying-Nothing-at-Scale-

Cloud Architect Simulator™ is a fake cloud platform where you deploy apps that don’t exist, scale to infinity with zero users, and optimize everything into nothing. Built for the DEV April Fools Challenge, it’s a playful take on over-engineered systems.

View on GitHub

It’s a simple HTML, CSS and JavaScript setup nothing fancy, just pure intentional nonsense layered on top of clean structure.

How I Built It

I kept the stack intentionally simple:
HTML for structure
CSS for styling (dark mode because we’re engineers obviously)
Vanilla JavaScript for all the chaotic interactions
Most of the logic is just fake state changes, random values and delayed responses to make it feel real.
The fun part was designing interactions that look legitimate at first… and then slowly fall apart.
For example:
Fake deployment logs that end in “No application found”
Billing that spikes randomly then pretends nothing happened
AI optimization that aggressively removes everything
It’s basically a real cloud dashboard… if it had an existential crisis.

Prize Category

I had to pay respect to the legendary 418 I’m a teapot energy.
The “Brew Coffee API” feature is my tribute it goes through a whole dramatic process before ultimately refusing to cooperate because… it’s a teapot.
It felt very on-brand for a project that commits fully to doing the wrong thing in the most elaborate way possible.