I am Amit Shekhar, Founder @ Outcome School, I have taught and mentored many developers, and their efforts landed them high-paying tech jobs, helped many tech companies in solving their unique problems, and created many open-source libraries being used by top companies. I am passionate about sharing knowledge through open-source, blogs, and videos.

I teach AI and Machine Learning, and Android at Outcome School.

Join Outcome School and get high paying tech job:

• Outcome School AI and Machine Learning Program
• Outcome School Android Program

In this blog, we will learn about KV Cache – where K stands for Key and V stands for Value – and why it is used in Large Language Models (LLMs) to speed up text generation.

We will start with how LLMs generate text one token at a time, understand the role of Key, Value, and Query inside the model, see the problem of repeated computation through an example, and then walk through how KV Cache solves this problem by storing and reusing past results.

Let’s get started.

How LLMs Generate Text

Before we understand KV Cache, we first need to understand how LLMs generate text.

An LLM – Large Language Model – is a model that has been trained on a massive amount of text data. It can understand and generate human language. When we give it a sentence, it predicts what comes next.

LLMs generate text one token at a time. A token is a small piece of text – it can be a word, part of a word, or even a single character. For simplicity, let’s treat each word as one token.

Let’s say we give the model this input:

"I love"

The model looks at “I” and “love”, and predicts the next token: “teaching”.

Now the full sequence becomes:

"I love teaching"

The model looks at “I”, “love”, and “teaching”, and predicts the next token: “AI”.

Now the full sequence becomes:

"I love teaching AI"

This process continues, one token at a time, until the model decides to stop.

The important thing to notice here is: every time the model predicts a new token, it needs to look at all the previous tokens to decide what comes next.

What Happens Inside the Model

Now, let’s understand what happens inside the model when it generates each token.

The model has a component called the attention layer. The job of the attention layer is to help the model figure out which previous tokens are important for predicting the next token. Not all previous tokens are equally useful. Some matter more than others.

Inside the attention layer, every token is converted into three things. Let’s understand each of them with a simple analogy.

Imagine a classroom where a new student joins and wants to find out who can help with a specific topic:

• Query (Q): The new student’s question – “Who here knows about this topic?” Every token being predicted gets a Query. It represents what the token is looking for.
• Key (K): The name tag each existing student wears that says what they know – “I know about math” or “I know about science.” Every previous token gets a Key. It describes what information that token holds.
• Value (V): The actual notes each student has. Once the new student finds the right person using their name tag (Key), the notes (Value) are what they actually use. Every previous token gets a Value. It carries the actual information.

So, the current token uses its Query to compare against the Keys of all previous tokens. This comparison produces attention scores – numbers that tell the model how much focus to give to each previous token. A higher score means that token is more relevant. A lower score means it is less relevant. The model then uses these scores to collect the Values from the relevant tokens.

This is how the attention layer works.

Now, let’s see the problem.

The Problem: Repeated Computation

Every time the model predicts the next token, it computes the Key, Value, and Query for all tokens in the sequence – not just the new one.

Let’s see what happens step by step with our example:

Step 1: Input is “I love”

The model computes Key, Value, and Query for:

• “I”
• “love”

It uses these to predict the next token: “teaching”.

Step 2: Input is “I love teaching”

The model computes Key, Value, and Query for:

• “I” (already computed in Step 1, but computed again)
• “love” (already computed in Step 1, but computed again)
• “teaching” (new)

It uses these to predict the next token: “AI”.

Step 3: Input is “I love teaching AI”

The model computes Key, Value, and Query for:

• “I” (already computed in Step 1 and Step 2, but computed again)
• “love” (already computed in Step 1 and Step 2, but computed again)
• “teaching” (already computed in Step 2, but computed again)
• “AI” (new)

Do you see the problem?

The Key and Value for “I” were computed in Step 1. But the model computes them again in Step 2, and again in Step 3. The same goes for “love” and “teaching”.

The model is repeating the same work for tokens it has already seen. This is wasted computation.

As the sequence grows longer, this problem gets worse. If the model has already generated 100 tokens, then at the next step, it would recompute the Key and Value for all 100 previous tokens just to predict one new token. This makes text generation very slow.

The Solution: KV Cache

The idea behind KV Cache is simple: compute the Key and Value for each token once, store them, and reuse them in every future step.

Think of it like taking notes. Imagine you are in a meeting. Every time someone new speaks, instead of asking all the previous speakers to repeat what they said, you simply read from your notes and only listen to the new speaker. The notes are your cache.

Similarly, KV Cache is a memory where we save the Key and Value of every token that has already been processed. This way, the model does not have to compute them again.

Let’s see how the same example works with KV Cache:

Step 1: Input is “I love”

The model computes Key, Value, and Query for:

• “I”
• “love”

It saves the Key and Value of “I” and “love” in the KV Cache.

It uses these to predict the next token: “teaching”.

KV Cache now contains: Key and Value for “I”, “love”

Step 2: Input is only “teaching” (only the new token)

The model retrieves the Key and Value of “I” and “love” from the KV Cache. No recomputation needed.

It computes Key, Value, and Query only for the new token: “teaching”.

It saves the Key and Value of “teaching” in the KV Cache.

It uses all of these together to predict the next token: “AI”.

KV Cache now contains: Key and Value for “I”, “love”, “teaching”

Step 3: Input is only “AI” (only the new token)

The model retrieves the Key and Value of “I”, “love”, and “teaching” from the KV Cache. No recomputation needed.

It computes Key, Value, and Query only for the new token: “AI”.

It saves the Key and Value of “AI” in the KV Cache.

KV Cache now contains: Key and Value for “I”, “love”, “teaching”, “AI”

So, instead of recomputing the Key and Value for every token at every step, the model computes them only for the new token and reuses the cached values for all previous tokens.

This is how KV Cache avoids repeated computation.

Why Only Key and Value Are Cached, Not Query

You would naturally ask: why do we cache only the Key and Value, and not the Query?

The Query is only needed for the current token – the one being generated right now. The current token uses its Query to compare against the Keys of all previous tokens to find which ones are relevant. Once the prediction is done, that Query is no longer needed.

But the Key and Value of every past token are needed at every future step, because every new token must look at all the previous tokens to make its prediction.

So, we only need to store the Keys and Values. This is why it is called KV Cache – it caches the Keys and Values.

How Much Faster Does It Get

Let’s compare the two approaches side by side:

Without KV Cache:

Step 1: Compute K, V, Q for 2 tokens
Step 2: Compute K, V, Q for 3 tokens  (2 recomputed)
Step 3: Compute K, V, Q for 4 tokens  (3 recomputed)
Step 4: Compute K, V, Q for 5 tokens  (4 recomputed)
...
Step N: Compute K, V, Q for (N+1) tokens  (N recomputed)

The amount of computation keeps growing at every step.

With KV Cache:

Step 1: Compute K, V, Q for 2 tokens → Save K, V for 2 tokens in cache
Step 2: Compute K, V, Q for 1 token  → Reuse K, V for 2 tokens from cache
Step 3: Compute K, V, Q for 1 token  → Reuse K, V for 3 tokens from cache
Step 4: Compute K, V, Q for 1 token  → Reuse K, V for 4 tokens from cache
...
Step N: Compute K, V, Q for 1 token  → Reuse K, V for N tokens from cache

After the first step, the model computes only for one new token at each step instead of the entire sequence.

To put this into perspective: if the model is generating a sequence of 100 tokens, without KV Cache, the total number of Key and Value computations across all steps would be 2 + 3 + 4 + … + 100 = 5,049 computations. With KV Cache, it would be 2 + 1 + 1 + … + 1 = 101 computations. That is roughly 50 times fewer computations. The longer the sequence, the bigger the savings.

This is what makes KV Cache so effective at speeding up text generation.

The Trade-Off: Speed vs Memory

KV Cache makes generation faster, but it comes with a trade-off: it uses extra memory to store all the Key and Value information for every token that has been generated so far.

As the sequence gets longer, the cache grows larger. For very long sequences with thousands of tokens, the cache can consume a significant amount of memory.

So, KV Cache is a trade-off: we use more memory to save computation time. For most use cases, this trade-off is well worth it, as the speed improvement is significant.

Now, we have understood the KV Cache in LLMs.

In the next blog, we will learn about Paged Attention that solves the memory issue of KV Cache.

Prepare yourself for AI Engineering Interview: AI Engineering Interview Questions

That’s it for now.

Thanks

Amit Shekhar
Founder @ Outcome School

You can connect with me on:

• X
• LinkedIn
• YouTube
• GitHub

Follow Outcome School on:

• X
• LinkedIn
• YouTube
• GitHub

Read all of our high-quality blogs here.

A lot of system design content looks impressive… until you actually try to build it.

I’ve seen architectures that look clean on paper but fall apart the moment real traffic hits.

So instead of theory, I decided to break things down from a builder’s perspective:

What does it actually take to build a scalable, Netflix-style system on AWS?

Let’s get into it—no fluff.

🧱 1. The Real Architecture (Not Just Diagrams)

At a high level, your system should look like this:

Users → CloudFront → API Gateway → Load Balancer → Microservices (EKS/ECS)
→ Cache (Redis) → Databases (RDS/DynamoDB)
→ Monitoring (CloudWatch + Prometheus)

When I first started designing systems like this, I underestimated how important each layer is. Skip one, and everything downstream suffers.

🌐 2. CDN + API Gateway: Your First Line of Defense

Before your backend even sees traffic:

CloudFront handles global content delivery
API Gateway manages routing, throttling, and security
Why this matters:

If you don’t control traffic at the edge:
👉 Your backend gets overwhelmed fast

Real talk—I’ve seen setups where skipping proper API management led to unnecessary load and higher costs.

⚖️ 3. Load Balancer: Keep Things Even

Use:

Application Load Balancer (ALB)
Incoming Traffic → ALB → Multiple Service Instances

This is what prevents:

One server from getting slammed
Others sitting idle

If your traffic distribution isn’t balanced, scaling won’t save you.

🧩 4. Microservices (This Is Where Complexity Starts)

Breaking a system into services sounds nice… until you manage them.

Example services:
User Service
Recommendation Service
Content Metadata Service
Deployment example:
apiVersion: apps/v1
kind: Deployment
metadata:
name: recommendation-service
spec:
replicas: 3
selector:
matchLabels:
app: recommendation
template:
metadata:
labels:
app: recommendation
spec:
containers:
– name: app
image: your-docker-image
ports:
– containerPort: 80

In one of my deployments, increasing replicas alone handled a traffic spike without touching the core logic.

That’s the power of proper separation.

⚡ 5. Caching (This Will Save You)

Let me be blunt:

If you skip caching, your database becomes your bottleneck.

Use:

Amazon ElastiCache (Redis)
Flow:
Request → Cache → (miss) → DB → Cache → Response

I ran into this early—DB latency started creeping up under load.

Adding Redis reduced response times instantly.

🧠 6. Database Strategy: One Size Doesn’t Work

Don’t rely on a single database.

Use a mix:
Use Case Service
User data RDS (PostgreSQL)
High scale reads DynamoDB
Logs/events S3

👉 SQL for consistency
👉 NoSQL for scale

If your DB can’t scale independently, your entire system is fragile.

🔄 7. Auto Scaling: Handle Traffic Without Panic

Set scaling rules based on:

CPU usage
Request count
Latency
Example:
CPU > 70% → Scale up
CPU < 30% → Scale down

This is what keeps your system alive during spikes.

Without it, you’re just hoping traffic stays low.

📊 8. Observability: Don’t Fly Blind

Use:

CloudWatch → logs & metrics
Prometheus + Grafana → deeper insights

Track:

Response time
Error rates
Throughput

From experience, debugging without proper monitoring is chaos.

You’ll waste time guessing instead of fixing.

🧬 9. Resilience: Design for Failure

At scale:

Things WILL break.

So, prepare:

Retry logic
Circuit breakers
Fallback responses

If one service fails:
👉 Your system should degrade gracefully—not crash.

🔥 Real Scenario

Let’s say:

A new feature drop
Traffic spikes 10x

Here’s what happens in a well-built system:

CloudFront absorbs global traffic
API Gateway controls request flow
ALB distributes load
Auto-scaling spins up more instances
Redis serves cached data
Databases stay stable

👉 No downtime
👉 No panic

💥 Where Most People Get It Wrong

Let’s be honest:

Overcomplicating too early
Ignoring caching
Relying on one database
No monitoring
No scaling strategy

I’ve seen systems that looked “advanced” but failed under basic load.

Complex ≠ scalable.

🧠 Key Takeaways
Control traffic at the edge
Scale horizontally
Cache aggressively
Use the right database for the job
Monitor everything
Expect failure
⚡ Final Thought

You don’t need Netflix-scale systems on day one.

But if you build without thinking about scale:

You’ll rebuild everything later.

🔥 Follow My Journey

I’m building AI systems, telecom infrastructure, and scalable platforms—and sharing what actually works (and what doesn’t).

If you’re into real-world engineering, not just theory, follow me for more.

zeed_xo.

ClickHouse Queries Billions of Rows in Milliseconds

PostgreSQL chokes on analytical queries over 100M rows. ClickHouse handles billions — and returns results in milliseconds. Thats not a typo.

What Makes ClickHouse Fast

ClickHouse is a column-oriented OLAP database:

• Columnar storage — reads only the columns you query
• Vectorized execution — processes data in batches using SIMD
• Compression — 10-40x compression ratios on real data
• Parallel processing — uses all CPU cores for every query
• Materialized views — pre-aggregate data on insert
• SQL compatible — standard SQL with extensions

Quick Start

# Docker
docker run -d --name clickhouse 
  -p 8123:8123 -p 9000:9000 
  clickhouse/clickhouse-server

# Connect
docker exec -it clickhouse clickhouse-client

# Create table
CREATE TABLE events (
  timestamp DateTime,
  user_id UInt64,
  event_type LowCardinality(String),
  properties String
) ENGINE = MergeTree()
ORDER BY (event_type, timestamp);

# Insert 1M rows in seconds
INSERT INTO events SELECT
  now() - randUniform(0, 86400*30),
  rand64() % 100000,
  arrayElement(['click,view,\purchase,signup], rand() % 4 + 1),
  {}
FROM numbers(1000000);

# Query — milliseconds on 1M rows
SELECT event_type, count(), uniq(user_id)
FROM events
WHERE timestamp > now() - INTERVAL 7 DAY
GROUP BY event_type;

ClickHouse vs PostgreSQL for Analytics

Free Options

• Self-hosted: completely free, unlimited
• ClickHouse Cloud: free tier with 10GB storage
• chDB: embedded ClickHouse in Python (pip install chdb)

When to Use ClickHouse

✅ Analytics dashboards, log analysis, time-series data
✅ Data warehousing, BI queries, metrics aggregation
❌ OLTP workloads (use PostgreSQL)
❌ Small datasets under 1M rows (overkill)

Need fast analytics? I help teams set up ClickHouse for real-time dashboards and log analysis.

📧 [email protected] — Analytics infrastructure consulting

Follow for more database deep dives.

If you run a GitHub repo with more than a handful of contributors, you know the pain: issues pile up, PRs go unreviewed, and critical bugs sit next to typo fixes with no way to tell them apart.

I got tired of spending 30+ minutes every morning just reading notifications, so I built DevOps Inbox Zero — an n8n workflow that does the triage for me.

What It Does

Every time a GitHub issue or PR is created, the workflow:

1. Catches the event via GitHub webhook
2. Sends it to GPT-4o-mini with a structured prompt
3. Gets back a JSON classification: priority (critical/high/medium/low), category (bug/feature/security/docs/infra/test), suggested owner, and recommended action
4. Routes to the right Slack channel based on priority
5. Creates a ticket in Linear or Jira (optional) with all the context

The whole thing runs in under 3 seconds per event and costs about $0.001 per classification (GPT-4o-mini is insanely cheap for this).

The Architecture

GitHub Event → Filter → AI Classifier → Parse → Priority Router
                                                      ↓
                                         Critical → #devops-critical + Linear
                                         High → #devops-alerts + Linear
                                         Medium/Low → #devops-inbox

The AI Classifier Prompt

This is the core of the workflow. The prompt is engineered to return consistent JSON:

You are a DevOps triage assistant. Classify this GitHub event
and respond in JSON format ONLY:

{
  "priority": "critical|high|medium|low",
  "category": "bug|feature|security|docs|infra|test",
  "summary": "one line summary",
  "suggested_owner": "team or person based on context",
  "action_needed": "review|merge|fix|discuss|close"
}

I use temperature=0.1 for consistency and maxTokens=200 to keep it fast.

The Priority Router

A simple switch node that splits traffic:

• Critical + High → Goes to alert channels AND creates a ticket in your project management tool
• Medium + Low → Goes to a general inbox channel (no ticket noise)

This alone saved us from “ticket fatigue” — only genuinely important stuff creates work items.

Why n8n?

I evaluated several options:

n8n won because:

• Self-hosted = no per-execution costs (only the OpenAI API call)
• Visual workflow makes it easy to modify routing rules
• Built-in nodes for Slack, Linear, Jira, GitHub — no custom API code
• Code node for the JSON parsing fallback

Real Numbers

After running this for 2 weeks on a repo with ~50 events/day:

• Time saved: ~35 minutes/day on manual triage
• AI cost: $0.04/month (yes, four cents)
• Accuracy: ~92% correct priority classification
• False critical rate: ~3% (acceptable — better to over-alert than miss)

The Fallback

What if GPT returns garbage? The Parse node has a try/catch:

try {
  const parsed = JSON.parse(raw);
  return [{ json: parsed }];
} catch(e) {
  return [{ json: {
    priority: 'medium',
    category: 'unknown',
    summary: raw.substring(0, 100),
    action_needed: 'review'
  }}];
}

Worst case, it defaults to medium priority and routes to the general inbox. No event gets lost.

Setup in 5 Minutes

1. Import the JSON workflow into n8n
2. Add credentials: GitHub webhook, OpenAI API key, Slack bot token
3. (Optional) Add Linear or Jira credentials
4. Set your Slack channel names in the env variables
5. Activate

That’s it. No custom code to maintain, no infrastructure to manage beyond your n8n instance.

Get It

I packaged this as a ready-to-import n8n workflow template: DevOps Inbox Zero on Gumroad

It includes the complete JSON workflow file plus documentation. Import, configure 3 credentials, and you’re done.

What’s your current GitHub triage process? I’d love to hear how other teams handle this. Drop a comment below.

I’ve been trying to build a whiteboard app for almost a year. I did it because of a couple of reasons: I wanted to try out skia. I wanted to try all the trendy react libraries like Zustand and TanStack Query. And, I wanted to get better at backend development with Go.

Okay, to be fair, last one doesn’t sound like what you’d expect for a frontend-heavy project. But that is exactly what started all of this!

I didn’t want to build a basic CRUD backend app. I wanted to build something real, something challenging. A backend for a collaborative whiteboard seemed like a great idea. So, I got to work. I implemented basic auth, classic CRUD endpoints, messaging with NATS JetStream, observability, and finally, WebSocket messaging.

Eventually, Postman just didn’t feel like enough to test my app. And then I thought building a minimal frontend app would be a good idea because I like to see what I’m building. So I started building it. After a couple of days, it was done. Then I decided to try out frontend tools I’d been wanting to try. I added Zustand for store management, TanStack Query to handle data fetching/updating.

Then, I wondered how good Skia’s CanvasKit really was. CanvasKit is a WebAssembly port of the Skia 2D graphics engine which powers Chrome and Flutter. It lets you render high performance graphics right in the browser. I wanted to try it out, so I created a board page and rendered a grid. Following that, I started rendering some basic shapes like rectangle, ellipse, triangle. Then came pen drawings and texts.

Just like that, my so-called backend project became a frontend project. All my curiosity shifted, so I took it further. I made the canvas interactive: selecting shapes, moving them, resizing them. Then of course, I integrated it with my backend. I started handling websocket messages to save shapes in the db and update them real-time. I made it collaborative: backend broadcasted updates to the other clients on the same board, and those clients listened to the messages to update their local shape data.

Looking back, I probably could have finished this project right there. But every time I thought I was done, I kept finding one more thing to add, one more thing to try. I added rich text support, the ability to add text inside shapes, a sub-toolbar to modify background colors, text colors, border thickness, etc. Then I added lines, sticky notes, images… and it became a real whiteboard app.

I’m really happy with how it turned out. I learned a lot along the way. Maybe I didn’t learn how to stick to a plan, but anyway, I have a whiteboard app now. And it’s something I genuinely enjoyed building, most of the time.

To make it as accessible as possible, I recently added a standalone mode. The frontend no longer relies on a backend. It uses browser’s IndexedDB to store the data locally. If you want to play around with it: https://eskiz.io. If you want to check source code: https://github.com/umtdemr/eskiz

Is it done? I don’t think so. I can think of a lot of features to add, like retina display, frames, AI integration but not sure if the world can handle another whiteboard app.

Flat design is functional, but depth makes an interface truly memorable. This updated collection aggregates high-performance solutions designed to add spatial interaction to your web projects.

Unlike standard flat styling, CSS 3D transforms allow developers to bridge the gap between basic layouts and highly immersive experiences. The best part? You can achieve this without the massive performance overhead of WebGL libraries. By using these curated snippets, you guarantee efficient, lightweight code rather than spending hours building complex physics engines from scratch.

Interactive 3D Flip Book Gallery. This is an Interactive 3D Flip Book Gallery. It simulates a physical book structure where each element acts as a double-sided page. Its function is to showcase images through spatial depth, replacing standard flat carousels with a tactile flipping mechanic.

Interactive 3D Coverflow Gallery. This is an Interactive 3D Coverflow Gallery. It organizes visual media into a spatial environment. Its function is to replace flat grids with depth-based navigation, using mathematical inverse transformations to zoom into selected items seamlessly.

Smooth 3D Scroll-Driven Reveal. This is a Smooth 3D Scroll-Driven Reveal. It replaces the native scroll behavior with a custom, momentum-based scrolling engine that orchestrates complex 3D transforms. Its function is to create a gallery experience where images feel weightless, tilting and translating in 3D space based on their velocity and position relative to the viewport.

Liquid Filling Heart Interaction. This is a Liquid Filling Heart Interaction. It visualizes a “pumping” effect by animating a fluid level inside a heart-shaped container. Its function is to serve as a playful, interactive state indicator - like a “like” button or health bar - that responds to user clicks with a simulated hydraulic fill and a 3D perspective jolt.

Immersive 3D Tilt Card Modal. We accept flatness in web interfaces as a constraint, but it is merely a habit. This component breaks the fourth wall, transforming a static modal into a tangible, digital artifact. By coupling mouse physics with deep perspective, we create an interaction that feels less like clicking a link and more like holding a rare collectable.

Isometric Floating Layers Diagram. This Isometric Floating Layers Diagram is a visually striking React component designed to represent architectural stacks or multi-tiered systems. By combining SVG geometry with CSS animations, it creates a lightweight 3D isometric illusion. Each layer floats rhythmically, enhanced by vibrant gradients and drop shadows, making it perfect for landing pages explaining software infrastructure or service tiers.

3D Parallax Card Slider. This 3D Parallax Card Slider brings a tangible, high-fidelity feel to web galleries. It goes beyond simple sliding by implementing a physics-based tilt effect that reacts to mouse movement, giving each card weight and depth. The background adapts seamlessly to the active slide, creating an immersive atmosphere perfect for luxury travel sites or premium portfolios.

Flip-Disc Mechanical Checkbox. This Flip-Disc Mechanical Checkbox brings the satisfying, tactile physics of old-school airport information boards to the web. Instead of a simple tick, selecting an item triggers a 3D rotation of a mechanical disc, flipping it from a dark, inactive side to a glowing orange active side. This creates a high-contrast, industrial aesthetic perfect for system dashboards or retro-themed interfaces.

3D Rotating iOS Time Picker. This 3D Rotating iOS Time Picker recreates the tactile feel of native mobile controls on the web. It features three independently rotating wheels (Hours, Minutes, Meridiem) that snap into place with satisfying physics. The component leverages the cutting-edge Scroll-driven Animations API for buttery-smooth performance on supported browsers, while seamlessly falling back to GSAP for others. The 3D perspective creates a “drum” effect where numbers fade and rotate away as they leave the center view.

3D Tilt Mobile Navigation. This 3D Tilt Mobile Navigation concept adds a tactile, physical feel to mobile app menus. Unlike standard flat navigations, this component utilizes CSS perspective to “tilt” the entire menu bar towards the user’s touch point, simulating a floating surface. It pairs this effect with delightful SVG icon micro-interactions and a “fly-out” card transition for the content area, creating a highly polished, app-like experience on the web.

This post was inspired by a curated selection on FreeFrontend. The original version is available at: https://freefrontend.com/css-3d-transforms/

We are FlagoDNA.

Not a “Muslim version” of Google.
Not another Islamic app studio.
A developer lab building parallel digital infrastructure for the Ummah.

It started in 2020.

One developer. One mission.
Build tools that actually serve Muslim daily life.

Quran readers. Hadith collections. Prayer trackers.
One app at a time.

Then something happened.

60,000 downloads.
7,500 active users.
15+ apps shipped.

And one uncomfortable truth became clear:

A single app is not enough.

Our phones are not just tools anymore.
They are environments.
They shape attention. Habit. Character.

And right now, those environments are built
by people who do not share our values.

We decided to change that.

FlagoDNA is now building the foundation:

→ Muslim Launcher — a faith-first home screen
→ Muslim VPN — data sovereignty for the Ummah
→ Muslim AI — intelligence grounded in Islamic sources

Not add-ons.
Not plugins.
A foundation.

We build with four values:

Innovation. Push the boundary of what faith-tech can be.
Quality. Privacy-first. Performance-first. Always.
Collaboration. Open source where it matters.
Mlampah Ing Tresno. Walk with love. ❤️

This is our first post as FlagoDNA on DEV.

More coming — behind the builds, the decisions, the stack, the failures.

If you are a builder who cares about what technology does to people,
you are in the right place.

→ flagodna.com