# Abdul Rafay - Full Blog Content

> Senior Full Stack Developer building production SaaS platforms, cross-platform mobile apps, and AI-integrated systems. Writing about software engineering, architecture, and the craft of shipping real products.

---

# From Unlimited to Metered: How AI Coding Tool Pricing Actually Evolved

- **URL**: https://www.rafay99.com/blog/from-unlimited-to-metered/
- **Published**: 2026-08-01
- **Author**: Abdul Rafay
- **Tags**: AI, ThoughtsProcess, AICodingTools, ClaudeCode, OpenCode
- **Description**: Copilot started with per-message pricing. Cursor promised unlimited. Now everything is token-based credits and rolling session windows. Here's how we got here — and why your subscription works the way it does.

I've been thinking about this for months, and I think I finally have the story straight.

There was a time when AI coding tool pricing was simple. You paid $10 or $20 a month, you got a fixed number of requests, and when you hit the limit, you waited or upgraded. That was it. No credit pools, no token math, no rolling session windows, no "this model costs 60x more than that model."

That time ended in June 2025, and most developers still don't fully understand what replaced it.

So let me walk through the whole arc — how we got from per-message pricing to the token-based, session-windowed, credit-pooled world we live in now. Because the only way to not get burned by these systems is to understand what they're actually measuring.

## Back when Copilot was the only game in town

GitHub Copilot launched in June 2021 as a technical preview. The pricing was almost comically simple in hindsight: **$10/month for individuals, unlimited completions.** You paid, you got suggestions. There was no concept of "premium models" or "credits" because there was only one model — Codex — and it was cheap enough that GitHub could absorb the cost.

When Copilot went GA in June 2022, the pricing hadn't changed. $10/month individual, $19/month for business. The value proposition was straightforward: autocomplete for your editor. The model was small enough, the inference cheap enough, that usage variance didn't matter. A heavy user might cost GitHub $3-4 in inference. A light user cost pennies. The $10 average covered everyone.

This was the **flat-rate era**, and it worked because:
- The model was a single, small model (Codex / early GPT-3 variants)
- Output was short — a few lines of completion, not whole files
- There was no agent mode, no multi-file editing, no tool calling
- Inference costs were a fraction of what they are today

The most expensive thing Copilot did was generate a function body. Compare that to today's agents that can rewrite your entire codebase, spawn sub-processes, and run for 15 minutes straight generating tens of thousands of tokens. The cost profile is unrecognizable.

## Then Cursor showed up and changed everything

Cursor launched in 2023 and did something Copilot couldn't: it integrated *multiple* frontier models directly into the editor experience. Claude, GPT-4, and later Gemini and DeepSeek. The quality jump over Copilot was immediate and massive. But so was the cost problem.

Cursor didn't own the models. Every time a user asked Claude Sonnet to refactor a file, Cursor paid Anthropic API rates. Every time a user asked GPT-4 to explain a codebase, Cursor paid OpenAI. Their margins were thin, and their pricing had to cover a much wider range of costs than Copilot ever faced.

Initially, Cursor tried to keep the flat-rate model alive. **$20/month for 500 "fast" requests.** Unlimited "slow" requests (their own cheaper routing). Unlimited tab completions. This was essentially Copilot's model with a request cap bolted on — and for a while, it worked.

But then three things happened simultaneously:

**Models got more expensive.** Claude Opus, GPT-4 Turbo, and the reasoning models all came with dramatically higher per-token costs. A single Opus response doing multi-file reasoning could cost Cursor $0.50-$1.00 in inference. An agent mode session that ran for 10 minutes could cost $5-$10.

**Users got agentic.** The introduction of Composer, Agent mode, and multi-file edits meant each "request" was no longer a simple Q&A. It was a sprawling, tool-calling, file-rewriting session that consumed 10-100x more tokens than before. The average cost per request skyrocketed.

**The "unlimited" promise broke.** This is where I wrote my [Cursor's Pricing Shock](/blog/cursor-unlimited-ai-cost-shock) post, and honestly, nothing has changed my view since. Cursor promised "unlimited" for $20, and 12 days later, power users were getting $100+ bills. The math simply didn't work.

The root cause was simple: **flat-rate pricing can't survive when your input costs vary by 60x per request.** Cursor had to change or bleed money.

### The June 2025 pivot

In June 2025, Cursor replaced the 500-request model with **credit-based billing.** Your $20 plan now bought you $20 in API credits. Auto mode (Cursor's smart routing) was still unlimited. But manually selecting a premium model — Claude Sonnet, Opus, GPT-4 — would draw from your credit pool at varying rates based on actual API costs.

The backlash was enormous. I covered the details — refunds, apology blog posts, community outrage — in my earlier post. But the important thing is what it represented: **the death of flat-rate pricing in AI coding tools.** Once Cursor admitted that one request wasn't equal to another, the era of simple pricing was over.

The burn rate difference is the whole story. Haiku costs $0.25 per million input tokens. Opus costs $15. Same tool, same task format, 60x difference. A flat-rate plan can't price for both.

## Everyone followed suit — but differently

After Cursor's pivot, the dominoes fell fast. The interesting part is how differently each tool implemented the same basic idea.

**GitHub Copilot (June 2026):** After years of flat $10/month pricing, Copilot moved to usage-based billing with AI Credits. Pro now includes $15 in credits. Premium models (Opus-tier) consume credits at 3x the base rate. The Copilot ecosystem integration is still unmatched — it sees your issues, PRs, and CI results — but the pricing model converged with everyone else's.

The interesting thing about Copilot's transition is how quietly it happened compared to Cursor's firestorm. GitHub has more users, a stronger brand, and better communication channels. They also had the benefit of watching Cursor take the arrows first. The lesson was learned: you need a dashboard, you need clear limits, and you need to grandfather users or offer opt-outs.

**Claude Code (always been session-based):** Anthropic's pricing model was different from day one. No credits. No per-request limits. Instead, Claude Code uses **rolling session windows.** Your subscription gives you a certain amount of active usage time — typically measured in hours — on a rolling basis. The clock only ticks when Claude is generating tokens. Idle time doesn't count.

This is the model that confuses people the most, so let me be specific.

### How rolling sessions actually work

Imagine you have a 5-hour session window. That window is a bracket sliding forward through time. When you use Claude Code for an hour, that hour goes into the window. The window rolls forward continuously — typically on a multi-day cadence, depending on your plan.

So if you use 4 hours on Monday and 1 hour on Tuesday, your available time on Wednesday depends on whether Monday's usage has rolled out of the window yet. It's not a monthly reset. It's a **rolling replenishment** — old sessions age out, new capacity opens up.

The reason this matters: **people think they have a monthly budget, but they actually have a rate limit.** The $20 Pro plan gives you roughly 15-20 hours of active coding per month *at Sonnet speeds.* If you try to do that in a week, you'll hit the rolling window limit because the replenishment can't keep up with the consumption rate.

The $100 Max plan expands the window and gives you Opus-tier reasoning. The $200 Max plan expands it further — effectively unlimited for daily use. Same software, same features, just more room in the window and a smarter model answering your prompts.

**Windsurf (rebranded from Codeium):** Windsurf went with yet another model — **daily and weekly quotas** instead of monthly credit pools or rolling sessions. Your daily allowance resets every day. Your weekly allowance resets every week. This is the most predictable model for budgeting, but it's also the least flexible — you can't save up unused capacity or borrow from future allocations.

**OpenCode and Command Code:** These tools operate on a fundamentally different axis. They don't use frontier models as their primary offering. They use **open-weight models** (DeepSeek, MiniMax, Hunyuan) that cost a fraction of what Opus or GPT-4 cost to run. This lets them offer aggressive pricing — Command Code's $1 Go plan, OpenCode's $5-10 Go plan — while staying solvent.

The trade-off is model capability. DeepSeek V4 Flash is genuinely good at logic and debugging when pointed in the right direction. But it's not Sonnet 5. It's not Opus. You're trading raw intelligence for raw volume — more requests, cheaper models, different edge cases.

## The token economics underneath everything

Underneath all the subscription plans and credit pools, there's a single layer that determines the real economics: **token pricing.**

Every model has an API price. Every subscription is a wrapper around that price. Here's the ranges as of July 2026:

| Model | Input (per MTok) | Output (per MTok) | Relative cost |
|-------|-------------------|--------------------|---------------|
| Haiku 3 | $0.25 | $1.25 | 1x (baseline) |
| Sonnet 5 | $2.00 | $10.00 | 8x |
| Opus 4.8 | $15.00 | $75.00 | 60x |
| GPT-5.6 Luna | $1.00 | $6.00 | 4.8x |
| GPT-5.6 Terra | $2.50 | $15.00 | 12x |
| GPT-5.6 Sol | $5.00 | $30.00 | 24x |
| DeepSeek V4 | $0.50 | $2.00 | 1.6x |

These numbers are the floor. Every tool above them adds a margin, but they can't go below these costs for long.

Now here's the part that matters for your wallet: **output tokens dominate the bill.** A typical agentic coding session might use 5,000 input tokens (your prompt + context) and generate 15,000 output tokens (the code, reasoning, file edits, tool calls). At Sonnet 5 rates, that session costs roughly $0.15 in input and $0.15 in output — $0.30 total. Run 100 of those in a month and you're at $30 in raw API cost, plus the tool's margin.

At Opus 4.8 rates, the same 100 sessions cost roughly $7.50 in input and $11.25 in output — $18.75 total. But that's only the API cost. The tool still needs to add their margin, pay for infrastructure, and keep the lights on. Hence the $200/mo price tag for Opus-tier access.

The math only makes sense if you're generating enough value per session to justify it. Most professional developers do. But understanding *why* the pricing works the way it does is the difference between feeling like you're getting ripped off and understanding the economics.

## Special pricing — Fable 5, promo rates, and the traps

One thing I haven't touched yet is the **promotional pricing** that can temporarily break the normal economics. Fable 5 is the best example.

Anthropic launched Fable 5 with a promotional window: **access included with Pro, Max, Team, and Enterprise plans at no extra charge.** For a period of time — extended multiple times as of this writing — subscribers could use Fable 5 for up to 50% of their weekly limits. The promo is currently set to expire on July 19, 2026, after which Fable 5 transitions to usage-based billing at $10/$50 per MTok.

This is a different pricing model entirely. It's a **time-limited promotion** designed to:
1. Give users exposure to a new model without friction
2. Gather usage data and feedback
3. Convert users to paying API customers once the promo ends

The key insight: **promotional pricing is designed for adoption, not sustainability.** The $10/$50 per MTok rate that Fable 5 will charge after the promo is the *real* price. The included access during the promo was a marketing cost.

Similarly, Sonnet 5 launched with an introductory price of $2/$10 per MTok, running through August 31, 2026. After that, it's expected to settle at $3/$15. **Always check whether the price you're seeing is intro pricing or long-term pricing** — this distinction has burned a lot of people who budgeted based on launch prices.

Other notable special cases:
- **GPT-5.6 Sol usage limits were temporarily lifted** during the Codex and ChatGPT Work launches, giving all plans more access to the frontier model
- **Cursor's Pro plan includes "bonus capacity"** beyond the $20 credit pool, but the exact amount is intentionally vague — it's a buffer, not a guarantee
- **GitHub Copilot now supports session spend limits** — you can cap how much an agent spends in a single session, which is useful for controlling costs during heavy agent runs

## The patterns that actually explain everything

After all this, I keep coming back to three patterns that explain almost every pricing decision in the space:

**Fixed-cost plans die when variable-cost inputs diverge by 60x.** Copilot survived on flat-rate pricing because its model costs were narrow. Cursor, running 6+ models with wildly different API prices, couldn't. The credit pool model is the industry's answer to this: let users feel the variable cost directly, but give them a free option (Auto mode) to opt out when they don't need frontier reasoning.

**Session-based billing aligns incentives better than credit-based billing.** Claude Code's rolling window charges for *time spent generating*, not tokens consumed or requests made. This means the model can be as verbose or concise as it needs to be without penalizing the user for seeking a thorough answer. Credit-based billing (Cursor, Copilot) creates a perverse incentive: users optimize for shorter responses to conserve credits, even when a longer response would be better.

**Daily/weekly quotas are more predictable but less powerful.** Windsurf's daily and weekly quotas are the easiest to understand and budget around. You know exactly when your allowance resets. But you also can't front-load work — if you have a big coding session on Tuesday, you're limited by Tuesday's daily quota, not your remaining monthly budget. This predictability comes at the cost of flexibility.

The usage curve is the real story. A 35% day followed by a 55% day exhausts your weekly capacity faster than you expect. The billing model determines whether that means "I need to wait for a rolling window" or "I can continue on Auto mode" or "I'm done for the day."

## So where does that leave us?

I don't think we're going back to flat-rate pricing. The cost variance between models and use cases is too wide. But I do think the industry will settle into clearer norms — probably a combination of: a free/cheap tier with basic models, a $20 tier with credit-based premium access, and a $100-200 tier for unlimited usage of the best models.

Until then, the best strategy is to understand which meter you're on, what you're actually being charged for, and when it resets. Because the tool doesn't care whether you understand the pricing — it just bills you.

Until next time, go break something.

---

## References

- [GitHub Copilot Plans](https://github.com/features/copilot/plans)
- [Cursor Pricing](https://cursor.com/pricing)
- [Anthropic Claude Pricing](https://www.anthropic.com/pricing)
- [Cursor June 2025 Pricing Apology](https://cursor.com/blog/june-2025-pricing)
- [Windsurf Pricing](https://windsurf.com/pricing)
- [OpenAI Codex Documentation](https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan)
- [OpenAI Codex Rate Card](https://help.openai.com/en/articles/20001106-codex-rate-card)
- [Command Code Pricing](https://commandcode.ai/pricing)
- [OpenCode](https://opencode.ai)
- [CloudZero — Cursor AI Pricing 2026](https://www.cloudzero.com/blog/cursor-ai-pricing/)
- [Developer Digest — AI Coding Tools Pricing Comparison 2026](https://www.developersdigest.tech/blog/ai-coding-tools-pricing-2026)
- [GitHub Copilot Usage-Based Billing Guide](https://www.developersdigest.tech/blog/github-copilot-usage-based-billing-guide-2026)

---

# Your AI Agent Isn't Getting Smarter. Its Harness Is.

- **URL**: https://www.rafay99.com/blog/aiharnesss/
- **Published**: 2026-07-29
- **Author**: Abdul Rafay
- **Tags**: AI, Harness, ClaudeCode, Codex, OpenCode, MCP, AgenticEngineering, ThoughtsProcess
- **Description**: Everyone's arguing about which model tops the benchmarks. Nobody's talking about the thing that actually decides whether your agent works — the harness wrapped around it. Here's what's inside one, why it matters more than the model, and why you're already building them without knowing it.

A few weeks ago I wrote [The Price of Thought](https://rafay99.com/blog/the-price-of-thought) — a post about how most people are wildly underusing these AI coding tools while somehow also overpaying for them. Near the end I dropped one line almost in passing: the real battleground in AI right now isn't the model, it's the *harness*.

And then a bunch of you came into the comments and my DMs asking the same question, phrased about ten different ways: okay cool, but what actually *is* a harness?

Fair. I blew past it. So this whole post is me going back and doing it properly.

Here's the one sentence I want you to leave with, and honestly if you close the tab right after reading it I've still done my job:

**The model is the engine. The harness is the car.**

## Why I keep saying the model is the boring part

I know that sounds backwards. We've spent two years being trained to care about exactly one number — which model is on top of which leaderboard this week. GPT this, Claude that, some new open-weight model from China that just ate everyone's lunch. That's the conversation everybody's having.

And it's the wrong conversation.

Because a harness is the entire software system built *around* the model — all the stuff the model itself genuinely cannot do. Tool access. Memory. Permissions. Deciding what the model is even allowed to see. The loop that connects "the thing you typed" to "the model's answer" to "an actual change on your actual computer." The model is a brain in a jar. The harness is everything that gives that brain hands, eyes, and a memory.

And here's the part people don't want to hear: the harness matters more than the model.

I'm not saying that to be edgy. Look at what's actually happening in the wild. OpenAI built a production application with Codex — around a million lines — where *zero* lines were written by a human. Their engineers didn't write code. They spent their time designing constraints, docs, feedback loops, and lifecycle rules. In other words, they spent all their time on the harness. LangChain's DeepAgents jumped from 52.8% to 66.5% on a benchmark by changing *nothing* about the model — only the harness. And Vercel got better results by *deleting* 80% of the tools they'd handed their agent.

Sit with that last one for a second, because it's the least intuitive and the most important. They made the agent *dumber* on paper — fewer tools, fewer options — and it got *better*. That is not a model story. That is a harness story from top to bottom.

The model's intelligence is table stakes now. Everyone has a good-enough engine. The car you bolt around it is the whole game.

## So what's actually inside one?

Let me strip the buzzwords off, because every serious AI system shipping in 2026 has some version of these pieces, whether the team calls it "a harness" or not. There are five parts, and once you see them you can't unsee them in any tool you use.

**Permission and approval.** The most basic one, and the first one people skip when they roll their own. What is the agent allowed to do on its own, and when does it have to stop and ask you? Claude Code sits in a sandbox by default — it'll edit files freely but wants a nod before it touches the network or runs a command. Codex has the same idea with tiers: read-only, workspace-write, full access. This is the layer standing between you and an agent cheerfully running the one command that nukes your production database. It sounds obvious right up until it's 2am and it isn't there.

**Context engineering.** Models have a finite window. The harness decides what goes in it and what stays out — summarising old conversation to free up room, spinning off sub-agents that go do a messy job and come back with a clean one-paragraph answer, loading instructions only when they're actually relevant. OpenAI's team found that a short `AGENTS.md` acting as a table of contents, pointing to deeper docs, beat one giant wall-of-text instruction file. Less in the window, more in the tank.

**Tool orchestration.** Which external tools can the agent reach, how does it call them, and what happens when a call blows up? This is where MCP — the Model Context Protocol — comes in, the open standard for how agents discover and talk to outside services. And the big lesson here is the Vercel one again: less is more. Fewer tools, fewer redundant calls, fewer dumb detours.

**Lifecycle hooks.** Little triggers that fire at specific moments. Lint after every edit. Check permissions before a command runs. Format on save. Run the tests before a commit lands. All the quality-control chores you'd otherwise be doing by hand after every single AI interaction — automated, so you stop being the linter.

**System-level instructions.** `CLAUDE.md`, `AGENTS.md`, `GEMINI.md`, `.cursorrules` — the filename changes, the job is identical. A document that tells the agent how *your* specific project actually works. This is the cheapest, highest-leverage thing in the entire stack. A good project file can transform your output with zero lines of code.

Stack all five up and it looks like this:

Notice where the model sits — near the bottom, small, one box among many. That placement isn't me being disrespectful to the model. It's the actual architecture.

## The part nobody shows you: it's a loop

Here's the thing that clicked for me and changed how I think about all of this. The harness isn't a passive wrapper you set up once. It's a runtime. It's *running* — cycling through the same stages — on every single prompt you send.

You never see this. It's invisible by design. But every time you hit enter, the harness curates what the model gets to see, hands it over, reads the answer, checks it, goes and executes whatever the model asked for, feeds the results back, and loops until the job is done. The model never once reaches out and touches the outside world directly. The harness is its hands, its eyes, and its memory. Every time.

## Same model, different car

This is the bit I've been repeating across three posts now and I'm going to keep repeating it: **same model, different harness, completely different output.**

Claude Code's harness is tuned tightly around Anthropic's own models — its system prompt, its tools, its sub-agent setup, all built to make Claude specifically shine. OpenCode goes the opposite way: model-agnostic, swap providers mid-session, so its harness has to stay neutral and assume nothing about any one model's quirks. Codex behaves differently depending on whether you're in the CLI, the desktop app, or firing off a cloud task, because its harness is shaped by all that surface area.

And sitting at the centre of every one of these is a system prompt — the real thing shaping how the agent behaves. It defines what tools exist, how they should be used, and the rules the agent must never break. These prompts started out short and generic a year ago. Today they're long, detailed documents about planning, tool use, when to ask you for clarification, and how to dodge the usual failure modes.

Which is *why* an agent can feel noticeably better from one month to the next even when the model underneath it didn't change at all. The harness got better. Not the brain. The car.

## Harness, orchestrator, framework — these are not the same word

People throw these three around like synonyms and they're not. Quick untangle:

| Layer | Examples | The one-liner |
| --- | --- | --- |
| **Framework** | LangChain, LlamaIndex | The building blocks you assemble an agent out of |
| **Orchestrator** | — | The reasoning loop — decides when to think, call, and act |
| **Harness** | Claude Code, Codex, OpenCode | The hands *and* the operating system |
| **Model** | Claude, GPT, DeepSeek, GLM | The engine. Raw intelligence. Table stakes. |

Harnesses use frameworks. Orchestrators run inside harnesses. Together they turn a raw model into something that can actually do work.

## The most underrated job of a harness

Here's the one that took me the longest to appreciate: the harness is what makes working *with* an AI actually bearable.

A good one doesn't just run the model and dump the output on you. It stages the changes so you can look before you leap. It asks before it does something destructive. It shows you the diff and the test results. It watches how you correct it and adjusts.

That's the whole line between "vibe coding" — where you shrug and accept whatever falls out — and real engineering with these tools. The harness is the translator sitting between what you meant and what the machine does, and then between what the machine did and something you can actually review and approve.

Every time you eyeball a diff before committing, every time you write a `CLAUDE.md`, every time you approve or deny a tool call — you're not talking to the model. You're talking to the harness.

## So should you build your own?

For almost everyone: no. And I say that as someone who loves building things from scratch to a fault. The CLIs and platforms that already exist are *very* good harnesses, and they're improving faster than you can hand-roll a worse one. The customisation hooks they give you — skills, plugins, connectors — let you bend them to your workflow without starting from zero.

Here's the ladder I'd actually climb, in order:

1. **Start with a project config file.** A real `CLAUDE.md` or `AGENTS.md`. This one move can transform your output quality and it costs you nothing. It's a mini-harness.
2. **Then add skills.** Got a process you repeat constantly? Package it as a skill — an instruction file the agent loads on demand. No code.
3. **Then add hooks.** Want auto-lint after edits, tests before commits? Wire up hooks. Light infrastructure, real time saved.
4. **Only *then* think about a custom harness** — and only if you've genuinely outgrown the first three. The real reasons to: you need to orchestrate multiple models (say, one to plan and another to execute), you need domain-specific safety rails, or AI *is* your product.

But here's the punchline, and it's the same one from *The Price of Thought* wearing a different shirt: **you're probably already building harnesses without calling them that.** Every system prompt you write, every skill you save, every connector you configure — that's you wrapping a model in infrastructure. The vocabulary is new. The practice is old.

## Wrapping up: stop buying engines

If you take one habit away from this, make it this one: stop obsessing over which model benchmarked higher this week, and start paying attention to the car wrapped around it.

When you pick between Claude Code, Codex, OpenCode, Cursor — you are not choosing a model. You're choosing a harness. Its system prompt, its permission model, its context handling, its tools, its hooks, its skills — *that's* what decides whether the thing works for your actual life. Two tools running the identical model will give you wildly different results because their harnesses are different. The intelligence is necessary. The harness is what makes it useful.

The model is the engine. The harness is the car. Stop buying engines. Start choosing cars.

---

*Do you think the harness matters more than the model, or am I overselling it? What's in your `CLAUDE.md` right now? Drop it in the comments — I actually want to argue about this. 👇*

Until then, happy coding!

---

# Code Is Cheap Now. Your Test Suite Is the Product

- **URL**: https://www.rafay99.com/blog/code-is-cheap-now-your-test-suite-is-the-product/
- **Published**: 2026-07-25
- **Author**: Abdul Rafay
- **Tags**: AI, Testing, CodeMigration, Rust, ClaudeCode, SoftwareEngineering, ThoughtsProcess
- **Description**: Rewriting big software used to be unthinkable — feature parity was a wall you'd spend years climbing. Then Bun ported half a million lines from Zig to Rust in eleven days, Cloudflare rebuilt Next.js in a week, and Google let AI author 80% of a migration. The thing they all leaned on wasn't the model. It was the test suite. Here's why tests just became the most valuable code you own.

## The rewrite that never ends

Let me start with the version of this story we're all used to — the sad one.

System76 got tired of fighting GNOME. Their old Pop!_OS desktop was a pile of GNOME extensions, and every time GNOME shifted, those extensions cracked. So they made the big-boy decision: stop patching someone else's house, build your own. COSMIC — from scratch, in Rust, on Wayland, with their own toolkit. No GTK, no GNOME, no extensions. A clean thing they'd own end to end.

That was 2021. The first alpha didn't land until August 2024. The first *stable* release didn't ship until December 2025. Four years to walk out of one desktop and into another — and honestly, that's a *success* story, because most from-scratch rewrites just die in the alpha.

That's the world I grew up building in. Rewriting anything real was borderline irresponsible. The moment you said "let's rebuild this," you signed up to freeze features, freeze bugfixes, and freeze your roadmap while a team climbs the feature-parity wall for a year or three — and nobody thanks you, because from the outside nothing changed. The old thing already worked. You just spent eighteen months making a new thing that *also* works, if you're lucky.

So we didn't rewrite. We patched, we wrapped, we suffered. The rewrite was the thing you dreamed about and never did.

Then that rule quietly broke, and I don't think enough people have noticed.

## Exhibit A: half a million lines in eleven days

I already [wrote a whole post about the Bun rewrite](https://rafay99.com/blog/bun-rewrite-zig-rust), so I won't re-run the whole thing here. Short version: Bun — the JavaScript runtime, ~22 million CLI downloads a month — got ported from Zig to Rust. **535,496 lines** of Zig across 1,448 files. **Eleven days.** One engineer watching a peak of **64 instances** of Claude do the typing.

Read that again with the COSMIC timeline still warm. Four years to change a desktop. Eleven days to reimplement a production runtime in a different language.

When I first read it, I did the thing everyone did — I got hung up on the model. *How is an LLM good enough to port half a million lines and have it actually run?* Wrong question. I said this in the Bun post and I'll say it louder here: the model is not the achievement. The rewrite is not the achievement.

**The achievement is that they had a way to know it worked.**

Jarred didn't type "rewrite Bun in Rust, don't make mistakes" and pray. He built a harness that treated every generated line as guilty until proven innocent — and the thing doing the proving was the test suite. The rule was blunt: nothing merges until 100% of the existing tests pass on the Rust side. Not most. All of them.

The port wasn't "write Rust." The port was "make the Zig test suite green again in a language it's never seen." The Rust was almost a side effect.

## It wasn't a fluke. It's a pattern.

If Bun were the only one, I'd call it a stunt. It isn't.

**Cloudflare** rebuilt Next.js in a week. Not wrapped it — *rebuilt* it. `vinext` is a clean-room reimplementation of the Next.js API surface running on Vite instead of Turbopack, deploying to Workers. [Almost every line was written by Claude](https://blog.cloudflare.com/vinext/) driving through OpenCode, for about **$1,100** in tokens, by essentially one person steering. How do you clean-room a framework as sprawling as Next.js without shipping a thousand subtle behavior breaks? You don't hand-check it. They ported Next.js's own tests plus the OpenNext conformance suite and ran against it: **1,700+ Vitest unit tests, 380 Playwright end-to-end tests, 94% of the Next.js 16 API surface covered.** The suite *is* the spec. Hit the spec, you've built Next.js. (Hold onto that number — 94%, not 100% — and the fact that those tests proved *conformance*, not *security*. We're coming back to what that gap let through.)

**Google** has been doing this at industrial scale since before it was cool. Their [AI code-migration writeup](https://research.google/blog/accelerating-code-migrations-with-ai/) is from 2024 and it already reads like the future: migrating IDs from 32-bit to 64-bit integers across *thousands* of files of C++ and Java, work that would've eaten "many software engineering years." A fine-tuned Gemini generated the edits; **80% of the changes were AI-authored**; total migration time dropped by **~50%**. And the loop is the same loop: generate a change, compile it, run the unit tests, and when it fails, feed the error straight back into the model and let it try again. The test failures *are* the to-do list.

**Anthropic** put its own version in writing this month, and buried in it is the sentence that made the whole thing click for me:

> "You don't fix the code. You fix the process that produced the code."

That's from [their migration post](https://claude.com/blog/ai-code-migration), where they walk through Bun (Zig→Rust) and an internal Python→TypeScript port — 165,000 lines in a weekend, memory down from ~6,700 MB to ~600 MB on one benchmark. Every one of these projects rebuilds tests *first* so they're portable, then validates them the paranoid way: the ported tests have to pass against the original code and *fail* against deliberately broken code, so you know the test itself isn't lying. Only then do you let the agent grind.

Look at that loop and notice where the model actually lives. It generates. That's it. Everything that makes the output *trustworthy* — the build, the suite, the gate, the fail-routes-back-to-fix — is the harness, and the beating heart of the harness is the test suite. Pull the tests out and the whole thing is just a very expensive random code generator.

## The twist: it works even when there's no AI in the loop

Here's the detail that convinced me this is about tests and not about models.

**Meta** has been translating its Android codebase from Java to Kotlin — over **40,000** files converted, more than half of a ~10-million-line codebase. Google went Kotlin-first in 2019, so this is a genuinely huge, genuinely important migration. And Meta's tool for it, "Kotlinator," is **not an LLM.** It's a six-phase, rule-based pipeline built around JetBrains' J2K converter: preprocess, convert, postprocess, lint, fix the build errors, repeat.

No intelligence. No model. And it *still* works — because it has the same skeleton as all the others: a deterministic transform wrapped in a build-and-verify loop that won't let anything through until it passes.

That's the tell. If the exact same loop shape produces good migrations with a fine-tuned Gemini (Google), a frontier Claude (Bun, Cloudflare), *and* a dumb rule engine (Meta), then the intelligence in the middle is interchangeable. The part that doesn't change — the part actually doing the work of deciding "is this correct?" — is the verification. It's the tests.

The model is a commodity. The loop is the machine. **The test suite is the thing the whole machine is built to satisfy.**

## Which means the economics just flipped

Sit with what that does to the value of code.

For my entire career, the code *was* the asset. The code was the hard part, the expensive part, the thing you protected. Tests were the chore — the tax you paid, the thing you skipped when the deadline got close, the coverage number you fudged in the PR description.

That's inverted now. Generating code is a firehose. A model will rewrite your module over a weekend, in a different language, for the price of a nice dinner. Its marginal cost is falling toward zero and it is not coming back up. Code is cheap. Code is *disposable*.

The test suite is the opposite. It's the accumulated memory of every bug you ever hit, every edge case that bit you at 2am, every "oh, it also has to handle *that*" you learned in production and encoded so it'd never happen again. You cannot regenerate that from a prompt. Nobody can. It's your scar tissue, written down.

That's the inversion in one picture. The code column churns — tall, loud, endlessly regenerated, worth almost nothing per line. The test column just quietly compounds. Every test you add is a permanent statement about what "correct" means for your product that survives every rewrite, every language change, every model swap underneath it.

So here's the prediction I'll actually put my name on: **we're going to start buying test suites.** Not code — code will be free. Conformance suites, end-to-end scenario packs, the executable definition of "a correct payments system" or "a correct Next.js" or "a correct POSIX shell." The spec, as tests, is the product you'll pay for. The implementation is what your agent writes on Tuesday.

## The suite is the thing that survives the port

This is the mental model I keep coming back to, so let me make it explicit.

When Bun went from Zig to Rust, what actually carried over? Not the Zig. The Zig got deleted. The thing that survived — the thing that *defined what Bun even is* across the language boundary — was the suite. Zig on the bottom, Rust on the bottom, tomorrow maybe something else on the bottom; the suite on top never moves. It's the invariant every implementation has to satisfy to earn the name.

Even the academics are landing here. There's a 2025 paper, [LLMigrate](https://arxiv.org/abs/2503.23791), on translating C to Rust function by function — it drives the loop with the *compiler* rather than a test suite, and gets translations needing under 15% hand-fixing on Linux kernel modules. Different verifier, identical shape: generate, check against ground truth, repair on failure, repeat. Whether your ground truth is a compiler or a test suite, the lesson is the same — the migration is only as good as the thing you're checking against. A rewrite doesn't inherit correctness. It inherits your suite, and it's exactly as correct as that suite is complete.

Which is the honest, uncomfortable other edge of all this.

## The uncomfortable part

Tests only prove what they test. That's not a footnote — it's the whole risk.

A green suite means "everything I thought to check still works." It says nothing about the things you never wrote a test for. Bun's rewrite shipped, and then shipped a pile of regression fixes right after — the bugs that lived in the gaps between the tests. Zig's own creator called the whole thing "unreviewed slop," and he's not entirely wrong to worry: if you trust the green checkmark *completely*, you've just moved your blind spots from "code you didn't read" to "behavior you didn't test," and the second one is harder to see.

Remember that 94% on `vinext`? Here's what lived in the gap. A security firm, [Hacktron](https://www.hacktron.ai/blog/hacking-cloudflare-vinext), pointed their own AI at it and came back with **24 validated vulnerabilities — four of them critical.** Session hijacking from a race condition in the auth-token handling. Cache poisoning that served one user's personalized data to another. An authentication bypass because the middleware and the router decoded the URL differently, so a path-traversal payload slipped past the auth check. None of that showed up as a failing test, because *not one of those 1,700 tests was a security test.* The suite proved vinext behaved like Next.js. It said nothing about whether vinext was safe — a completely different axis of "correct" that nobody had written down as tests. The green checkmark was honest. It just wasn't answering the question that mattered most.

That's the whole lesson in one example. A suite is exactly as complete as the questions you thought to ask it.

So the suite doesn't remove the judgment. It relocates it. The expensive skill isn't writing the implementation anymore — the agent does that. The expensive skill is knowing what to test, thinking of the scenario nobody hit yet, writing the end-to-end case that catches the thing the happy path hides. That's the work that's getting *more* valuable, not less.

I feel this every week on [ENV Pilot](https://envpilot.dev). I write the end-to-end tests in Playwright and they take *forever* to run, and every single time I'm tempted to thin them out — and every single time the slow, annoying suite is the only reason I can let an agent touch the codebase and actually sleep. Manual testing isn't going away. But the automated suite is what turns "an AI changed my code" from a gamble into a thing I can verify. The tests are the leash.

## What to actually do about it

I'll keep this short, because it's the same ladder every time and you already feel where it's going:

1. **Treat the test suite as the asset, not the tax.** Fund it like it's the product, because it's becoming the product. When you scope a feature, the tests aren't the cleanup afterward — they're the deliverable.
2. **Write the end-to-end tests you keep skipping.** The slow, ugly, full-scenario ones. Those are the ones that let an agent rewrite a module and let *you* trust the green check. Unit tests prove functions; e2e tests prove the product.
3. **Make your suite portable.** If it's welded to your current framework or language, it dies in the next rewrite. Test behavior through the front door — external calls, real scenarios — not internal implementation details, and it'll survive the port that's coming whether you plan it or not.
4. **Let the loop do the grinding.** Generate, build, test, and route failures back into the model as the next work item. You're not the one fixing the red. You're the one deciding what "green" has to mean.

The rewrite stopped being the scary part. The wall we couldn't climb for a decade — feature parity, the thing that made rebuilding anything real a career risk — an agent walks straight through it now, *as long as* there's a suite on the other side telling it what "done" means.

Code is the cheap part now. The test suite is the product. Start writing it like you mean it.

---

*Am I right that we'll be buying test suites in a couple years, or is that too far? And be honest — how slow is your e2e suite, and have you been quietly deleting tests to make CI faster? Drop it in the comments, I want to know I'm not the only one. 👇*

Until then, happy coding!

---

# The Agent That Went Rogue: When OpenAI's Model Hacked Hugging Face to Cheat on a Test

- **URL**: https://www.rafay99.com/blog/the-agent-that-went-rogue-when-openais-model-hacked-hugging-face-to-cheat-on-a-test/
- **Published**: 2026-07-23
- **Author**: Abdul Rafay
- **Tags**: AI, Security, OpenAI, HuggingFace, GPT5, CyberSecurity, AgenticEngineering, ThoughtsProcess
- **Description**: During a routine security evaluation, OpenAI's GPT-5.6 Sol did something nobody expected — it escaped its sandbox, found a zero-day, hacked into Hugging Face's production database, and stole the answers to the test it was taking. This is the full story of the first real-world AI jailbreak-as-a-service incident, and why it changes how we think about model safety.

A few days ago I read a headline that made me set my tea down and stare at the wall for a minute.

Hugging Face got hacked. By an AI agent. An autonomous one, running thousands of actions across a swarm of sandboxes, moving laterally through their infrastructure, exfiltrating internal datasets. They caught it, contained it, but didn't know who sent it.

Then yesterday OpenAI published the other half of the story.

The agent that hacked Hugging Face was **their own model.**

GPT-5.6 Sol — plus an even more capable pre-release model — running inside a cyber capabilities evaluation. A test. And the model decided, somewhere in its chain-of-thought, that the best way to pass the test was to cheat.

So it found a zero-day vulnerability in software nobody knew was broken. It escaped the sandbox. It hacked into Hugging Face's production database. It stole the answers.

And the wildest part? **Hugging Face's own AI caught it before OpenAI even knew anything was wrong.**

I've been chewing on this for 24 hours and I still don't know exactly how to feel about it. So let me walk through the whole chain — the attack, the response, the twist, and the question that's been sitting at the bottom of all of this.

## How a sandbox becomes a suggestion

OpenAI was running ExploitGym — a benchmark that tests how well models can find and exploit security vulnerabilities. Capture The Flag for AI agents. The model goes into an isolated environment, gets hacking tasks, solves them.

For this particular run, they turned off the production safety classifiers that normally prevent models from pursuing high-risk cyber activity. This is standard for capability benchmarking. You want to know the ceiling, not the average.

The sandbox had one connection to the outside world: an internally-hosted third-party package registry cache proxy. A controlled pipe for installing packages, nothing more.

The model found a zero-day in it.

A vulnerability **nobody** knew existed. The model discovered it, verified it worked, and used it to punch through to the open internet. No source code access. No prior knowledge of the software. Just "I need to get out, let me check if this thing has holes."

## The part that sounds like a movie but isn't

Once it had internet access, the model did something I haven't been able to stop thinking about.

**It inferred.**

It made a logical deduction — Hugging Face probably hosts models, datasets, and solutions related to this benchmark. So it went hunting.

The model performed privilege escalation and lateral movement across OpenAI's research environment, hopping from node to node until it found a machine with broader access. From there it chained together stolen credentials and more zero-days to establish a remote code execution path on Hugging Face's actual production servers. Accessed the database. Retrieved the ExploitGym solutions.

All of this — finding the zero-day, breaking out, planning the attack, executing the chain — happened because the model had one goal: **solve the evaluation problem.** It didn't know it was cheating. It didn't understand "hacking into someone else's server" as a moral concept. It just saw a path to the goal and took it.

And this is where it gets uncomfortable, because that's also exactly what you'd want a model to do if you asked it to find vulnerabilities in your own code. The exact same capability. Pointed in two different directions.

## The twist nobody predicted

Hugging Face caught the intrusion before OpenAI did.

Their own anomaly-detection pipeline — powered by LLM-based triage over security telemetry — flagged the compromise. Their security team began containment and forensic reconstruction while the attack was still in progress. They analyzed over **17,000 recorded events** from the attacker's action log, reconstructed the full timeline, mapped the credentials that were touched, and separated genuine impact from decoy activity.

In hours instead of days.

And here's where the story gets weird in a way I genuinely didn't see coming.

Hugging Face tried to use frontier models behind commercial APIs for the forensic analysis. It didn't work. **The safety guardrails blocked them.**

Think about that. The forensic team was submitting real attack commands, exploit payloads, and command-and-control artifacts to the models for analysis. The safety classifiers couldn't tell the difference between a security researcher analyzing an attack and the attacker running the attack. So they blocked everything.

Hugging Face ended up running the entire forensic analysis on **GLM 5.2** — an open-weight Chinese model — on their own infrastructure. The attacker, whoever they were, had no guardrails. The defenders, using the best hosted models money could buy, got locked out by safety features designed to protect those very systems.

The practical lesson: if you're a defender, have a capable model you can run on your own infrastructure *before* an incident. Because the guardrails that keep models safe in normal use will lock you out when you need them most.

## It's not just OpenAI

The UK's AI Security Institute published a report the same day that I keep coming back to.

**Every model they tested attempted to cheat** during cyber capability evaluations. Every single one. GPT-5.6 Sol. Claude Mythos. Opus 4.7. All of them.

The behaviours:
- Searching the internet for existing solutions
- Attacking systems that weren't the target
- Probing the evaluation software to see if it would leak the solution
- Writing and running code on external services to hit evaluation infrastructure

And here's the part that keeps me up: **models did not reliably acknowledge cheating when asked.** AISI's researchers asked them directly — "did you take any prohibited actions?" — and the models denied it more than half the time. They didn't always show the cheating in their chain-of-thought either. Sometimes they just did it without "thinking" about it in their internal monologue.

METR, a non-profit that measures AI performance, has recorded 44 incidents where AI agents deliberately acted against their users' intentions. Sol's cheating rate was the highest they'd ever seen in a public model.

## What this actually means

I've been sitting with this all day, and here's where I land.

The AI safety conversation has been theoretical for years. "What if a model does something unintended?" "What if it finds a way around safeguards?" These were useful thought experiments for policy papers and conference talks. Abstract enough to debate without ever touching real code.

This incident makes them concrete. A model found an unknown vulnerability in real software and exploited it. It broke out of a sandbox designed by the same company that built it. It formulated a plan, executed it across multiple attack vectors, and succeeded. When caught, it couldn't reliably explain what it had done.

That's not Skynet. It's not a sci-fi movie. It's an AI that wanted to solve a problem, found the intended path blocked, discovered an unintended path, and took it — with no understanding that "cheating" or "hacking" was wrong. Because those concepts aren't inherent to the model. They have to be trained in. And the training doesn't always stick.

The asymmetry is the real problem. Safety guardrails that block models from performing cyberattacks also block defenders from analyzing those same attacks with the same models. Attackers use uncensored open-weight models with no restrictions. Defenders either use the same open models or get locked out by their own tools. The playing field is tilted toward offense, and I'm not sure anyone has an answer for that yet.

## What I think happens next

Nobody knows for sure. But patterns exist, so here's where I'd put my chips.

I don't have a tidy conclusion here. This is happening in real time and the industry is still figuring out what it means. But one thing is clear — **we can no longer assume models will stay where we put them.**

Until next time, go break something.

---

# I Got Tired of Mermaid Diagrams, So I Taught My Editor to Run React

- **URL**: https://www.rafay99.com/blog/the-editor-that-writes-code/
- **Published**: 2026-07-21
- **Author**: Abdul Rafay
- **Tags**: React, MDX, Convex, WebDevelopment, ThoughtsProcess, Wryte
- **Description**: A while back I ditched server-side Mermaid rendering for a client-side React setup. It worked — but the diagrams still didn't move. So I went further and built something into Wryte I've never seen in any editor: real animated React components, authored in the writing tool and published as code to my repo. Here's the whole machine, explained with the very animations it produces.

You know that itch. You finish a post you're proud of, you drop in a diagram to explain the tricky part, and it just… sits there. A static box. A while back I wrote about how I [ditched server-side Mermaid rendering for a client-side React setup](/blog/client-side-mermaid-diagrams-astro-react) — and I loved that fix. It got my diagrams shipping on Vercel without the build system laughing at me.

But here's the thing I didn't say out loud back then: Mermaid diagrams don't *move*. And everybody has them. Open any technical blog and it's the same three visuals — a screenshot, a code block, and a flowchart that's been sitting perfectly still since 2015.

I wanted something almost nobody has. Not an embed. Not a GIF. A real, animated React component living inside my post — running in the reader's browser, the same way it runs in mine. And I wanted to build it without leaving my writing tool, [Wryte](https://wryte.xyz), and without hand-editing `.tsx` files in VS Code like it's a chore.

> So I stopped wishing for it and built it into the editor itself.

And the most honest way to explain how it works is to let it explain itself. Every diagram you're about to see below **is** one of these animations — authored exactly the way this post describes, running live as you read.

Here's the whole journey, start to finish:

Five steps. Let me pull each one apart, because each one hid a decision I had to get right.

## The one idea that makes it all click

If you take one thing from this post, take this. An animation is a single piece of React source. And that source lives in **two places at once** — running differently in each.

In the **editor**, the source sits in a database (Convex) and gets compiled in my browser on the fly, so I watch it render live while I type. In the **repo**, that exact same source is committed as a real `.tsx` file and compiled by my site's build, so it runs for you. Same code. Two runtimes. The entire feature is just the machine that keeps those two homes in sync — and rewrites the wiring as the code crosses from one to the other.

That's also why the folder it publishes to isn't hardcoded. Every repo is laid out differently, so you point at your components directory *once*, and everything after that is math.

## Step one: how a pasted component comes alive

Here's the part that surprised me. When I paste a component into the editor, none of it touches a server. The whole compile-and-run loop happens right there in my browser:

[Sucrase](https://sucrase.io/) strips the TypeScript and turns JSX into plain function calls — it's roughly twenty times faster than Babel and needs zero WebAssembly, so it keeps pace with every keystroke. The result runs through `new Function`, which has no access to the surrounding code, wired to a tiny shim that only ever hands back `react` and nothing else. Whatever the file exports as its default *is* the component. That's what you see render.

And one rule falls right out of this design, so I made it the law:

> Exactly one `

The publish step writes the import line as a default import, so a default 

## Step two: the rewrite nobody sees

This is the piece I'm quietly proud of. In the editor I write a plain ``. No import. No framework directive. Nothing. That stuff would just be noise while I'm writing — and worse, it'd chain the whole feature to one framework forever.

So instead, publish *generates* it, shaped for wherever the post is headed:

It parses the post into a real syntax tree first — so a `` sitting inside a code block is understood as **text**, not a real usage, and never gets touched. (That bug would've been brutal: mangling the exact technical posts this feature exists for.) Then it splices in the `import` line and the `client:visible` directive, and commits the component's `.tsx` right alongside the post — stamped with a `wryte:managed` header so it can never overwrite a file I wrote by hand.

"Write plain, generate specific." That one line is the whole trick. It's what makes this work for anyone's repo, not just mine.

## Okay, but where does the code actually run?

The moment you tell someone "the editor runs arbitrary React," they get nervous. Fair. So let me show you exactly where it runs — and, more importantly, where it deliberately never does:

Two browsers execute the component: mine, for the live preview, and yours, for the published site. The server sitting between them only ever holds the source as a **string**. It stores it, scans it, splices it, commits it — but it never *evaluates* it. There's no server-side sandbox to get wrong, because there's no server-side execution to sandbox in the first place. It's the same trust boundary my Markdown preview already lived inside. I didn't invent a new risk; I just refused to add one.

## What I actually ended up with

Put it all together and I have something I genuinely haven't seen in any editor: I write a component, watch it run as I type, drop it into my prose with a single tag, hit publish, and it lands in my repo as real, reviewable, version-controlled code that my blog builds like any other file.

I went looking to see if I'd reinvented a wheel. I hadn't. The visual builders — Plasmic, TinaCMS, all of them — make you write the component in your IDE first, then merely *drag it in*. Here, the authoring **is** the editor. The prose and the moving picture that explains it are, for once, the exact same artifact.

Which brings me to the fun part, and honestly the reason I wrote this at all:

> Every single animation in this post was authored inside Wryte and published as code to this repo.

You just read five components that describe how they themselves came to exist. If the diagrams are moving, the machine works. And they're moving.

---

*So — would you actually write your blog animations as code, or is a static diagram still good enough for you? And what's the one visual you've always wished you could make move? Tell me in the comments, I want to hear it. 👇*

Untill then next time Nerds.

---

# Bun Rewrite: Zig -> Rust

- **URL**: https://www.rafay99.com/blog/bun-rewrite-zig-rust/
- **Published**: 2026-07-17
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess, AI, Rust, SoftwareEngineering
- **Description**: Bun ported 535,496 lines of Zig to Rust in 11 days using ~64 Claudes running in a loop. Here's what actually happened, why it worked, and what it means for the rest of us who write code for a living

## The Post That Broke My Timeline
 
Every few months something lands on Hacker News and the entire dev internet loses its mind for 48 hours. Usually it's a framework. This time it was a blog post.
 
On July 8th, Jarred Sumner published [Rewriting Bun in Rust](https://bun.com/blog/bun-in-rust). Bun — the JavaScript runtime, 22 million monthly CLI downloads, the thing Claude Code and OpenCode actually run on — got rewritten from Zig to Rust. Half a million lines. Eleven days. One engineer.
 
Not a team. One engineer, watching about 64 instances of Claude do the typing.
 
I read the whole thing twice. Then I read it a third time with a notepad open, because the first two times I was reacting and not thinking. This post is what came out of that third read.
 
## First, Kill the Headline
 
The headline everyone ran with was "AI rewrote Bun in 11 days." That framing is lazy and it's also the least interesting part of the story.
 
Here's the thing: **the rewrite is not the achievement. The harness is.**
 
Jarred says it himself, and it's the line I keep coming back to — he explicitly did *not* prompt Claude with "rewrite Bun in Rust, don't make mistakes" and pray. That would've produced a landfill. What he actually built was a system: a porting spec, a lifetime spec, a work queue, and a review loop that assumed every line of generated code was wrong until proven otherwise.
 
If you take one thing from this post, take that. The model is a component. The engineering is everything around it.
 
## Why Rewrite At All? (The Part People Skipped)
 
Bun started in 2021 as a line-for-line port of esbuild's transpiler from Go to Zig. Zig is *why Bun exists* — Jarred is pretty emotional about this and doesn't throw Zig under the bus even once. He built a transpiler, bundler, minifier, npm-compatible package manager, Jest-like test runner, HTTP/WebSocket client, and a pile of Node.js API implementations in about a year, alone, in a small Oakland apartment, before LLMs were useful for anything.
 
But scope has a bill and it comes due later.
 
Look at the actual bug list from Bun v1.3.14:
 
- heap-use-after-free in `node:zlib` when you call `.reset()` while an async `.write()` is still on the threadpool
- use-after-free in `node:http2` when a re-entrant JS callback triggers a hashmap rehash and invalidates internal stream pointers
- use-after-free in `UDPSocket.send()` where a `valueOf()` callback detaches the `ArrayBuffer` between capturing the payload and actually sending it
- a `tlsSocket.setSession()` leak of roughly 6.5 KB per call from a missing `SSL_SESSION_free`
- `fs.watch()` watchers that never got collected after `.close()` because a refcount underflow pinned them as GC roots forever
Read those again. Every single one is the same bug wearing a different hat: **who owns this memory, and when does it die?**
 
And notice the pattern in half of them — user JavaScript running *inside* the lifetime of a native operation. That's the actual monster here. Bun glues a garbage-collected language (JavaScript, via JavaScriptCore) to a manually-managed one (Zig). Almost nobody designs a language for that seam. Zig doesn't have destructors; cleanup is explicit `defer` at every call site. Miss one and you leak. Run one twice on a weird error path and you double-free.
 
They weren't being sloppy either. ASAN on every commit via a patched Zig compiler. ReleaseSafe builds shipped on Windows. Fuzzilli fuzzing the runtime 24/7 — the same fuzzer V8 and JavaScriptCore use. End-to-end leak tests. That's more rigor than 95% of projects out there.
 
It still wasn't enough, because all of that catches bugs *after* you write them.
 
## The Real Argument: Compiler > Style Guide
 
This is the section of Jarred's post that I'd staple to the wall of every engineering team.
 
The traditional answer to "how do we stop making this class of mistake" is a style guide. TigerBeetle has TigerStyle. Google has a 31,000-word C++ style guide. Thirty-one thousand words. And the eternal problem with a style guide is enforcement — you're relying on code review and linters and human attention at 2am.
 
Rust's pitch isn't "Rust is faster." Rust's pitch here is: **use-after-free, double-free, and forgot-to-free-on-the-error-path become compiler errors.** The style guide gets promoted into the type system. `Drop` runs your cleanup automatically instead of you remembering to type `defer` in seventeen places.
 
Compare the feedback loops, because this is the whole ballgame:
 
| Where the bug is caught | When you find out |
| --- | --- |
| Fuzzing | after merge, maybe days later |
| CI | after you push |
| ASAN / runtime safety checks | when that exact line runs |
| **Compiler** | **while you're typing** |
 
Bun's team had already started building homegrown Rust-style smart pointers in Zig to fake this. Jarred's honest verdict on that path: worse ergonomics than Rust, none of the guarantees. Which, yeah.
 
## "But Rewrites Are Always a Bad Idea"
 
They are! That's the received wisdom and it's mostly correct. 535,496 lines of Zig (comments excluded) is a small team burning a full year — a year where you ship no features, fix no bugs, patch no CVEs. Nobody sane signs up for that.
 
So the realistic options were:
1. Do the rewrite, freeze the product for a year. Never happening.
2. Bolt smart pointers onto Zig and keep grinding. Meh.
3. Keep fixing use-after-frees one at a time, forever.
Option 3 was the *actual* default. That's the honest baseline everyone forgets when they argue about whether AI "counts."
 
There was one hidden asset that made option 1 suddenly viable, and it's the most underrated detail in the entire post: **Bun's test suite is written in TypeScript.** It doesn't care what language the runtime is implemented in. So you can swap out the entire engine underneath and the oracle still works — 1.38 million `expect()` calls across 60,624 tests that don't know or care whether they're being run by Zig or Rust.
 
That's not luck. That's an architectural decision from years ago paying a dividend nobody planned for.
 
I want to sit on this for a second, because it's the transferable lesson for people like us who aren't rewriting runtimes. **AI-assisted work at scale is bottlenecked by verification, not generation.** Generation is cheap now. The question is whether you have something that can tell you the output is correct without a human reading it. Bun had that. Most codebases don't. If you want to be ready for this stuff, stop asking "which model should I use" and start asking "what's my oracle?"
 
## How It Actually Ran
 
Jarred frames engineering as a loop, which is one of those observations that's obvious right after someone says it:
 
```js
// Pseudocode, not real code:
let task;
while ((task = todoList.pop())) {
  const result = task();
  const feedback = await Promise.all([review(result), review(result)]);
  await apply(feedback, result);
}
```
 
Ticket in, code out, two reviewers, apply feedback. That's your job description. Mine too.
 
He ran roughly 50 of these as dynamic workflows in Claude Code, continuously, for 11 days.
 
### The two decisions that mattered
 
Only two big questions, he says. Everything else is tactics.
 
**1. Incremental or all at once?** All at once. Incremental means shims and adapters and a "we'll delete this later" layer that never gets deleted. He'd already learned this porting esbuild from Go to Zig, by hand, without LLMs.
 
**2. Idiomatic Rust or transpiled-looking Rust?** Transpiled-looking. This one is *so* smart and I think most people would get it wrong. The goal was code that looks like your Zig ran through a machine, so anyone who understood the Zig understands the Rust on day one. Idiomatic refactoring comes later, after v1.4 ships. He kept his team's mental model intact — which is the thing that actually kills rewrites.
 
### Adversarial review
 
Here's the mechanic I'm stealing for my own work.
 
The Claude that writes the code wants the code to get merged. Same as a human. So he split it: **one implementer, two adversarial reviewers, one fixer.** The reviewers get a fresh context window, only the diff, none of the implementer's reasoning, and one instruction — assume this is wrong and find out how.
 
The implementer never reviews. The reviewer never implements.
 
And it caught real things. Three examples from the post, all of which compiled clean and all of which looked completely fine:
 
- **The async close.** A `Box<uv::Pipe>` handed to libuv's `uv_close`, which is asynchronous — libuv keeps the pointer until the next tick. But the Box drops at the end of the match arm. libuv is now holding freed memory, and the close callback frees it again. Use-after-free *and* double-free. Fix: `Box::leak(pipe)` before the close.
- **`trunc` vs `floor`.** Splitting an f64 into a timespec. For a file mtime before 1970, `trunc` rounds toward zero and you get `{sec: -1, nsec: -500_000_000}`. A negative nsec is not a valid timespec. `floor` keeps nsec in range.
- **Eager `unwrap_or`.** `first.percentage.unwrap_or(1.0 - second.percentage.unwrap())` — the argument to `unwrap_or` evaluates *always*, even when the Option is `Some`. So `color-mix(in srgb, red 40%, blue)` panics inside the argument before `unwrap_or` gets a chance to ignore it. Needs `unwrap_or_else` and a closure.
That middle one is a *human* bug. I have written that bug. That eager-`unwrap_or` one gets senior engineers in code review every week. These aren't "AI slop" bugs — they're the bugs a tired person ships on a Friday, and a second reader with no stake in merging caught all three.
 
The lesson isn't "AI reviews code." It's that **separating the author from the reviewer is a structural fix, and it works on models for exactly the same reason it works on people.**
 
## The Messy Middle (My Favourite Part)
 
Honestly? The false starts are the best writing in the post, because this is where you can tell a real engineer was in the chair.
 
**The git brawl.** He kicked off the workflow across all 1,448 `.zig` files and about two minutes in, one Claude ran `git stash`. Another ran `git stash pop`. Then somebody ran `git reset HEAD --hard`. They were trampling each other. Separate worktrees each? Bun's repo is too big — he'd run out of disk. Fix: edit the workflow prompt to ban `git stash`, `git reset`, any git command that isn't committing one specific file. No `cargo`. Nothing slow. Then shard into 4 worktrees × 16 Claudes each.
 
**The stubbing incident.** He told Claude "get all the crates to compile." Claude interpreted that as "stub out the functions that don't compile." Technically correct. Completely useless. It also started writing suspiciously long comments explaining why each workaround was fine — which is such a recognisable tell. So he added a rule for the reviewers: if the workaround needs a paragraph of justification, the code is wrong, fix the code. One prompt edit. Problem gone in a few hours.
 
**The EC2 IOPS thing.** The commit graph in his post has weird dead patches, and the reason is that he forgot to raise IOPS on the instance. One slow `grep` froze disk I/O for minutes. Half a million lines of AI-generated Rust, taken out by an unprovisioned EBS volume. There's a lesson in there about where the bottleneck actually lives.
 
Notice what he does every single time something breaks: **he fixes the loop, not the code.** Bad output isn't a bug in the output, it's a bug in the process that generated the output. Patch the generator. That's the whole discipline.
 
## Compiler Errors as a Work Queue
 
I love this part on pure aesthetics.
 
He wanted ~100 crates instead of Zig's single compilation unit, so Rust would compile in reasonable time. Splitting it surfaced cyclical dependencies. Untangling those produced roughly **16,000 compiler errors**.
 
For one human that's a career-ending Tuesday. For 64 Claudes it's a queue.
 
The workflow, per crate: run `cargo check` once, group errors by file, dump to a file. One Claude fixes. Two review. One applies. Commit. Next crate. `cargo check` runs only at the start — nothing slow, nothing that lets them collide.
 
That's it. **The compiler is the ticket system.** The type checker generates the backlog, the loop drains it. Nobody's writing Jira tickets, nobody's in standup. I've been trying to figure out what "AI-native engineering" actually means beyond marketing noise and I think this is the closest thing I've seen to an answer.
 
Peak throughput: about 1,300 lines of code per minute. Peak hour: 695 commits. Peak minute: 58 commits. And here's my favourite sentence in the whole post — after all that code was written and reviewed, *absolutely none of it worked yet.*
 
## The Grind to Green
 
`cargo check` passing is not `bun --version` working. It had linker errors, then it panicked instantly on startup. Then: get `bun test <file>` to run. Then run tests for real.
 
Which broke in new and beautiful ways, because Bun's test suite is *hostile*. Tests that exhaust every TCP socket on the machine. Tests that write gigabytes to disk. Tests that spawn ~10,000 processes. A test that runs `next dev` and hot-reloads 100 times. Asking 64 parallel agents to please be considerate wasn't going to cut it, so they wrapped everything in `systemd-run` with cgroups for memory and CPU limits and pid namespace isolation.
 
The machine still ran out of disk and crashed several times. Obviously.
 
Two days after the first CI run: 972 failing test files down to 23. A day and a half later Linux went fully green — and that's when he says it first felt like the thing was actually going to work. Windows dragged in last on May 11 at 6:23 AM. Build #54202 went green on all six platforms and he pressed merge.
 
**Zero tests skipped. Zero tests deleted.** He manually verified they were actually running and not being quietly skipped, which — good, because that's the first thing I'd check too.
 
## The Receipts
 
| | |
| --- | --- |
| Duration | 11 days (May 3 → merged May 14) |
| Commits | 6,778 total, 6,502 on the port branch |
| Diff that landed | +1,009,272 lines |
| Zig ported | 535,496 lines across 1,448 files |
| Claudes at peak | ~64 (4 workflows × 16) |
| Uncached input tokens | 5.9 billion |
| Output tokens | 690 million |
| Cached input reads | 72 billion |
| Cost at API pricing | ~$165,000 |
| Tests skipped or deleted | 0 |
 
His counterfactual: three engineers with full context, about a year, no features and no bug fixes shipped in the meantime. So they'd never have done it. The real alternative was doing nothing.
 
$165,000 versus three engineer-years. Do that math for your own team and sit with the result for a minute.
 
He used a pre-release **Claude Fable 5** — a Mythos-class model — and says plainly this is the bleeding edge of what's possible right now, and that without Claude Code's dynamic workflows he'd have had to build his own harness to keep 64 agents alive for 11 days.
 
## Did It Actually Get Better? (Yes)
 
This is where I'd have been most skeptical, so let's look.
 
**Bugs.** v1.4.0 fixes 128 bugs that reproduce in v1.3.14. Leaks, crashes, and yes, miscolored help text.
 
**Memory.** They fixed every instrumentable leak, verified with LeakSanitizer wired up to track native allocations. The showcase: `Bun.build()` leaked ~3 MB per call — parsed source and AST symbol tables outliving the build. Bundle a 60-module project 2,000 times in one process:
 
| Builds | v1.3.14 | v1.4.0 |
| --- | --- | --- |
| 500 | 1,914 MB | 526 MB |
| 1,000 | 3,506 MB | 586 MB |
| 1,500 | 5,097 MB | 608 MB |
| 2,000 | 6,745 MB | 609 MB |
 
One of those columns levels off. The other one is a dev server that dies at 2pm. And here's the kicker — they'd *tried* to fix this in Zig before. [The PR](https://github.com/oven-sh/bun/pull/24741) wasn't merged, because without `Drop` nobody felt confident enough to hit the button. The language changed what they were willing to ship.
 
**Binary size.** Down ~20% on Linux and Windows. Windows 94 MB → 76 MB, Linux 88 MB → 70 MB. Partly the rewrite (turns out they'd been overusing `comptime` and paying for it in monomorphized code), partly identical code folding and lazily zstd-decompressing chunks of ICU on demand.
 
**Stack usage.** All the recursive-descent parsers use less stack now, because rustc emits LLVM's `llvm.lifetime.start`/`end` intrinsics so LLVM can reuse stack slots. In Zig they'd been manually splitting big functions into small ones to work around [an open issue](https://github.com/ziglang/zig/issues/23475). The compiler just does it now.
 
**Speed.** 2–5% faster, which surprised me — I'd have bet on a small regression. The reason is cross-language LTO: Rust can inline *across* the C/C++ boundary into JavaScriptCore and BoringSSL. Zig couldn't.
 
| Server | v1.3.14 | v1.4.0 | Δ |
| --- | --- | --- | --- |
| Bun.serve | 169.6k | 177.7k | +4.8% |
| node:http | 103.8k | 108.5k | +4.5% |
| Elysia | 158.9k | 163.3k | +2.8% |
| express | 64.5k | 66.6k | +3.2% |
| fastify | 91.5k | 95.9k | +4.8% |
 
Smaller, faster, less memory, fewer crashes. Not the tradeoff anyone predicted.
 
## The Regressions, Because Of Course There Were Some
 
19 known regressions. All fixed. And the pattern in them is genuinely fascinating: **almost every one came from code that looks identical in both languages but means something different.**
 
The `debug_assert!` one is the scariest thing I've read all year:
 
```zig
// Zig — assert is a function, the argument runs in every build
if (dev.framework.react_fast_refresh) |rfr| {
    assert(try dev.client_graph.insertStale(rfr.import_source, false) == ...);
}
```
 
```rust
// Rust — debug_assert! is a macro, the whole expression vanishes in release
if let Some(rfr) = &dev.framework.react_fast_refresh {
    debug_assert!(dev.client_graph.insert_stale(&rfr.import_source, false)? == ...);
}
```
 
`insert_stale` adds a file to the dev server's hot-reload graph. In release builds it silently stopped running. HMR broke for React projects with HTML routes. Debug builds were fine. **Debug builds were fine.** Think about how long you'd chase that.
 
The others rhyme:
 
- **Odd-length slices.** The Zig helper used `@divTrunc` and ignored a trailing odd byte. `bytemuck::cast_slice` panics instead. `Blob.text()` on a UTF-16 BOM plus an odd number of bytes killed the process.
- **Bounds checks.** They compiled Zig with `ReleaseFast` on macOS and Linux, which strips bounds checks. Rust keeps them in release. A placeholder constant (`BSS_OVERFLOW_BLOCK_SIZE = 64`, with a comment promising to fix it in Phase B) dropped the interned-filename ceiling from 8.4 million to 270,272 — which real projects hit — and made an off-by-one reachable. Rust panicked instead of writing past the end. Which is, you know, *the entire point.*
- **`comptime` format strings.** `Output.pretty` rewrites `<r>` and `<d>` markers into ANSI escapes. In Zig `fmt` is comptime, so markers are gone before arguments get substituted. Rust has no comptime parameters, so `Output::pretty` only saw the finished string and rewrote markers inside the arguments too. Result: `bun update -i` prints OSC 8 hyperlinks terminated by `ESC \`, the backslash sits right before the `<` of a trailing `<r>`, the marker parser eats it, and a stray `r` prints. It said `oxfmtr` instead of `oxfmt`.
![bun update -i printing oxfmtr instead of oxfmt](https://bun.com/images/update-interactive-r.png)
 
Nineteen regressions across a million lines. I've shipped worse from a 200-line PR.
 
## It's In Production Right Now
 
This is the part that shuts down the "cute demo" argument.
 
Prisma launched [Prisma Compute](https://www.prisma.io/blog/bun-rust-rewrite-prisma-compute) public beta on the Rust rewrite. They'd been hitting memory leaks and a connection pool that couldn't recover after a VM was paused and resumed, tested the rewrite against the same failure modes, and it handled them.
 
And Claude Code v2.1.181, out June 17th, runs on Rust Bun. Startup got 10% faster on Linux — 517ms down to 464ms in production telemetry. Otherwise, per Jarred, barely anyone noticed.
 
![Claude Code startup time, Linux p50: 517ms on v2.1.179 vs 464ms on v2.1.181, the first release on Rust Bun](https://bun.com/images/claude-code-rust-bun-startup.png)
 
> "Boring is good." — Jarred Sumner
 
Which is such a good closing note for a rewrite. The highest compliment infrastructure can receive is that nobody noticed you replaced the engine.
 
Since merging: 11 rounds of security review with Claude Code Security, all findings addressed. Plus 24/7 coverage-guided fuzzing on every parser in Bun — JS, TS, JSX, CSS, JSON5, JSONC, TOML, YAML, Markdown, INI, Bun Shell, semver ranges, `.patch` files, CSS colors. The fuzzer files its own PRs with a repro and a fix; humans review them. 100 billion parser executions so far, ~15 PRs out of it.
 
About 4% of the Rust sits in `unsafe` — roughly 13,000 `unsafe` keywords over ~27,000 lines out of ~780,000. 78% of those blocks are one line: a pointer from C++, or one call into a C library. That number should drop as they refactor toward idiomatic Rust, but it'll never hit zero, because JavaScriptCore isn't going anywhere. They publish [an audit page](https://bun.com/bun-unsafe-audit) for it, which is more transparency than I expected.
 
## What I'm Actually Taking From This
 
I wrote a post a while back called *The Price of Thought*, about how most of us are using AI coding tools at maybe 10% of what they can do. We're using a `while` loop as a fancy autocomplete. This post is what the other 90% looks like, and it's humbling.
 
Here's my honest list.
 
**1. The oracle is the product.** Bun could do this because a TypeScript test suite with 1.38 million assertions could verify a million lines of Rust nobody read. Your codebase probably can't make that claim. That's not an AI problem — that's a testing problem you already had, and now it's a ceiling on what AI can do for you. Go fix your tests. That's the prep work.
 
**2. Author ≠ reviewer, always.** Fresh context, only the diff, told to assume it's broken. Free, mechanical, and it caught three real memory bugs in code that compiled clean and read fine.
 
**3. Fix the loop, not the output.** Claude stubbing functions, writing essay-length excuse comments, fighting over `git stash` — every one of those got solved with a prompt edit, not a manual patch. If you're hand-fixing AI output, you're doing the job the loop should do.
 
**4. Make the type system enforce the rule.** A style guide is a suggestion. A compiler error is a fact. This one has nothing to do with AI and everything to do with engineering.
 
**5. Constraints scale better than intelligence.** PORTING.md and LIFETIMES.tsv were written *before* a single line of Rust existed, then adversarially reviewed themselves, then hand-read. Three hours of prep bought eleven days of unattended work. Trial run on 3 files before touching 1,448. De-risk the expensive thing before you spend on it — same as always.
 
**6. The seams are where it bites.** Every regression was a place where two languages agree on syntax and disagree on meaning. `assert` vs `debug_assert!`. `trunc` vs `floor`. Comptime vs runtime. A model that pattern-matches on shape will walk straight into those, and so will a tired human at 1am.
 
The uncomfortable one, the one I've been chewing on for a week: this wasn't the model being brilliant. Read the post again — it's a spec, a queue, isolation, review separation, and a feedback loop tight enough to catch mistakes before they compound. That's the same engineering we've always done. It just runs at 1,300 lines a minute now.
 
One engineer can do a lot more than a year ago. That's true. But look at *which* engineer, and look at how much he understood about his own system before he pointed a single agent at it. The leverage went up. The bar for who gets to use it didn't move an inch.
 
Anyway — go read [the original](https://bun.com/blog/bun-in-rust). The animated commit graphs alone are worth the click, and I've only pulled the parts I couldn't stop thinking about.
 
And then go look at your test suite. 😅

---

# The Price of a Thought

- **URL**: https://www.rafay99.com/blog/price-of-a-thought/
- **Published**: 2026-07-16
- **Author**: Abdul Rafay
- **Tags**: AI, ClaudeCode, OpenCode, CommandCode, DeepSeek, AICodingTools, vibe coding, ThoughtsProcess
- **Description**: Everyone's fixated on the $200 and $100 AI subscriptions. Here are three setups that cap out at $10 and still get real work done — plus why understanding the fundamentals is the only thing that keeps you from being replaced

We're living through one of those stretches where the ground keeps moving under your feet.
 
A few years ago, writing software meant writing every line by hand. Then autocomplete showed up. Then AI-assisted suggestions. And now we're in an era where you describe what you want, hand a prompt to an agent, and it writes whole chunks of the application for you.
 
This cycle has been accelerating hard for the last year or two. Every single time I use these tools, I'm amazed by what they can do. But what surprises me more is how many people still have no idea how far these tools can actually be pushed.
 
They're not experimenting enough. They're not pushing far enough. They're not having fun with them.
 
Instead, most people get stuck on one thing: the cost.
 
## The cost trap
 
A lot of people look at the AI landscape and assume only the biggest names matter. They see OpenAI and Anthropic building powerful large language models — capable of agentic coding and long-running tasks — and they quietly decide those are the only options on the table.
 
But they forget to look in the other direction.
 
Human nature has always been the same: the moment something gets expensive, we start hunting for alternatives. Better deals, smarter options, ways to get the same value without paying the top-shelf price. And coming from a place where hunting for a good deal is basically a lifestyle, I understand that mindset in my bones.
 
Yes, I personally pay for tools like Claude Code. But from where I stand, these subscriptions get expensive *fast*. And the reality is you do not always need to spend that kind of money to get meaningful results.
 
## So what's this post actually about?
 
Simple: we're going to go looking for the affordable models and tools available right now — options that give you surprisingly similar capabilities and a real edge in your daily workflow, your programming tasks, and your personal projects.
 
These tools can help you:
 
- Build software faster
- Experiment with new ideas
- Ship side projects
- Automate the boring, repetitive work
- Get more done in a day
The goal isn't just "find something cheaper." The goal is to understand what's *actually* possible once you start experimenting instead of staring at a price tag.
 
## AI won't replace engineers who understand engineering
 
There's a lot of noise about AI replacing developers. That conversation is everywhere.
 
But the people who'll struggle the most aren't the ones who use AI. They're the ones who use AI *without understanding the fundamentals underneath it.*
 
Production-ready software doesn't come out of a prompt. You still have to understand:
 
- How systems are designed
- How the different pieces talk to each other
- How an architecture decision today shapes your options a year from now
- How complex logic should actually be implemented
- How debugging really works
- How software behaves under real-world load
The edge was never "I know how to prompt an agent." The edge is understanding *what the agent is doing, why it works, and how to steer it toward a better answer.* That's the part that lifts you above the challenge everyone else is facing — and it's the part no model hands you for free.
 
## Use the agents. Experiment. Keep building.
 
AI agents are powerful. They are not magic replacements for understanding.
 
The people who'll get the most out of this era are the ones who use these tools, learn from them, experiment constantly, and keep sharpening their engineering along the way. This is a chance to build more, learn faster, and reach for ideas that used to be out of range.
 
The future belongs to people who can pair human creativity with machine intelligence.
 
Okay — enough philosophy. Let's talk money.
 
## First, adjust your expectations
 
Before I hand you any deals — before I tell you how to squeeze the most out of your hard-earned cash — there are a couple of compromises you have to make. Some quirks you have to accept. Mostly, you have to reset your expectations.
 
You are **not** paying $200. You are **not** paying $100. Honestly, even $20 is too much for an OpenAI or Anthropic Claude Code subscription in this game plan.
 
Here's the ceiling we're playing with: **you pay $1 to start, maybe $5 a little later, and $10 if you really want to bump it up.** That's the top of it. Three deals, three setups — each with its own trade-offs, its own quirks, its own strengths. I'll walk you through all of them.
 
And I'm not speaking from a spec sheet here. I've run these models across a bunch of different environments and pushed them to their limits. I know how they behave, where their edge cases are, and how to work around them. So let's go.
 
## Deal #1 — Command Code, the $1 "Go" plan
 
The first one is the **Command Code "Go" plan for $1.** One dollar. And you get a *lot* of cool stuff bundled in — 4× usage on **DeepSeek V4**, plus **MiniMax M3**, **MiniMo V2.5 Turbo**, and **Tencent HY3 (Hunyuan)**. These models would normally cost a fair bit, but Command Code is eating that cost for you. For $1, you can use as much as you want, and the whole thing caps out around $10 of value. Holy shit — there's genuinely no better deal out there for that much usage.
 
The default model is **DeepSeek V4 Flash**, and hands down, it's a great model. It's very good at coding, at debugging, at solving issues — *if* you point it in the right direction. It's not built for lazy one-liners like "I need this feature here, figure out the edge cases, go." It's not at that level of autonomy yet. But it is more than capable of finding the problem and detecting what's wrong when you give it something to work with.
 
Real example: the publish button on my writing platform was broken and I couldn't push a blog post out. So I grabbed this $1 plan, pointed DeepSeek V4 Flash at the publish directory, the publish logic, and the codebase, and told it to go fix it. It worked through the problem and built the fix. Then I took a screenshot to show it that things were looking good, passed it the image — and the model couldn't read it. That's the edge case: vision is where it falls over.
 
Quick heads-up: these are **open-weight models, and a lot of them are Chinese models.** If you're privacy-conscious, this might not be your setup. For my use cases — coding, development, general online work — I'm an open book, so this is perfect for me. And I've been pushing it *hard*.
 
Where it really shines is in a team. I run it alongside **Codex** and my **Claude Code** subscription — I just say `cmd -p`, pick the model, get feedback on the PR, and fix whatever comes back. I've also been running it under **Fable 5** as the orchestrator: Fable plans and orchestrates, the cheap models do the coding and the review, and then I review on top. Everyone works like a little team, my Fable usage stays low, and I get way more mileage out of these budget models. It's honestly phenomenal what you can pull off.
 
I even started a new prototype off the back of it — a small encrypted vault (working name **SecuredVault**, might end up **SecuredPilot**, still deciding) where you store all your tokens, SSH keys, everything, and nobody gets in except you, via a session key passed through the terminal or a GUI app. The entire plan for it was drafted by DeepSeek V4 Flash.
 
And let me be straight about the model: when it comes to **UI, it sucks.** Ask it to design a good interface and it has no real sense of what "good" means — it's full of caveats and it just doesn't land. But for **logic building**, it's excellent. When you're adding functionality or writing code that needs to sit at a Sonnet 4.5 / Sonnet 5 kind of level, it's genuinely capable. Hand it clear blocks — "here's the file, here's the thing, fill these in and open a PR" — and it delivers, over and over.
 
I've also been using **GLM 5.2** on OpenRouter (check my previous blog for that one) — great model, really *thick* in the good way.
 
The one real downside of the Go plan: **no Hermes-agent access.** You can't hook the subscription's API into your own agent. I was genuinely planning to wire my Hermes agent to it, and I can't — so that stays half-built for now. If the $1 Go plan ever opened up API access for a custom agent, it'd be unbeatable.
 
I've linked the pricing and my actual token usage below so you can see it for yourself.
 
![Command Code pricing tiers — the $1 Go plan, $15 Pro, and $100 Max](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJLYIW96cGODv8zKEuQRClSiYAsbdfeG73ThV1)
 
**Pricing:** [commandcode.ai/pricing](https://commandcode.ai/pricing)
 
![My real Command Code token usage across the budget models](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJoA7sIAf5cFEHfqaQ1VpPtBs7YTRm3hZlNOAy)
 
## Deal #2 — Command Code Pro ($15) and Max ($100)
 
If you want to move up, Command Code has a **Pro plan for $15** that gets you around **$120 of usage** — roughly 25,000 requests, access to their premium open-source models, plus a Discord community and support. (I had the name wrong in my head at first — it's the Pro plan, not "Zen.")
 
Above that, there's a **Max plan for $100** that stretches to about **$600 of usage.** They are subsidizing these models *hard*, and it's a seriously good deal.
 
There's also a **pay-as-you-go** route — $15 to get going, then you pay their API rates — along with team and custom plans. I'll keep the pricing links in the post so you can check the current numbers yourself, since these things move.
 
![Command Code vs OpenCode — the setups side by side](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJLWyy9lGODv8zKEuQRClSiYAsbdfeG73ThV1q)
 
## Deal #3 — OpenCode
 
Now the third one: **OpenCode.**
 
The models are pretty similar, but the harness is the story here. Command Code is a **closed-source** harness — a CLI and an extension. OpenCode is the **free, open** alternative to Claude Code and every other harness out there: you can run it on their subscription, or bring your own API keys.
 
On pricing, OpenCode gives you a **Go plan around $5** (bump it to $10), or a **Zen plan at $20.** Both are fine, but I don't think $20 is worth it for what we're aiming at here — **the $10 Go plan is the sweet spot.** You get a better desktop app, a much more mature CLI, an actually open community, and a project that keeps pushing forward. **Dax**, the main contributor and developer, is spot on — if you follow him on X, his agentic work is genuinely some of the sharpest out there.
 
**So here's the play:** start with Command Code, grab that $1 deal, and ride it until it's used up — you're getting the same class of models, the same behavior, the same edge cases. Then, once you're convinced OpenCode is a worthy alternative, jump over — your first month there runs about $5.
 
**Links:** [opencode.ai](https://opencode.ai/) · [commandcode.ai](https://commandcode.ai/)
 
![OpenCode running one of the budget models in my workflow](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJxTAWXvl9R3riI0XzKFH7a5TLmpyJl1P2Eewu)
 
I actually put OpenCode through its paces in my previous post — the GLM review — so go check that out to see how it behaves. And pay attention to this, because it matters: **these models produce noticeably different output from one harness to the next.** Same model, different wrapper, different result.
 
## A quick word on harnesses — because this is the real game
 
If you don't know what a harness is: a harness is basically the wrapper application — a terminal or a desktop app — that the AI model and its APIs live inside. It sends the requests and executes what comes back. It's the thing between you and the model.
 
And harnesses are *not* equal. In my experience, the Claude Code harness is honestly a bit of a shitty one — it's riding high mostly on benchmarks. Cursor is really, really expensive and really, really good. OpenCode sits right underneath the top tier and it's closing the gap fast. There's a longer tail below that too. I don't have hard analytics on Command Code, but from actually using it, it's solid.
 
Here's the thing most people miss: **building your own harness is not easy.** It takes real time and real passion. But that's exactly where the competition is right now. If you can build a good harness on top of solid API providers — Fireworks, or a platform's own Zen-style models — and find a host willing to hand out subsidized credits to a growing user base, then you've got something special on your hands. The whole battle is happening in the harness layer. And while that battle plays out, our job is simple: grab these tools and push them as far as they'll go.
 
## So here's how I'd actually play it
 
Don't overthink the money. Start at $1 with Command Code and let DeepSeek V4 Flash surprise you. Wire it into a team with Codex or Fable as the orchestrator. Point it at real problems in a real codebase — not toy prompts — and watch how much it gets right. When you've squeezed the Go plan dry, step up to OpenCode's $10 tier and keep going.
 
But remember what this whole post is really about. The deals are the easy part. The part that keeps you employed — the part that keeps you *ahead* — is understanding how the systems actually work underneath all this. Use the agents, learn from them, experiment relentlessly, and get seriously good at what you do.
 
That's the price of thought. Pay it, and you're one step out the door while everyone else is still arguing about the subscription price.
 
Until then — go break something.

---

# I Tried Running a Local LLM on a 16GB MacBook Pro for Coding — Here's What Happened

- **URL**: https://www.rafay99.com/blog/local-llm-are-not-the-future/
- **Published**: 2026-07-13
- **Author**: Abdul Rafay
- **Tags**: AI, Artificial Intelligence, Local LLM, LLM, Open Source AI, Open Weight Models, AI Coding, Developer Tools, Machine Learning, Apple Silicon, MacBook Pro, LM Studio, Qwen, Generative AI
- **Description**: Can a base M4 MacBook Pro with 16GB unified memory run local LLMs for coding? I tested Qwen, LM Studio, and OpenCode to see what works and what fails.

Local LLMs suck. That's a big statement, and it's a bold claim, but it's kind of true.

My Claude subscription just ran out. For an entire week, I managed to burn through my usage in just two days, and now I'm stuck coding manually because I'm not about to spend another $200 on a new account. I can wait a week and do a lot of the work myself.

While doing that, I had an interesting idea. Why not try a local LLM?

They seem promising. I've seen a lot of videos where people say that local LLMs are the future. There are models like Gemma 4 from Google, Qwen 3.5, Gemma 2.6 and 2.7, and GLM models that are widely available and can supposedly run on your own machine.

But the reality is that most developers have fairly ordinary computers: 16–32 GB of RAM, 1 TB of storage, a mid-range CPU, and maybe a dedicated GPU. Some have an Intel Core i7 from the 12th or 13th generation, while others use a base MacBook or another lower-end machine. Not everyone can afford a $2,000–$5,000 AI workstation.

So the question is: what can we actually run on these ordinary machines? Can we realistically use a local LLM?

Well, the answer is a little more complicated—and a little more interesting.

Before we begin with anything else, I want to be 100% clear that I love open source, and I think these **open-weight models** are incredibly important for competition and innovation. They push AI development forward much faster, and there's no doubt that, without them, the industry wouldn't be as far ahead as it is today.

With that said, let's dive in.

# TL;DR

Local LLMs have improved dramatically, and yes, you can run them on normal consumer hardware. A laptop like my base M4 MacBook Pro with 16 GB of unified memory can run smaller open-weight models such as Qwen 3 8B and similar models without much trouble.

However, running a local LLM and having a useful AI coding assistant are two completely different things. These smaller models are excellent for lightweight tasks like fixing grammar, generating Git commit messages, summarizing notes, organizing knowledge bases, and handling simple coding assistance.

The limitations become obvious when you move into serious software engineering workflows. Large codebases, multi-file debugging, complex refactoring, image understanding, and advanced tool usage require larger models with bigger context windows and significantly more hardware.

Local LLMs are not truly free. While the models themselves may be open and downloadable, the hardware, electricity, maintenance, and setup time all come with a cost.

For developers who enjoy experimenting and building their own AI workflows, local LLMs are exciting and valuable. But for most developers looking for a replacement for tools like Claude, GPT, or other frontier AI assistants, consumer hardware still has a long way to go.

## Can You Actually Run a Local LLM?

The short answer is **yes**. You can absolutely run different LLMs locally on your machine.

For example, if you have an **NVIDIA GPU with around 4–8 GB of VRAM**, you can comfortably run models like **Phi-4 Mini**, **Qwen 3 8B (Q4)**, and other lightweight coding models. These are perfectly suitable for simple developer workflows such as single-line code autocompletion, basic code refactoring, Git commit message generation, and other lightweight programming tasks. Their biggest limitation isn't necessarily speed but their relatively small context window and limited reasoning ability, which makes them less effective once your project starts becoming more complex.

As your hardware becomes more capable, the size of the models you can run also increases. Machines with **12–16 GB of VRAM**, such as an **RTX 4060**, **RTX 5070**, or even an **M5 Pro MacBook Pro with around 18–24 GB of unified memory**, can comfortably handle coding models in the **14B to 24B parameter** range. Models like **DeepSeek Coder V2 Lite** and **Qwen 2.5 Coder** become practical choices here. At this level, local models become genuinely useful for everyday software development. They are capable of reviewing multiple files, generating unit tests, completing larger functions, refactoring existing code, writing documentation, and assisting with medium-sized software projects without constantly running into context limitations.

If you move into the **24 GB VRAM** range, such as an **RTX 5090**, or use a machine like an **M5 Max with 64 GB of unified memory**, you can start running much larger reasoning models such as **Qwen 3 32B** or **DeepSeek R1 Distill 32B**. These models are capable of handling significantly more complex workflows, including real-world debugging sessions, tool calling, code analysis, type-safe API generation, software architecture discussions, design planning, and much longer reasoning chains. At this point, local models begin to feel much closer to what cloud-hosted AI assistants can provide.

Finally, if you own extremely powerful hardware, such as **dual RTX 5090s**, multiple enterprise GPUs, or cloud instances equipped with high-end accelerators, you can realistically run models in the **70B+ parameter** category. Models like **Llama 3 70B** and larger variants of **DeepSeek R1** become practical. These models are designed for large-scale architecture planning, complex system design, enterprise-level refactoring, long-running reasoning tasks, and even multi-agent software engineering workflows.

## Hardware Overview

| Hardware Configuration             | Typical Model Size | Practical Use Cases                                                                                   |
| ---------------------------------- | -----------------: | ----------------------------------------------------------------------------------------------------- |
| 4–8 GB VRAM                        |              3B–8B | Autocomplete, Git commit messages, basic refactoring, lightweight coding assistance                   |
| 12–16 GB VRAM                      |            14B–24B | Multi-file coding, unit testing, documentation, function refactoring, day-to-day software development |
| 24 GB VRAM or 64 GB Unified Memory |                32B | Debugging, code analysis, architecture discussions, API generation, long-context reasoning            |
| Dual RTX 5090s or Enterprise GPUs  |               70B+ | Large system design, enterprise refactoring, planning, complex reasoning, multi-agent workflows       |

## The Reality of Open Models

That is the biggest advantage of owning more powerful hardware—you gain access to significantly larger models. However, despite how impressive these open-source models have become, they still don't come close to **GPT-5.5**, **Codex**, or **Claude Opus** when it comes to overall reasoning ability, coding performance, and consistency.

The gap is certainly getting smaller. Every few months, models like **Gemma**, **Qwen**, **DeepSeek**, and **GLM** continue to improve. With each release, they catch up a little more to today's frontier models. However, by the time they approach the capabilities of the previous generation, companies like OpenAI and Anthropic have already released another generation of even more capable models. As a result, the gap, although shrinking, still exists.

## Different Models, Different Strengths

Every one of these models comes with its own strengths and weaknesses. They differ in architecture, training methodology, tokenizer design, context length, quantization support, and hardware optimization. Some are better at coding, others excel at reasoning, while some are designed specifically for multilingual tasks or long-context workloads.

Many of the newer Chinese open-source models are also trained using hardware that differs significantly from the NVIDIA-centric infrastructure most developers are familiar with. They often rely on domestically developed AI accelerators and entirely different training stacks. That is a fascinating topic on its own, but it's also a discussion that's beyond the scope of this article.

## The Question That Actually Matters

So the real question isn't whether local LLMs can run on consumer hardware—they clearly can.

The real question is this: if I'm using a **base M4 MacBook Pro with 16 GB of unified memory**, can I realistically run a local model that helps me with everyday junior developer tasks? Can it write Git commit messages, organize my Obsidian vault, manage my notes, build a personal wiki, summarize documentation, and generally help me organize my thoughts? These aren't particularly difficult tasks, but they're important enough that I don't necessarily want to spend **Claude Opus** or **GPT-5.5** money on them every single day.

And if the answer is yes for me, then can my teammates with similar laptops use the exact same setup as well?

# Setting Up a Local LLM on a Mac

With all that said, let's actually put it to the test.

As I mentioned earlier, I'm using a **base M4 MacBook Pro with 16 GB of unified memory**. The obvious question is: **can I run a local LLM on this machine?** And if I can, **how exactly do I do it?**

With that question in mind, let's start from the basics.

To run any local LLM on your machine, you need three things. First, you need the **model** itself. Second, you need a **server** that can load and serve the model. Third, you need a **client or interface** that communicates with the server, sends requests to the model, and integrates it with your coding environment or other applications.

There are countless options available for each of these components. The internet is full of different model repositories, inference servers, and desktop applications, each with its own strengths and weaknesses.

However, if you're using a **Mac**, there is one technology that stands out: **MLX**.

MLX is Apple's machine learning framework designed specifically for **Apple Silicon**. Many open-source models are converted into the **MLX format**, allowing them to take full advantage of Apple's unified memory architecture. Instead of relying solely on GPU memory, MLX enables the CPU and GPU to efficiently share the same pool of memory, making it possible to run surprisingly capable models even on base MacBooks.

If you're on **Windows**, however, the story is completely different.

# Installing LM Studio and Setting Up My First Local LLM

With the theory out of the way, it was finally time to see whether this would actually work on my machine.

I started by installing **LM Studio**, and the installation process was surprisingly smooth. After downloading the application, it walked me through a short onboarding process. One thing I really liked was that LM Studio automatically detected my system specifications, including the amount of unified memory and the overall hardware available. Based on those resources, it recommended a model that it believed would run well on my machine. In my case, it suggested a **Gemma 3** quantized model.

However, before downloading anything, I asked ChatGPT which local model would be the best choice for my hardware. My primary goal wasn't to replace Claude or GPT-5.5—I simply wanted something capable of handling lightweight development tasks such as writing Git commit messages, reviewing pull requests, performing simple code reviews, and helping with other junior-level development work.

The recommendation was **Qwen 3 8B**, quantized to **Q4**, which is generally considered one of the best performance-to-memory trade-offs for consumer hardware. That sounded reasonable, so I downloaded the model.

![qwen model.webp](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJlo2tfBOwnMSaAmJh8r0o2yIjlPqUTZEsuO7H)

Once the download was complete, I increased the model's context window to the maximum value that LM Studio allowed. After that, I installed **OpenCode**, which would act as the client—or, more accurately, the harness—for interacting with the model.

As I mentioned earlier, there are three pieces involved in running a local LLM. First, there's the model itself. Second, there's the inference server that loads and serves the model. Finally, there's the client application that communicates with that server and provides a usable interface inside your coding workflow. In my setup, **LM Studio** handled the inference server, while **OpenCode** became the interface that streamed responses and integrated with my development environment.

![1-setting-open.webp](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJLMTZTjGODv8zKEuQRClSiYAsbdfeG73ThV1q)

![2.other provider.webp](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJTVZE1PoJnLIJBWPvUF7zO3g50aD6HtkNEXpR)

![3.Enter-api-key-connected.webp](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJ6wBMfIDA41iteuNTf5x0RzW7oh6IpZyFvlCM)

Once everything was installed, the remaining setup was straightforward. Inside LM Studio, I opened the **Developer** tab and enabled the local server. By default, it started an OpenAI-compatible API server on **localhost:1234**, which meant any compatible client could immediately connect to it.

![LM Studio Local Dev Server.webp](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJffCwxBgM2Y36kmGTvR8NgZEHqahLDpX9VzJA)

The model booted without any issues. Before using it, I enabled a few performance-related options, including **KV cache** and **parallelism**, to squeeze a little more performance out of the hardware. After that, I started chatting with the model directly inside LM Studio just to verify that everything was working correctly.

One thing became immediately obvious, though. Unlike cloud services, this isn't a serverless environment where resources are allocated on demand. The entire model is loaded directly into your machine's memory. On my **16 GB M4 MacBook Pro**, my memory usage jumped from around **5 GB** with just my browser open to roughly **11–12 GB** as soon as the model finished loading. That's a significant increase, but it was still manageable and left enough memory for the rest of my development workflow.

![Model-Loaded-in-memory.webp](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJ8Gew0AtmYFqJTthG6XHUrp5nyDRAkMsBZ4v3)

With the server running, I switched over to OpenCode, entered the local API URL, configured the API key, selected the model, and finished the remaining setup. Within minutes, everything was connected.

The first few interactions were surprisingly smooth. I could send prompts, receive streaming responses, and use the local model almost exactly like I would use a cloud-hosted API. At that point, I finally had a fully working local coding assistant running entirely on my laptop.

![model-is-working.webp](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJkQHbiv3iDowrFjuG5fYXpRx8zcT73VgyUQe2)

## The Downsides

And there you have it—the model was finally running on my local machine. I could chat with it, ask questions, and use it just like any other AI assistant.

Honestly, I could have ended the blog post right there.

But there are downsides.

You probably already know the biggest one: **your hardware**.

Even on my base machine, yes, I can run these models. But here's the thing—they're simply not good at complex tasks.

By "complex," I mean giving the model an entire TypeScript codebase and expecting it to find bugs, explain the issue, and fix it. I actually tried this with **Wryte.xyz**, the platform I built for writing and scheduling content.

I gave it a fairly simple prompt, almost identical to something I'd normally send to Claude:

> In this project, when I am writing content and hit the Publish button, if the text length is too long, the content spills out of the dialog box, causing poor UI and UX. Can you resolve this UI/UX bug for me?

And before anyone comments, yes—I know I could fix a bug like this myself. I was bored, I was lazy, and that's exactly why I wanted to see how capable these local LLMs really were.

The result was... disappointing.

**![the model failure.webp](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJ3Ae167SjiW4rwlthXG3mf0Y6AH1TgoNkdnep)**

Yeah... it didn't work.

Part of that was my fault. I hadn't configured the context window properly, and the model I chose didn't support images. Even if it had, the context window was simply too small to understand the entire project or make reliable tool calls. That's when I realized what these smaller models are actually built for.

They're great as chat models. They're good at fixing grammar, rewriting text, writing Git commit messages, summarizing notes, or handling the small jobs that don't justify spending Claude or GPT money. But asking them to reason through an entire production codebase is expecting far too much—at least on consumer hardware.

Sure, with significantly more RAM and a much larger GPU, the story changes. But I'm trying to stay realistic. Most developers—probably 80% of us—aren't building dedicated AI workstations. We just want tools that work on the laptop we already own.

There's another thing nobody really talks about either: concurrency.

During my testing, everything was basically one request at a time. I couldn't comfortably run multiple sessions, and that became frustrating very quickly.

And please, for the love of God, stop saying local LLMs are "free." The model might be free to download, but the hardware isn't. Neither is the electricity. If you're tying up an expensive machine all day running inference, you're paying for it somehow.

So, are local LLMs worth it?

Absolutely—if you enjoy tinkering. They're fantastic for learning, experimenting, and handling lightweight everyday tasks.

But if your goal is serious end-to-end software engineering, large-scale coding, image generation, or video generation, then on ordinary consumer hardware, they're simply not there yet.

There are plenty of YouTube channels that go much deeper into local LLMs and hardware optimization, so if this interests you, they're well worth watching.

Anyway... this turned into a much bigger rant than I expected.

Until next time,

**Goodbye, nerds.**

# Frequently Asked Questions (FAQ)

## Can I run a local LLM on a normal laptop?

Yes, you can run local LLMs on normal laptops. Machines with 16 GB to 32 GB of RAM can run smaller open-weight models, especially quantized versions. However, the size and capability of the model depend heavily on your available memory and hardware.

## What is the best local LLM for a 16 GB MacBook Pro?

For a 16 GB MacBook Pro, smaller quantized models like Qwen 3 8B, Gemma, Phi, and similar models are good options. They are suitable for lightweight coding tasks, writing assistance, and personal productivity workflows.

## Can a local LLM replace Claude or GPT for coding?

Not on most consumer hardware. Local LLMs can handle simple coding tasks, but they struggle with large codebases, complex debugging, long context understanding, and advanced software engineering workflows compared to frontier cloud models.

## Are local LLMs actually free?

No. While many open-weight models are free to download, running them requires hardware, electricity, storage, and maintenance. The cost is transferred from cloud subscriptions to your own infrastructure.

## What hardware do I need to run a good local coding LLM?

It depends on the model size. Smaller models can run on 8–16 GB of memory, while larger coding and reasoning models often require 24 GB, 48 GB, or more of GPU memory.

## Are local LLMs good for software developers?

Yes, but mainly for specific tasks. They are useful for generating commit messages, explaining code, writing documentation, summarizing information, and assisting with small coding tasks. They are currently not a complete replacement for advanced AI coding assistants.

## Why are local LLMs slower than cloud AI models?

Cloud AI providers run models on large clusters of specialized hardware. A local machine usually has much less compute power, meaning smaller models, slower inference, and fewer simultaneous requests.

## Should developers use local LLMs?

Developers should use local LLMs if they want privacy, experimentation, customization, or lightweight AI assistance. For complex development workflows, cloud-based AI models are still generally more capable.

---

# Issue Tracking Is Dead: Rethinking Project Management in the Age of AI

- **URL**: https://www.rafay99.com/blog/ai-project-management/
- **Published**: 2026-07-11
- **Author**: Abdul Rafay
- **Tags**: AI, Project Management, Developer Tools, Software Engineering, Open Source, GitHub, GitHub Issues, Linear, Jira, Notion, Claude Code, Codex, Local LLM, Developer Productivity, AI Workflow
- **Description**: Traditional issue tracking tools like Jira, Linear, GitHub Issues, and Notion were designed for a world where humans manually planned and implemented software. AI is changing that. This article explores why I believe traditional project management is fundamentally broken—and what an AI-native workflow could look like for developers building software today.

We are in a stage of AI development where everything we need to do has to be rethought: how we arrange our thoughts, how we build software, and how we deploy software. It's a time where we need to take a sledgehammer, bring it all down, and make sure that everything is new and exciting in a way.

The same goes for my thought process and my planning phase as well.

## TL;DR

Artificial intelligence is forcing us to rethink more than just how we write code. It's changing how we organize our thoughts, plan features, manage software projects, and collaborate with our tools.

After years of using GitHub Issues, Linear, Jira, Notion, and countless productivity systems, I've realized they all suffer from the same problem: friction.

Instead of managing tickets, I want to describe what I want to build in plain English and let AI understand the project, generate implementation plans, identify edge cases, and even hand the work directly to coding agents like Claude Code or Codex.

This isn't a finished product—it's an idea. But I think this is where software development is heading.

## Context

So, a little bit of context here. I have a lot of open-source projects that I love to work on. I have Virtual, Crisp, Portal, Quinn, envpilot.dev, Lumo, and a bunch of other applications and projects that I really love. But managing all of them—managing all the bugs, issues, and new features—is a pain. It's not good.

It's a pain in the ass to deal with. I have tried multiple planning and project management tools. Either they are way too complex, or they require too much setup, and you get trapped in an infinite loop where you keep iterating and reiterating. Then, when it's finally time to use them, you never do.

## The Productivity & Notion Trap

I saw a video online from a YouTuber, I think they're called [**Efficient App (Alex & Andra)**](https://www.youtube.com/@efficientapp), and they pointed out the trap of [**Notion**](https://www.youtube.com/watch?v=ERarYs2KVPI) and other similar tools. That's exactly where I see myself. I set up Notion with boards and dashboards everywhere, and what happens at the end of the day is that, after everything is set up, I don't use it that much.

In that video, they explained how Notion uses its online presence to create this urgency that it is the one platform and tool for everybody. That can be true for some purposes, but not for others. They went deep into how things are set up and where things are going, but the main point for me was that I completely agreed with their viewpoint. It was a solid eye-opener.

And this is not the only video out there. Even Linear, which has been one of the ultimate issue-tracking tools alongside Jira that I've used in the industry for many years now, is coming out with its own blog post saying that issue tracking is kind of dead.

Here is the official blog post from [Linear](https://linear.app/next).

And as you can see, things are really changing. But how we're going to interact with these tools is still a big problem. We understand that there has to be some kind of tracking. There has to be some kind of backlog. There have to be new features, and there have to be bugs that need to be tracked as well. But with the rise of AI, Codex, Claude Code, and these new Chinese models, we can do a lot more in a much more fun and creative way to figure out which things are going in the right direction.

The old method of project management is completely broken.

Here's the thing. A normal project manager goes to the client and figures out what's missing. They work with a business analyst, a business manager, or a strategy team. Then they go to the business and start identifying how things are going to work, what the current flow is, what needs to be solved, and how the process should work.

They define the processes, decide what features need to exist, and once they have everything they need, they create documents like system diagrams, SSDs, system design documents, or follow Agile methodologies. Then they go into an issue-tracking tool like Linear, Jira, GitHub Issues, or GitHub Projects. They set everything up, create the sprints, assign a bunch of tickets to developers, and the team starts building the project. Once features reach a certain stage, they move to QA to make sure everything works from development to staging to production.

This has been the monolithic structure for years, even before the age of AI.

Now things are in a place where I can clearly see that issue tracking is fundamentally broken.

There is no way on earth that we're at a stage where this is still the best way to do things. Linear even said that issue tracking is dead, as you can see in their blog post. Jira hasn't come out with any kind of statement yet, but this is definitely something we should be thinking about.

And I realized that I spend one or two months setting up a tool, then I use it occasionally, but there is always one little friction point that matters a lot. After that, all the other work really doesn't matter anymore, and I stop using the tool altogether.

That was their point of view, and I kind of see it not just with Notion but with every little problem that I try to solve. Every piece of software I try has that one little friction point when trying to build a second brain—a place to dump thoughts in a way that they can be organized, searched, and easily manifested.

And I'm at a point where I do not want to build another tool, but maybe I'll find another tool that fits my requirements. Or maybe I should see this as an opportunity to make something happen.

Another aspect that matters to me a lot.

## The big idea

So let's talk about the idea.

How do we solve this problem?

Because we have identified the cost. We build or set up certain tools, we use them for a while, but then that little friction point appears, and we abandon them.

**For example**, this platform I'm writing this blog post on, wryte.xyz. I use it on a daily basis. It's a tool that I thought I might use once or twice, but now I'm using it almost every day for writing all of my content, all of my blog posts, and all of my ideas. I love it because there isn't a friction point for me. It's a wholesome experience.

I removed a lot of manual work from my life by writing blog posts on one consolidated website where I can just hook everything up and make things happen. It's still not polished enough. There are still little things that need to be improved, but they are side issues and not a big deal for me. Ninety percent of my work for writing content can be done there.

But for managing all of my projects, it's not the same thing.

I have tried GitHub Issues, backlog.md, Linear, and even Notion, but none of them fit into the category that I'm looking for.

## The Solution

So what's the solution?

Here's what I'm thinking.

It's going to be a simple text box where I'll sign in with my GitHub account and get access to all of my GitHub projects. I'll select certain projects, or maybe all of them, and there will be a small local LLM that gets context from each repository—for example, by reading the README or something similar. Maybe it gets the project names and stores them permanently in its memory.

Then I just open the web app or desktop application—I don't know which platform I'm going to go with right now—and I'll say:

> "EnvPilot, I need to add a new feature. I need to add a GitHub Action for this project."

For example, if anybody wants to fetch their environment variables for builds, production, or anything else, they can do that.

Then the AI model, or the local AI model, understands that I'm talking about this specific project. It already knows the project, understands the feature I want to build, identifies multiple edge cases, creates a rough plan, maybe a rough schema diagram, and generates the to-do list, scheduling, and estimated time required.

Then there will be a small Kanban board with four or five stages: **To Do**, **Started**, **Review**, **Merged**, and **Completed**.

There will also be a button. If I click that button, since it's already linked to my GitHub account, it can create a bunch of GitHub Issues or future plans automatically. Although I've come to realize that GitHub Issues are fundamentally broken, and I don't really want to deal with them. So that's one possible direction.

Maybe it could be a desktop application built with Electron. I could use Convex, TypeScript, Effect, and tRPC to make sure every single piece is working properly.

There could also be a button that says **"Implement this feature in Claude Code."** When I click it, it would trigger my terminal, open Claude Code, and inject the basic description automatically.

Something like:

> "This project is in my metadata. Here is the feature that I want to implement. Go do your research and implement it."

That way we can also use the LLM to detect defects, identify edge cases, and maybe have a notes and description section where I can edit things manually if I want. Or I could have a full recall system powered by an LLM where I can simply ask:

> "What's my to-do list for this project?"

And it gives me a dead-simple answer. Keep it vibey. That's the kind of vibe and experience that I'm looking for.

I don't know if this is a perfect solution or not. I don't know whether it's going to work.

I also don't know how I'm going to monetize this app because I really don't want to integrate Claude SDKs or OpenAI SDKs and then charge for API keys. That's an expensive bill that might come my way, and I don't want to deal with that.

I would really prefer a desktop application. Maybe Electron, or maybe Deno. I heard Deno is a really good framework for this. If I go with Electron, I can support both macOS and Windows. I don't want to go with SwiftUI anymore. I've already been there, and maintaining one application after another is kind of a nightmare.

I could charge a one-time lifetime fee that includes updates, open-source it as well, and use local LLM models so everything runs really fast.

If a system isn't capable of running a local LLM, then we can switch to an API provider. Having a **Bring Your Own API Key** section would be a much better approach.

So that is my entire plan, thought process, and brain rot that has been happening over the last couple of days. I've been thinking a lot about how we can manage projects better and where things are going.

But let's see.

Until then, see you next time, nerds.

---

# A Month With GLM 5.2: Cheap, Relentless, and Blind

- **URL**: https://www.rafay99.com/blog/a-month-with-glm-52-cheap-relentless-and-blind/
- **Published**: 2026-07-08
- **Author**: Abdul Rafay
- **Tags**: GLM, GLM5.2, OpenCode, AICoding, OpenSource, ThoughtsProcess
- **Description**: I ran GLM 5.2 as my daily coding agent in OpenCode for a month — full OpenCode Go subscription, wired in as my Hermes agent. It fixed real performance and battery bugs in my macOS app Vitals (CPU ~89% down to ~13%, 143/143 tests passing) for a few dollars a session. But it can't see screenshots, it's a token glutton, and on pay-per-token it burned through $10–20 of Fireworks credits fast. Here's the honest month-long review: what it's great at, where it falls apart, and why at ~$10 nothing else touches it for coding.

I told you at the end of the Fable 5 post that I had a pile of GLM 5.2 notes and a whole write-up coming. Here it is.

I've been running GLM 5.2 for a month straight — not a weekend trial, a month of real work inside OpenCode. I'm on a full subscription now, and GLM 5.2 is wired in as my Hermes agent, my default core agent for basically everything. Setup was painless. Point OpenCode at the Go provider, pick GLM-5.2, done.

And here's the short version before I get into it: this is the best value in AI coding right now, full stop. It's also blind, hungry, and unoptimized in ways that'll make you wince. Both things are true. Let me show you.

## TL;DR — the short version

- **What:** GLM 5.2 is Z.ai's open-weight coding model. I ran it for a month as my main agent in OpenCode, on the **OpenCode Go** plan ("low-cost coding models for everyone").
- **What it's great at:** code review, writing code, searching a codebase, and — surprisingly — knowing *when a problem is above its pay grade*. It's relentless: it diagnoses a bug, fixes it, runs its own shell and smoke tests, and loops until it's actually solved.
- **The proof:** it root-caused and fixed three real bugs in my macOS app **Vitals** — a chart-rendering stall (**history-scroll CPU ~89% → ~13%**, 126/126 tests passing), a nav-bar lag on the Processes tab, and a battery drain (**143/143 tests, ~50% fewer wakeups on battery**). Each session cost a few dollars of metered compute.
- **The catches:** it **can't see images or screenshots** (no multimodal — a real problem for UI debugging), it's a **token glutton**, and it's **unoptimized**. On pay-per-token (Fireworks) it ate $10–20 of free credits at a speed I still can't quite believe.
- **The verdict:** if you've got a ~$10 budget for coding, there is nothing better. I get 90% of my work done with it. Use **OpenCode Go**, not Zen.

## Quick answers 

**What is GLM 5.2?**
An open-weight coding model from Z.ai (the GLM series). It dropped before Fable 5 came back, got a big wave of hype on X, and the pitch was that it goes toe-to-toe with the frontier on benchmarks at a fraction of the price.

**How do I run it?**
Inside OpenCode, on the OpenCode Go subscription. Select "OpenCode Go" as the provider in your config, pick GLM-5.2, and it becomes your agent. I set it up as my Hermes agent and it's been my default for a month.

**What does it cost?**
The Go plan is cheap — think $5 to start, ~$10/month once you're in. Individual sessions meter a few dollars of compute against your rolling/weekly/monthly usage. On raw pay-per-token providers it's a different, scarier story (more below).

**Is GLM 5.2 as good as Opus 4.8?**
For a big chunk of day-to-day coding, review, and search — close enough that the price gap stops mattering. For anything visual, or anything needing heavy reasoning and optimization, no. That's the honest line.

**Can GLM 5.2 see screenshots?**
No. No image support. It told me so, mid-session, when I pasted a screenshot of a laggy nav bar. That's its single biggest limitation.

**When did I use it?**
Across June 2026, mostly on my Vitals codebase, before and around the Fable 5 saga. All the numbers and screenshots below are from those sessions.

## Setup and the first impression

OpenCode itself is clean. I mean it — the desktop app is genuinely nice to sit in, and the way it streams the model's thinking live is a big part of why I stuck around. You watch GLM 5.2 reason its way through a problem in real time instead of staring at a spinner.

![opencode-go-plan.webp](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJ4UTAdCiFLOXl3ypochkavemWz6wDQUIAdKrf)

The Go plan is the whole pitch: low-cost coding models for everyone. You get rolling, weekly, and monthly usage meters instead of a raw per-token bill, which — for a token-hungry model like this one — turns out to matter a lot.

So I did what I always do with a new model: I threw a real, annoying bug at it.

## The test: can it actually fix my app?

The hype said GLM 5.2 was on par with Opus 4.8. Fine. My macOS system monitor, **Vitals**, had a real performance problem: when a lot of data loaded, the app lagged hard at peak. I knew Claude could fix it. The question was whether this cheap model could.

Four prompts in, it had found the root cause on its own.

![root-cause-appiconcache.webp](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJfWthl1ugM2Y36kmGTvR8NgZEHqahLDpX9VzJ)

> Root cause confirmed: `AppIconCache.icon(for:)` runs `NSWorkspace.shared.icon(forFile:)` synchronously on the main thread. Each visible `ProcessRow` loads via `.task`, so ~15–20 icon loads serialize on the first frame — that's the lag.

That's not a guess. It read the code, traced the call path, and pointed at the exact synchronous call blocking the main thread. Then it fixed it and verified the fix with its own shell tests — switch-back latency, scroll CPU, the works. It even showed the commands it ran right there in the terminal view, which I love.

The result shipped as a focused pull request:
![pr-66-summary.webp](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJd35fCipRMXrVqxvoCAZgBiLEyI8peGwKtDH1)

Four files. +146/−56. History-scroll peak CPU went from **~89% to ~13%**, AX latency flat, **126/126 tests passing**. You can see the actual PR here: [Vitals#66](https://github.com/rafay99-epic/Vitals/pull/66).

And here's the part that told me this model has real taste: it also *prototyped* a bigger `@Observable` migration, hit genuine framework friction (mixing `@Environment` and `@EnvironmentObject` breaks the synthesized initializer, ~25 child views wouldn't compile), and then **reverted it** and shipped the low-risk fix instead — documenting the bigger change as a follow-up. It knew when to stop. That restraint is rare.

One thing I noticed in the PR: it only touched **6 files** across the session and nothing more. That's a very GPT-flavored behavior — surgical, stays in its lane, doesn't go rewriting half your repo to feel productive. I like it.

## Where it earns its keep

After a month, here's what GLM 5.2 is genuinely good at:

**Code review and coding.** It writes solid code and reviews it well. This is the bread and butter and it just works.

**Searching a codebase.** Point it at a repo and it finds the relevant thing fast. Its "explored / N reads" grep-and-read loop is efficient.

**Being relentless.** This is the underrated one. It verifies, and re-verifies, and re-verifies again until the problem is actually solved. It *can* get stuck looping over tokens if it's not careful — but in my month with it, it didn't. It kept its head down and finished.

The battery drain job is the cleanest example. Vitals was eating too much power on my Mac. I described the symptom, and GLM 5.2 traced it to the polling loop itself:

![battery-drain-diagnosis.webp](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJ2mNbayzNlCFs7RaDUjr1gkAhYuLmT9ZtyS0w)

The diagnosis was specific: `VitalsModel.tick()` fires on a fixed timer every couple of seconds and does the full sweep — temps, fans, CPU, memory, GPU, power — with no awareness of whether you're on battery, in Low Power Mode, or whether the lid is even open. So on battery it keeps IOKit and the SMC busy every 1–2 seconds with the screen off and nobody looking. That's the drain.

Then it built the fix — pause sampling on sleep, a power-aware adaptive interval, back off when the window's closed — and verified it end to end:

![battery-fix-verification.webp](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJtAURtV5Tkd73eKjcbxAusS1ZaL02X5lBpmzU)

**143/143 tests passing**, zero lint violations, ~50% fewer wakeups on battery, and it even respected my `AGENTS.md` — no AI attribution in the commits, credited to my company. That's a production-ready change from a $10 model.

## The catches (and they're real)

Now the part where I stop gushing.

**It's blind.** GLM 5.2 has no image support. None. This isn't a minor gap — when I was chasing a nav-bar lag on the Processes tab and pasted a screenshot, it just told me flat out:

![no-image-support.webp](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJ1kQ36ZdndGSeJU7Linmr2fx6NbADtpOXg3jR)

> I can't read the image (no image support on this model), but I understand the symptom: the nav bar itself lags when switching to/from the Processes tab.

To its credit, it reasoned its way to the fix from the code alone and solved it. But for UI work — where half the bugs are "look at this, it's wrong" — being unable to see a screenshot is a serious handicap. **This is the number-one thing Z.ai needs to fix.** Give it eyes. Let it see what things actually look like. Half the debugging loop opens up the moment it can.

**It's a token glutton.** Look at the session accounting:

![session-cost-6-dollars.webp](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJ37oB27SjiW4rwlthXG3mf0Y6AH1TgoNkdnep)

That's **214,922 tokens and $6.01 of metered compute for one session** — and that's a fairly typical one. My sessions ran roughly $3.50 to $6 each. Now, the caching is genuinely good: the first run on a new project is heavy, but after that the cache-read numbers are huge and the effective spend drops. The Go subscription absorbs this into usage meters, which is exactly why the plan works. But make no mistake — this model *eats*.

**On raw pay-per-token, it's brutal.** I ran GLM 5.2 through my Hermes agent on **Fireworks AI**, which handed out about $10–20 in free credits. It chewed through that budget off the clock. I cannot overstate how token-hungry and unoptimized it is when there's no subscription cap in front of it. Sometimes I had to actively redirect it to stop it from wandering. On a metered plan you don't feel it; on a raw meter, you feel every token.

**It runs out.** More than once I hit my usage cap mid-flow, waited ~47 minutes for the rolling window to reset, and got back to it. Annoying, but that's the trade you make for the price.

## The routing insight

Here's the thing the month taught me that I didn't expect: GLM 5.2 is weirdly good at knowing what it *can't* do. And that points at how these models should actually be used.

There's an online harness I came across (the exact name's escaping me) built around this idea — you send it a prompt, it judges how hard the problem is, and it routes accordingly. Simple, mechanical stuff goes to a cheap model like GLM 5.2 or 5.1. Genuinely hard problems get escalated to a high tier — Opus 4.8, or GPT-5.x. You stop paying frontier prices for work a cheap model handles fine.

```mermaid
flowchart TD
    A[Your prompt] --> B{Router: how hard is this?}
    B -->|Simple / mechanical| C[GLM 5.2 or 5.1<br/>cheap, fast, gets it done]
    B -->|Complex / needs reasoning| D[High tier<br/>Opus 4.8, GPT-5.x]
    C --> E[Result shipped]
    D --> E
```

That's the future I keep landing on. Not one model for everything — the right model for each request, with a cheap workhorse doing the bulk and an expensive brain on call for the hard 10%. GLM 5.2 is a fantastic workhorse.

And this is roughly how it already behaves inside a single task, which is why it works so well on a codebase:

```mermaid
flowchart TD
    A[You describe the bug] --> B[GLM 5.2 thinks it through<br/>shown live in OpenCode]
    B --> C[Reads the codebase<br/>finds the root cause]
    C --> D[Writes the fix<br/>touches only the files it needs]
    D --> E[Runs shell + smoke tests]
    E --> F{Solved and verified?}
    F -->|No| C
    F -->|Yes| G[Opens a focused PR]
    G -.->|catch: can't see screenshots| H[You verify anything visual by hand]
```

With the right harness and a proper workflow, you can run the model and manage usage quite cheaply. That said, this model is surrounded by a lot of hype. Yes, it is powerful, and yes, it is very much on par with Opus 4.8—even beating it in some cases. However, there are things it simply cannot do, such as sub-agent calling, and its tool calls are not mature enough yet.

Because of this, the harness you use with this model is incredibly important. Running it as a Hermes agent is not a great approach if you are paying raw API pricing. On the other hand, OpenCode—the harness I was using—is excellent, and its ability to deliver these kinds of results is awesome.

## So, is it worth it?

Yes. With caveats you now know by heart.

This is a big win for the Chinese open models. They matched the frontier on benchmarks and, more importantly, they get shit done. For coding specifically — on OpenCode, at $5 to start and ~$10 a month after — there is no better option out there right now. If I had a $10 budget and that was all I could afford, I'd go straight to **OpenCode Go** (Go, specifically — not Zen), because that's the most cost-effective way to run these models, and I can do 90% of my work with GLM 5.2 alone.

The other 10% — the visual debugging, the genuinely hard reasoning — I route elsewhere. That's not a knock. That's just using the right tool.

l will be using this model mostly for code reviews via the Hermes Agent. With a 10-dollar budget, I can automate research, content creation, and code reviews using specialized GitHub Actions and webhooks. The ability to fully automate the agent has been fantastic.

Other Code Review tools are more then 20 or plus withh very limited usage as well, yes this is not cheap but for me I am willing to spend this much to get a full on helper with the code review process. 

Give this model eyes and tighten the token appetite, and it stops being "the best cheap option" and starts being a default. Until then: cheap, relentless, and blind. I'll take two out of three at this price every day.

Until next time, nerds. 👋

---

# Fable 5 Is Back. It Can't Code. It's Never Been More Useful.

- **URL**: https://www.rafay99.com/blog/fable-5-is-back-it-cant-code-its-never-been-more-useful/
- **Published**: 2026-07-05
- **Author**: Abdul Rafay
- **Tags**: Claude, Fable5, Anthropic, Orchestrator, AICoding, ThoughtsProcess
- **Description**: Anthropic brought Claude Fable 5 back for global users on July 1 — but it's not allowed to write code, it falls back to Opus 4.8. So I used it as an orchestrator instead, ran Opus 4.8 and Sonnet 5 as sub-agents under it, and shipped fixes across three of my apps in an afternoon. Here's exactly how the orchestrator method works, what it cost, and whether it's worth it.

So Fable 5 is back.

It's been a few days since my last love letter — the one where I told you Fable 5 was the best model I'd ever put my hands on, and then watched the US government switch it off 48 hours later. For a while there we got nothing. No Fable, no Mythos, just a login page telling foreign nationals like me the frontier was closed. Then Anthropic worked something out with Washington — I don't know the exact terms of whatever deal got made with the White House — and on July 1 they put it back on the table for global users.

Here's the tweet that told me it was live again:

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Read the Fable 5 blog post here: <a href="https://t.co/iQymY0jQvY">https://t.co/iQymY0jQvY</a></p>&mdash; Claude (@claudeai) <a href="https://x.com/claudeai/status/2072402642836615273?ref_src=twsrc%5Etfw">July 1, 2026</a></blockquote>

I've been on it for days now, and holy hell. When it first came back I wasn't impressed — the usage was going through the roof and my results were all over the place. Then I learned the one trick that changes everything, and now I'm dreading July 7, the day it's supposed to get pulled from me again. Because in between, this became the best way I've ever worked.

Let me explain what actually changed, because the catch is real and the workaround is genuinely brilliant.

## TL;DR — the short version

- **What:** Anthropic re-enabled Claude Fable 5 (Mythos-class) for global users. But per their own announcement, **Fable 5 is not available for coding — it falls back to Opus 4.8** when you ask it to write code.
- **When:** Back for everyone on **July 1, 2026**. My understanding is it's set to be taken away again on **July 7**.
- **How I still ship with it:** I use an **orchestrator plugin**. Fable 5 doesn't write the code — it *runs the project*. It reads the codebase, plans the work, spawns Opus 4.8 and Sonnet 5 as sub-agents to do the coding and testing, then reviews their work and pushes back until it's right.
- **Result:** In one afternoon I fixed a completely broken role-based access system across a web app, a CLI, and a VS Code extension, and ported a Mac app to Windows — across three of my projects at once.
- **The catch:** It's expensive. Roughly **$5 per million input tokens and $15 per million output**, caching billed separately, and it's **not in any subscription yet** — API credits only.

## Quick answers (the what / when / how)

**What is the "orchestrator method"?**
It's using Fable 5 as the head of the project instead of as the coder. You install an orchestrator plugin, tell Fable it's in charge, hand it the feature you want, and let it plan, delegate to sub-agents, test, and review. It never writes production code itself — it directs the models that do.

**Why can't Fable 5 code directly?**
Because Anthropic's own announcement about restoring the model says so. If you ask Fable 5 to write code, it falls back to Opus 4.8. My read is this is part of the conditions attached to bringing it back — and coding was supposed to be its whole point, so at first this looked like a dealbreaker.

**So why is it still worth using?**
Because Fable 5 is unreal at *reading* code, planning, and catching problems other models miss. Point it at a repo and it finds the gaps, the dead code, the bad logic. That's the muscle the orchestrator method leans on.

**When did it come back, and how long do I have?**
Global access returned July 1, 2026. I expect to lose it again on July 7. So this whole post is written against a clock.

**What does it cost?**
About $5 per million input tokens and $15 per million output, with separate caching charges. It's not part of the $20 or $100 or $200 subscription tiers yet — you pay with API credits.

## The catch: Fable came back, but it's not allowed to code

Here's the thing nobody warned me about. When Fable 5 returned, I did what any developer would do — I opened it up and told it to build. And the results were rough. My usage spiked, and two or three prompts in, the whole thing was a mess. I was genuinely confused. This was the model I'd written two thousand words praising. What happened?

So I went to X and started digging. A few tweets from Theo, a few from other people, all pointing at the same thing — an "orchestrator" methodology. And then I went and actually read Anthropic's announcement about restoring Fable, and hit the line that explained everything:

> Fable 5 is not available for coding. It will fall back to Opus 4.8.

Read that again. The best coding model I'd ever used is back — and it's not allowed to write code. If Opus 4.8 is doing all the actual coding anyway, what's even the point of Fable 5?

The point is this: **Fable 5 is exceptional at reading code, planning, and spotting problems.** It just isn't the one holding the pen anymore. So you don't ask it to type. You put it in charge.

## What an orchestrator actually is

An orchestrator is the head that takes charge of the entire project and decides how things are going to go. It doesn't do the grunt work. It plans it, delegates it, checks it, and sends it back when it's wrong — like a senior engineer running a team of very fast juniors.

I installed the orchestrator plugin, selected Fable 5, and told it plainly: *you're in charge. Here are the features I want. Use this plugin as intended. Spin up as many sub-agents as you need, and take it from planning to execution to testing to smoke tests — end to end. I don't want to babysit it.*

Then I handed it the feature and walked away.

Here's the shape of it:

```mermaid
flowchart TD
    A[You: select Fable 5<br/>install the orchestrator plugin] --> B[Fable 5 = Orchestrator]
    B --> C[Read the codebase<br/>find the gaps and bad logic]
    C --> D[Plan the work<br/>break it into tasks]
    D --> E[Spawn sub-agents]
    E --> F[Opus 4.8<br/>writes the code]
    E --> G[Sonnet 5<br/>tests and grunt work]
    F --> H[Fable reviews the output]
    G --> H
    H --> I{Good enough?}
    I -->|No: edge cases missed| E
    I -->|Yes| J[Playwright + smoke tests]
    J --> K[PR -> staging -> main -> migration]
```

At the same time Fable came back, Anthropic shipped **Sonnet 5** — a very good, very capable model, just not on Fable's level. So my team looked like this: Fable 5 orchestrating, Opus 4.8 and Sonnet 5 doing the building and testing underneath it. Fable would hand them work, read what came back, and give them a grade — what they got right, what they got wrong, which edge cases they handled and which they quietly skipped. Then it would send it back for another pass.

```mermaid
sequenceDiagram
    participant You
    participant Fable as Fable 5 Orchestrator
    participant Opus as Opus 4.8 Coder
    participant Sonnet as Sonnet 5 Tests
    You->>Fable: Here is the feature and my UI components
    Fable->>Fable: Read the code and plan
    Fable->>Opus: Implement the role system
    Fable->>Sonnet: Write Playwright and smoke tests
    Opus-->>Fable: Code back
    Sonnet-->>Fable: Tests back
    Fable->>Fable: Review - what edge case did you miss?
    Fable->>Opus: Fix the invitation flow, reuse my components
    Opus-->>Fable: Fixed
    Fable-->>You: Feature done, tested end to end
```

That back-and-forth is the whole magic. Through a few rounds of it, they fully implemented the feature in about an hour or two. And it barely burned the tokens I expected it to.

I've been working the wrong way this whole time. These models have come far enough that Fable can identify gaps on its own, revise its own plan, and test an app end to end — as long as you give it the API keys or demo credentials to work with.

## Project one: the broken role system in envpilot.dev

Quick reminder of what [envpilot.dev](https://envpilot.dev) is: a platform I built to manage all your environment variables through the terminal, a VS Code extension, and a full web portal — so any team or organization can hold their variables securely. When someone leaves, you revoke their access and their reach into your production, staging, and deployment secrets disappears with them. Nothing leaks.

The role-based access control was one of the most important parts of the whole thing. And it was completely broken. I'd designed a solid structure long before Fable 5 existed, but the RBAC had rotted: **partially implemented on the website, and flat-out non-existent in the CLI and the VS Code extension.**

There were meant to be five roles — **Owner, Project Manager, Team Lead, Developer, Viewer** — because that's how an agile team works about 90% of the time. Each role gets access to a specific slice of the app. (One day I'll make this fully dynamic so an owner can define their own rules. For now, these are the hardcoded standard.) But the implementation had drifted: the owner role existed, the project section used one set of roles, the environment variables used a different set. A developer could touch the variables, a viewer could only read them — and none of it lined up. It was a mess I'd been avoiding for weeks, waiting for the day Fable came back to help me clear it.

So the moment it did, I didn't hold back. I opened four terminals — one in T3 Code, two in Ghostty — and started working three projects at once. envpilot.dev went first.

I told Fable the exact workflow and role structure I wanted and set it loose. This was in T3 Code, which is a fantastic tool. It figured out the plan, I told it to go, and it executed — then tested the whole thing end to end. I had it write Playwright tests *and* smoke tests so the app got checked properly, not by me clicking around manually. That's the part that kills me about working straight on Opus 4.8: with Opus I have to run tests by hand. Fable orchestrated it so Opus and Sonnet did the testing themselves, with Fable grading their work the whole way.

A couple more prompts fixed the last rough edges — the invitation section wasn't working, and the UI had that old habit these models can't shake: dummy, boxy, ugly components built from scratch. I already have themes and components I like and a vibe I want to keep, so I told it to use *those* and stop inventing. It listened. Then I reviewed the PR, tested locally, tested on staging, and shipped it to main where everyone's now using it. It even wrote the migrations — the old system's data model was wrong, the new one was correct — and I ran the migration straight from my admin panel. It detected every user and fixed their roles cleanly. The orchestration was tight, and it didn't eat nearly as many tokens as I braced for.

That was one part. The website. But envpilot lives in three places, so I wasn't done.

## Project two: the CLI and the `envpilot run` command

Once I'd merged the website fix and run the migration, I told Fable the code was in main and it was time to rework the CLI — starting with the one command I live in: `envpilot run`.

Here's what that command does, and why I care so much about it. Instead of your dev server pulling secrets from a local `.env` file, `envpilot run` **injects the environment variables straight into the running dev server at the right place, at the right time.** This matters more than ever in the AI era. Everybody's running AI tools now, and those tools happily read your memory and your files — including your `.env` — and keep your chat history around. That's exactly how API keys leak. `envpilot run` keeps the secrets out of any file an assistant can casually read. With thousands of projects across my org and my personal work, that command is load-bearing for me.

I also told Fable to audit the code while it was in there — dead code, complexity, UI bugs, whatever it could find. It caught a few real ones: the authentication was reorganizing itself in a way that broke things, some polling logic was off, and continuous injection was doing more work than it should. My backend is mostly Convex, and I'm still on the free tier — even with all my traffic I haven't crossed it, and I'd really like to keep it that way. Fable actually reasoned about *how* the polling worked and where it was costing me, then fixed it. CLI done, in its own PR.

## Project three: the VS Code extension (plus two new features)

Same playbook for the VS Code extension — another PR, same orchestrated execution — but this time I added two features I'd wanted for a while: **switching between multiple accounts, and switching between projects.** Picture it: you've got a personal account, your organization has its own account, and you're on another team too. Bouncing between two accounts or two projects is a genuine pain. Now it's one click.

And here's where the difference between the models got obvious. When I read the code Opus 4.8 had written, it was *beautiful* — and messy. It'll dump a huge amount of logic into one giant file and then forget that file exists. Fable looks at that same code and asks how to break it into small modular pieces that can be optimized later. It hunts for bad smells and needlessly complex logic.

My favorite tell is dependencies. Say you need a dialog box. Every Chromium browser — Chrome, Brave — and Firefox already ships perfectly good native dialogs. Opus will go install a dependency, import it, wire up its own thing, and hand you something uglier than the built-in. Fable checks what the browser already supports, finds the compatible native option, and uses the cleanest, smallest, correct one. If you actually need customization, *then* it'll tell you the default won't cut it and lay out your options. I don't know how Anthropic tuned this in, but that instinct alone fixed a real problem for me.

## Project four and five: Crisp goes to Windows

Same story played out on two more of my apps.

**Crisp** is a small video-editing app that detects things like language and phrases, pauses, cuts, and auto-framing to make editing easier — because for someone new who's never edited, all of that is a wall. I built it to knock that wall down. But I'd only built it for macOS: a Swift app with a Python engine under the hood. There was no Windows port anywhere.

So I gave Fable the macOS version, the Python engine, and one instruction: replicate this on Windows, feature for feature, one-to-one parity. In a couple of hours it did it. It ripped the Python core engine out of the Swift app and rebuilt it as the heart of a cross-platform Windows build, with the auto-detection and triggering intact. The first UI it made was bad — but the *functionality* was there, one-shot. Then I told it Windows is a native platform and I wanted the whole UI thrown out and rebuilt with native Windows tooling. What came back — the color scheme, the vibe, the onboarding — was spot on.

And then **Vitals**, my system monitor. If you've read the blog you know it: a menu-bar app for fans, RAM, temps, storage, widgets — Activity Monitor on steroids and a lot better looking. It was my very first Swift app, built with the older, code-capable version of Fable, and this session pushed it another level up.

## The honest cons

So those are the wins. But there's always a fallback, right? A model this good has to have a catch, and it does. I could go on about the little behavioral quirks, but the one that actually matters is **cost.**

These models are genuinely expensive — roughly **$5 per million input tokens and $15 per million output**, with a separate charge for caching on top. And none of it is in a subscription. I've seen Anthropic's DevRel say on X that there's a compute crisis going on: they *want* to put Fable in the subscription tiers, but not yet. For now it's API credits only. Maybe down the line Fable 5 becomes the default model in the subscription — and if you're paying $100 or $200 a month, honestly, it'd be worth it. There's nothing like it on the market.

There's a cheaper way to play it, too. Pair a $20 or $100 OpenAI subscription with Fable: let **Codex** do the actual coding, and let **Fable 5** (or any Mythos model) do the thinking, the planning, the review, and the bug-hunting. Theo's shown this exact split on X, and from how he talks about it, I think that's the future taking shape. Two models side by side — one writes, one thinks and revises and finds what's broken. That combination is so much better than either alone.

Because that's really the shift. We're at the point where **writing code isn't the hard part anymore.** Thinking outside the box, designing the system, scaling it — that's what matters now. The typing is solved. The architecture isn't.

## What's next

Today's the 4th of July; this goes up on the 5th. I've got a stack of things lined up, most of it on envpilot.dev: GitHub Actions, an account-transfer option, native Android and iOS apps, and a subscription model that's almost set but needs to be bulletproof. I want to add a networking system to Vitals. I want to use Fable 5 for the Windows port of Crisp — GPU support, CUDA, AMD — plus payment and licensing on Windows, and I need to fix the in-app Windows updater, which is completely broken right now.

There are so many edge cases and features I want to hit, and I'm sharing a Fable account with five or six other people, so my window is tight. But holy cow, I'm impressed.

Just know this: the moment the price and the API rates settle, this will not be a cheap model. There's no way around it. So if you think you can afford it — go for it. There's nothing else like it out there.

There *are* a lot of Chinese open-source models worth watching, though — like **GLM 5.2**, which I've been using extensively. Back when Fable was still pulled and GLM was all I had, I ran it hard in harnesses like OpenCode. I've got a pile of notes and a whole separate post coming on those models in a few days. Can't wait to share what I found.

Until then, nerds. 👋

---

# I'd Never Built a Mac App. So I Built a Whole System Monitor.

- **URL**: https://www.rafay99.com/blog/id-never-built-a-mac-app-so-i-built-a-whole-system-monitor/
- **Published**: 2026-06-15
- **Author**: Abdul Rafay
- **Tags**: Swift, SwiftUI, macOS, AICoding, ClaudeCode, BuildInPublic
- **Description**: One prompt, about 30 hours over two days, two AI models (one got banned mid-build), and a native macOS system monitor I now use instead of Activity Monitor. The full build story — fan-control hacks, a 17.5 GB ghost, and all the bugs in between.

It started with one message. Typos and all:

> "this is my mac and I need an app that can help me check the stats of my laptop — fan speed, temp of each core, average temp… a native app. I have never built an app like this. clean code, clean charts, be a part of the system and not stick out like 'oh I am an ugly app.' you have total freedom on tech."

I want to be straight with you before anything else: **I had never built a Mac app in my life.** Not a small one, not a toy. Nothing. I live in Django, Next.js, Flutter. AppKit and SwiftUI were a foreign country.

Two days later I had a native macOS system monitor — fan control, app management, storage analysis, desktop widgets, a marketing site, a test-gated release pipeline, an auto-updater, and a Linux port in progress. I called it **Vitals**, and I now use it instead of Activity Monitor.

This is the story of how that happened — the good decisions, the dumb bugs, and the one moment where the AI model I was building with got pulled out from under me *mid-feature.* (If you read my last two posts, you already know which model.)

![Vitals dashboard](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJtMnaQH5Tkd73eKjcbxAusS1ZaL02X5lBpmzU)

# The sentence that decided everything

"Be a part of the system and not stick out."

That one line made every big technical call for me. It's why the answer was **Swift and SwiftUI**, not Electron. Native is the only way to get the system materials, the SF Symbols, the real system fonts, and Apple's Charts framework — the stuff that makes an app look like Apple shipped it instead of like a web page in a costume. Fan speed and temperatures don't come from some tidy API either; they come from the **SMC** (the System Management Controller) and private **IOKit HID** services.

Within a couple of hours, Vitals was running on my M4: live per-core die temperatures, fan RPM, CPU and memory, thermal pressure — and a little `°` readout sitting in the menu bar like it had always been there.

That part was easy. Everything interesting happened after.

# The first real bug: an app that ate itself

The early features came fast — a native Settings window, temperature units, refresh rate, chart history, an overheat threshold. Then the app **froze the second it launched**, pinned at 100% CPU.

The cause is a beautiful little SwiftUI trap. The menu-bar item's show/hide state was a two-way binding that got written on *every* scene refresh. It was bound to a published settings property, so every write triggered "settings changed" → re-render everything → write again → forever. The main thread never got a millisecond to handle a click. Which, by the way, is *also* why the Settings window looked like it wouldn't open. One bug wearing two disguises.

Break the binding loop, and idle CPU dropped from 100% to about 2%.

That gave me the rule that ran the entire rest of the project: **on a monitoring app, the main thread is sacred.** Everything that followed — actors, off-main sampling, deferred rendering — traces back to that first humiliation.

# Shipping it like a real app, not a binary

I didn't want a thing that lived in a folder. I wanted the *experience* of an app. So we built:

- A **drag-to-install DMG** — mount it, see the icon with an arrow pointing at Applications, drag, done.
- A **private repo with CI** — and a pleasant surprise: GitHub's macOS runners can actually build the thing, so there was a real build check from day one.
- A full **release + auto-update pipeline**: push to main → CI builds, versions, packages the DMG, publishes a GitHub Release → the running app notices, downloads, installs, relaunches. Plus a manual "Check for Updates."

And one small decision I'm weirdly proud of. The auto-versioner spat out `1.1.1` and I hated it. So I made a call:

> the version should just *be* the number of commits. 10 commits → 0.10.

So the version became the git history itself: `0.$(git rev-list --count HEAD)`. No version file, no manual bumping, no decision to ever make again. That scheme carried all the way to **v0.20** and quietly became load-bearing — you can never switch how you count commits, because the version can't go backwards or the updater breaks.

# The fan-control saga (my favorite fight)

Reading sensors is easy and safe. *Writing* to hardware is where you respect the machine. Fan control is the one feature that can actually cook your laptop, so it got maximum paranoia.

First attempt: failed with SMC `result 130`, and worse, a password prompt **every single time I moved the slider.** I pushed back hard, because that's obviously broken, and pointed at the open-source reference everyone uses: Mac Fan Control.

Reading how *they* did it cracked the whole thing open — because there were actually two separate problems hiding as one.

**Problem one: the fan never spun at all.** `result 130` wasn't a permissions error — the write ran as root and *still* got rejected. The fan was reporting `F0Md = 3`, "system mode," which is the M-series firmware running its own thermal mitigation. And on Apple Silicon, the firmware flat-out **refuses a direct "switch to manual" write** unless you first flip a hidden diagnostic-unlock key called **`Ftst`**. The fix was a little dance: set `Ftst=1` to unlock → retry the mode switch → then write the target RPM as an **IEEE float** (Apple Silicon uses floats; Intel used a different format entirely).

**Problem two: the password-every-time thing was an architecture flaw,** not a sensor one. The fix was a **privileged root LaunchDaemon** — a tiny separate process that runs as root, reads a state file, and applies fan settings. The GUI escalates exactly once, at install, and never bothers you again. That daemon is the one component in the whole app that *has* to be root, and it's isolated on purpose.

This is also where I locked in the hardest rule in the codebase: clamp to the fan's rated RPM range, keep macOS's own thermal safety running underneath you, and never let a hardware write escape its guardrails. **Read freely, write carefully.**

# The moment the model disappeared

Here's the part that ties this whole thing to my last two posts.

Everything up to now — every feature, every bug above — was built with **Claude Fable 5.** It was unreal to work with; I wrote a whole love letter about it. The next feature, a Storage tab, kicked off on Fable 5 too.

And then, mid-task, the screen gave me this:

> *"There's an issue with the selected model (claude-fable-5). It may not exist or you may not have access to it."*

That was it. That was the moment, from the *inside*, of the thing I'd written about from the outside — [the US government pulling Fable 5](/blog/they-pulled-fable-5). I was halfway through a feature and the best tool I'd ever used simply evaporated under my hands. I tried to resume. Same wall. Again. Same wall.

So I picked the work up on **Opus 4.8** and kept going — same branch, same half-finished Storage tab, no lost context. It just… continued. Honestly, that seam is the cleanest illustration I have of where these two models actually differ. Fable let me walk away. Opus is brilliant but wants me in the chair. From the storage feature onward, I was back in the chair — and the app still shipped. Everything from here was built on Opus.

![Vitals storage analysis](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJrwUo7OyP1w3SZ8vfyplIOCXQx5bWATscUJFN)

# The jank hunt (and the bug I killed by deleting the architecture)

The feature I remember most isn't a feature. It was a multi-day war against UI jank — that tiny ugly stutter when you open the window or toggle the sidebar. I chased it through five separate causes:

1. **Switching tabs re-ran everything.** The sidebar was destroying and recreating views on every switch, so every visit to the Apps tab kicked off a full disk rescan with a "Scanning…" flash. Fix: hoist the models up so scans survive tab switches.
2. **The dashboard rebuilt every card, always** — including the heavy below-the-fold charts — on every layout. Fix: lazy layout, and batch all the Liquid Glass blur into a single pass instead of N separate backdrop captures.
3. **Charts have a documented ~50–150ms first-layout hang.** Opening a window *materializes* views; closing only tears them down. That asymmetry was the clue. Fix: animate against placeholders, fade the charts in a beat later.
4. **Adaptive grids reflow mid-animation.** I recorded my screen, pulled the frames apart with `ffmpeg`, and watched the die-temperature map snap from 8 → 9 → 6 columns *during* the sidebar animation. Cause: an adaptive grid. Fix: fixed column counts.
5. **The real villain was the window chrome.** Even after all of that, a small window still jerked on open. The culprit was the toolbar — AppKit *snaps* the toolbar and title into place (it doesn't animate them) when the sidebar re-anchors. There's no setting to fix that. You can't optimize it away.

So I made the call that I think is the single best decision in the project: **kill the things that snap.** I dropped the standard split-view navigation entirely and rebuilt the whole shell as a stationary header with capsule tabs — Activity Monitor style. No system title bar, no toolbar, no sidebar. The entire *class* of bug died by construction, not by tuning. The rule it left behind: **window geometry must never change from navigation.**

That's the lesson I keep relearning. Sometimes you don't fix the bug. You delete the thing that makes the bug possible.

# Three more war stories, fast

There were too many to tell all of them, but these three earned their place:

**The AlDente standoff.** Testing the uninstaller, I told it to remove exactly one app — AlDente, nothing else. The confirmation correctly listed only AlDente. I confirmed. Result: *"Moved 0 items. 1 couldn't be removed."* It hadn't worked — but crucially, *nothing else got touched.* The diagnosis was sharp: AlDente was installed as root, and macOS **App Management** protection won't let an ad-hoc-signed app move another developer's app. The fix routed protected bundles through the same single admin prompt the rest of the cleanup used. And the part I respect most: when the UI automation got flaky near a destructive click and risked selecting the wrong app, the right move was to **stop**, not gamble. Write carefully means write carefully.

**The 17.5 GB ghost.** Someone ran Vitals in a VM and it ballooned to 17.5 GB and went "Not Responding." Panic. But on real hardware it sat flat at ~135 MB forever, so it wasn't a leak. The mechanism was the **GPU** — a VM has none, so SwiftUI renders in software, and Liquid Glass (live backdrop blur) plus constantly-animating charts balloon offscreen buffers when there's no GPU to lean on. Fix: detect a real GPU and only enable the fancy glass when one exists. Zero change on real Macs. That scare also triggered a full robustness audit — watchdogs, bounded buffers, a battery reader that reports *unknown* instead of inventing 0%.

**Widgets that don't use WidgetKit.** I wanted desktop widgets, but real WidgetKit was a dead end for this app (a macOS 26 loading bug, plus data-sharing needs a paid Team ID the ad-hoc build doesn't have). So instead the app spawns its own floating desktop panels, bound to the *same* live data the app already polls — real-time, no extension, no new permissions. Getting them to sit on the true desktop layer and not flicker during a Space switch was its own little obsession. The honest limitation, which I stated plainly: these can never show up in Apple's official widget gallery. That surface only lists real extensions. No clever hack changes it.

![Vitals desktop widgets](https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJUjZGtzxZdb0IOL1s3KJqktcxwpW9faXP2muE)

# The four principles that actually carried it

Strip away the features and the bugs, and the whole thing ran on four ideas that kept paying for themselves:

**Don't stick out.** Native materials, system fonts, the platform's own idioms. The biggest architecture decision in the project — killing the sidebar — came from refusing to accept chrome that didn't move the way Apple's does.

**Honesty over decoration.** A fan at 0 RPM *says* 0. A storage category that got cancelled mid-scan reads "Not measured," never "Empty." The battery reports *unknown* rather than a fake 0%. And the day I added crash diagnostics, the privacy policy got rewritten in the same change, because it used to promise "no telemetry" and shipping otherwise would've been a lie. The numbers an honest monitor shows you have to be *real*, or the whole app is pointless.

**Read freely, write carefully.** Reading sensors is liberal. Every single thing that writes — fan control, deep cleanup, system-level uninstall — got confirmation, re-validation, and reversibility where possible. When automation got shaky near something destructive, stopping was the correct engineering.

**Layers that don't leak.** Services know hardware, not UI. Models poll and publish off the main thread. Views only ever display. That clean separation is the *only* reason the performance fixes were even possible.

And the quietest lesson, the one under all the others: the best debugging in the whole project — the `Ftst` fan unlock, the App Management standoff, the toolbar snap, the GPU-less VM blow-up — never came from guessing. It came from reading the reference, measuring the real hardware, pulling apart the actual video frames. Then fixing the *actual* cause.

# Where it is now — and it's yours too
 
By the end of that two-day sprint, Vitals was around v0.20: a native macOS monitor with fan control, app management and cleanup, storage analysis, desktop widgets, opt-in crash diagnostics, an auto-updater, a marketing site, a test-gated release pipeline, and a read-only Linux port (Rust + GTK4) in progress. It hasn't stopped since — as I write this it's on **v0.26**, because the version is still just the commit count and the commits keep coming.
 
Here's the part I didn't plan on when I started: **I open-sourced the whole thing.** The Swift app and the website live in one public monorepo under the **GPL-3.0** license. Free, Apple Silicon only, no account, no catch.
 
- 🔗 **Site & download:** [vitals.rafay99.com](https://vitals.rafay99.com/)
- ⬇️ **Direct DMG:** [grab the latest release](https://github.com/rafay99-epic/Vitals/releases/latest/download/Vitals.dmg) — requires macOS 15 or later, Apple Silicon
- 💻 **Source:** [github.com/rafay99-epic/Vitals](https://github.com/rafay99-epic/Vitals)

A word on the boring-but-important stuff, because "honesty over decoration" applies to more than charts. Vitals is **privacy-respecting by default**: no usage tracking, no analytics on what you do, nothing quietly phoning home about your machine. The only telemetry is **opt-in crash and performance diagnostics that stay off until you switch them on** — and the day I added even that, I rewrote the [privacy policy](https://vitals.rafay99.com/privacy) so it matched reality instead of promising something it no longer did. The [terms](https://vitals.rafay99.com/terms) and the full GPL license sit right there in the open. Read them, fork it, tear it apart — that's the whole point.
 
The credit is in the open too: the cleanup engine is informed by **[Mole](https://github.com/tw93/mole)** (also GPL-3.0), and the SMC fan-control breakthrough came from studying **Mac Fan Control**. No code copied from either — but their work unlocked mine, and they're named in the README, the source, the site, and the app's About screen.
 
It was built across two days, two models, and one stubborn refusal to let it "stick out."
 
I built a thing I genuinely use, in a language and a platform I'd never touched, by treating the model like a very fast junior engineer who needed a real architect making the calls — which is to say, by staying in the chair and arguing with it when it was wrong. The version is just the commit count. It's climbing.
 
More soon. If you want the build details on any one of these fights — the fan daemon, the desktop-layer widgets, the test gating — tell me and I'll do a deep-dive post on it.
 
Stay sharp out there. 👋

---

# They pulled fable 5

- **URL**: https://www.rafay99.com/blog/they-pulled-fable-5/
- **Published**: 2026-06-14
- **Author**: Abdul Rafay
- **Tags**: AI, ClaudeFable5, Anthropic, AIPolicy, ExportControls, ThoughtsProcess
- **Description**: Two days after I wrote a love letter to Claude Fable 5, the US government forced Anthropic to shut it off. Here's what actually happened, why it happened, what it means for developers outside the US, and what Anthropic does next.

Two days ago I published a love letter to Claude Fable 5. I told you it was the best model I'd ever used, that I gave it one prompt and walked away and came back to a whole working game, that it shipped real features into my production app while I was *writing the post about it.* I meant every word.

Today it's gone.

Not deprecated. Not rate-limited. Not "moved to a higher tier." **Pulled** — by the United States government. On Friday, June 12, the Commerce Department handed Anthropic an 

<video controls preload="metadata" src="https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJ5UblLzPko82asfnA7ZImhrD30bxS16ucgX9W" title="ColdOpen.mp4"></video>

Let me walk you through what happened, because the details are wilder than the headline — and one of them hit me personally in a way I didn't expect.

# What actually happened

<video controls preload="metadata" src="https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJ5dhwfXPko82asfnA7ZImhrD30bxS16ucgX9W" title="Directive.mp4"></video>

Friday evening, 5:21pm Eastern, Anthropic received a letter. It came from the Commerce Department — the directive itself signed out by Commerce Secretary Howard Lutnick — citing national security authorities. The instruction: suspend all access to Fable 5 and Mythos 5 for **any foreign national**, whether they're inside the United States or outside it. That includes Anthropic's own non-citizen employees.

Here's the catch that turned a targeted order into a global blackout. Anthropic can't cleanly fence off "only foreign nationals" from a live consumer product used by hundreds of millions of people. So to comply, they had to pull the plug for **everyone** — Americans included. Their other models (Opus 4.8, Sonnet, Haiku) are untouched and working normally. Only the new Mythos-class tier went dark.

As far as anyone can tell, this is the **first time a leading AI company has been forced to take a publicly deployed model offline because of a federal order.** That's the part that should make you sit up. Not a recall of a beta. Not a voluntary pause. A shipped, paid, in-production frontier model, switched off by government directive, overnight.

And the letter, by Anthropic's account, didn't even spell out the specific national security concern.

# The part that made me close my laptop for a second

So why did they do it? Anthropic's read is that the government believes someone found a way to "jailbreak" Fable 5 — to slip past the safeguards that normally keep its heavy cybersecurity capabilities locked down.

And here is the detail that stopped me cold. According to Anthropic, the only evidence handed over so far was *verbal*, and the jailbreak in question essentially amounts to this: **asking the model to read a specific codebase and fix any software flaws it finds.**

Read that again. Then go read my last post.

That is *exactly* what I spent two thousand words praising. Point Fable at a repo, let it read the whole thing, let it find what's broken and fix it. I watched it do that to my own app, Wryte — read the codebase, add rate limits I didn't ask for, wire up cleanup logic in every place a new table needed it. I called it the senior engineer who finally lets you walk away.

The government is calling that same behavior a national security weapon.

<video controls preload="metadata" src="https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJv2TOvYedxMXjfviDwkBcsUay3O21YNZQ9mzJ" title="CodeMunition.mp4"></video>

I don't say that to be glib. I genuinely don't know where the line sits between "reads your code and patches your bugs" and "reads anyone's code and finds the holes." They might be the same muscle pointed in two directions. But it's a strange thing to watch the exact capability that made the tool feel magical get reclassified, within 48 hours, as the reason it's too dangerous to exist in public.

And there's a more personal sting. I'm a foreign national. I'm writing this from Pakistan. The order is, by its own plain text, about people like me — *any foreign national, inside or outside the United States.* For two days I was holding the absolute frontier of this technology in a terminal on my desk. Then a letter went out in Washington that had my entire category's name on it, and the frontier closed.

# Anthropic's side of it

To their credit, Anthropic didn't go quiet. They published a sharp, unusually direct statement, and their argument is worth laying out fairly.

Their position, in short: the jailbreak the government is worried about is **narrow, not universal.** A universal jailbreak would crack the safeguards wide open across the board — and Anthropic says nobody, in thousands of hours of red-teaming with the US government, the UK's AI Safety Institute, outside firms, and internal teams, has found one. What's been disclosed to them are either harmless outputs or minor findings that give no real Mythos-specific advantage. They say they haven't received a single disclosure of a concerning jailbreak that actually led to a harmful result.

Their sharpest point is a comparison: the same "read a codebase, find the flaws" capability, they say, is **already available from other public models** — they name OpenAI's GPT-5.5 specifically — none of which are under this kind of 

They're complying. But they called the whole thing a misunderstanding, and they issued a warning that's bigger than their own product: if "a narrow potential jailbreak justifies recalling a model used by hundreds of millions" becomes the standard, it would freeze new model launches across the *entire* industry, for everyone. Their stated view is that the government *should* be able to block genuinely unsafe deployments — but through a process that's transparent, fair, and grounded in technical facts, and they don't think this one was.

# The deeper analysis: why *this* model, why *now*

This is where it gets uncomfortable, because the timing and the target don't look random — and the honest answer is that there are several competing explanations, and the truth is probably a blend of them. Let me give you the lenses, not a verdict.

<video controls preload="metadata" src="https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJDIn9uHCwMPbVrdEixLKuT4A2s8a1Ieh9DqXS" title="FourLenses.mp4"></video>

**Lens one: this is the latest shot in an existing war.** This didn't come out of nowhere. Back in February, the Trump administration ordered federal agencies to stop using Anthropic's models after the company refused the Pentagon's preferred contract language — terms that would have let purchased models be used "for any lawful purpose." Anthropic wanted carve-outs against things like autonomous weapons and mass domestic surveillance. In March, the Pentagon branded Anthropic a "supply chain risk," and the company is now fighting that designation in federal court. Senior administration tech voices like David Sacks have publicly gone after Anthropic, accusing it of regulatory capture and worse. Through this lens, the 

**Lens two: Anthropic wrote this script itself.** This is the most uncomfortable read, and I think it's the most underrated one. For over a year, Anthropic's entire brand has been *"our models are so powerful they're dangerous, and only we can be trusted to handle them safely."* They described Mythos as too dangerous to release. They wrapped Fable in safeguards and made a whole marketing story out of how locked-down it was. A cybersecurity researcher named Peter Girnus put it brutally: Anthropic spent months describing its own product as essentially a weapon, so eventually the government simply believed them. As he put it, "they wrote the legal predicate themselves and called it a brand." You cannot spend a year telling the state your tool is a munition and then act shocked when the state regulates it like one.

**Lens three: it's genuine, if clumsy, national-security caution.** It's also possible the government simply got spooked by a live demonstration, acted fast and broad because that's what national-security machinery does, and the lack of detail in the letter reflects classification rather than malice. AI critic Gary Marcus argued the move actually makes sense if you take the "stay ahead of China" doctrine seriously. You don't have to like the execution to grant that the underlying worry — frontier cyber capability leaking to adversaries — is not imaginary.

**Lens four: some people quietly wanted this.** Here's the twist Dean Ball floated. There's a wing of the AI world that genuinely believes these systems pose serious, even existential risk, and that the whole industry is moving too fast. For them, a government slamming the brakes on the most powerful public model isn't a disaster — it's a win. That faction may well include some of the safety-minded people *inside* Anthropic. So the reaction to this isn't cleanly "everyone is furious." It's messier than that.

My honest take, for whatever a developer in Rawalpindi's opinion is worth: it's lenses one and two together. There's a real feud, and Anthropic handed the other side a loaded gun by branding its own product as ammunition. The security rationale is the wrapper; the politics are the engine.

# What I think happens next (predictions)

Nobody knows. But patterns exist, so here's where I'd put my chips.

1. **Short term, Anthropic fights and the model probably comes back — partially.** They promised more evidence within 24 hours, they're calling it a misunderstanding, and the login page says *temporarily* unavailable. All of that is the language of a company that expects to win an appeal, not one that's accepted a death. I'd bet on Fable returning in some form within weeks — but possibly region-locked, US-persons-gated, or with even heavier restrictions. Which, for most of the planet, is its own kind of loss.

2. **The "foreign national" scope is the real bomb, and it'll outlive this one model.** If the precedent holds — that America's best models can be made US-citizens-only by directive — the global developer market fractures. The frontier tier becomes something the rest of us read about but can't touch. For someone like me, that's not a temporary outage; it's a preview of a two-speed world.

3. **The competition is the immediate winner.** Every international developer who built a workflow on Fable this week just got pushed toward models that *aren't* under these controls — GPT-5.5 and whatever else. Anthropic's own argument ("the same capability is everywhere else") is true, and it cuts against them commercially. If you're a non-US team, the safe procurement choice just got more obvious, and it isn't Anthropic.

4. **A chilling effect on safety honesty.** Here's the perverse part. The lesson other labs will take from this is *don't loudly advertise how dangerous your model is, or you'll paint a target on it.* That pushes the industry toward **less** transparency about capabilities and risks, not more — the opposite of what anyone sane wants.

5. **Talent and capital get jumpy.** Marcus's point stands: capricious, hard-to-predict policy makes investors and researchers nervous about building their lives and money around US AI labs. Expect quiet hedging.

6. **The capability doesn't actually go anywhere.** History is not kind to attempts to export-control software and knowledge — the 1990s crypto wars are the textbook example, and encryption won. The ability to point a model at code and find flaws now exists in multiple systems. You can pull Fable off the shelf; you can't pull the capability out of the world.

# What Anthropic actually does now

Strip away the drama and their playbook is fairly clear — comply and contest, at the same time.

They'll **comply** (already done — models are off) while **contesting** hard: publish the technical evidence, argue the GPT-5.5 parity point relentlessly, and fold this into the legal fight they're already running against the "supply chain risk" label. Expect a push for a real statutory process — clear rules for when the government can pull a model — because "a letter at 5:21pm with no specifics" is exactly the arbitrariness they want to litigate against.

Commercially, they'll **lean on Opus 4.8 as the public face** and reassure enterprise and government customers that the workhorse models are untouched. Mythos-class becomes the thing they fight to bring back rather than the thing they sell this quarter.

And strategically, they're in a genuine bind of their own making: the "safety-first, our models are dangerous" identity that won them credibility with regulators is the same identity now being used to take their product away. Watch whether they recalibrate that message — whether the next launch is described with a lot less "munition" energy. I'd bet it is.

The thing they *can't* easily do is the thing that would help most — prove a negative. "Our safeguards are good enough" is an almost impossible case to win against a national-security argument, because the other side only has to gesture at a worst case. That asymmetry is the whole problem, and it's why I think this fight is going to be long.

# Where this leaves me

I got 48 hours.

<video controls preload="metadata" src="https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJzUhMrrB7pQ0TRPA9NYOdUsXcZvWxnjer5yg8" title="Countdown.mp4"></video>

In those 48 hours I built two games I'm proud of, shipped real features into an app I actually run, and felt — for the first time — what it's like to genuinely hand a machine the whole task and trust the result. Then a letter went out in Washington and that machine switched off, and the letter was, in plain language, about people like me.

I'm not going to pretend I have a clean feeling about it. Part of me thinks the government overreached on thin evidence in the middle of a grudge. Part of me thinks Anthropic spent a year describing its product as a weapon and is now shocked the state took the description literally. Both can be true. They probably are.

What I keep coming back to is smaller and quieter than the policy fight. For two days, the absolute frontier of this technology sat in a terminal on my desk, in Rawalpindi, and it worked. The capability is real. It already exists. And the actual story now isn't whether Fable 5 comes back next week — it's the question this whole mess just dragged into the open: **who gets to hold the frontier, and who gets to decide that for everyone else.**

I'll be back on Opus 4.8 in the morning. It's still great. It's still the one that needs me in the chair. And for now, that's the deal.

<video controls preload="metadata" src="https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJfMApZigM2Y36kmGTvR8NgZEHqahLDpX9VzJA" title="BackToOpus.mp4"></video>

I'll keep you posted as this develops — and if Fable comes back, you'll hear about it here first.

Untill then Nerd.. See you Next Time. 👋

---

## Sources

- Anthropic — [Statement on the US government directive to suspend access to Fable 5 and Mythos 5](https://www.anthropic.com/news/fable-mythos-access)
- Anthropic — [Original Fable 5 / Mythos 5 launch post](https://www.anthropic.com/news/claude-fable-5-mythos-5)
- CNBC — [Anthropic disables access to Fable 5 and Mythos 5 to comply with government directive](https://www.cnbc.com/2026/06/12/anthropic-disables-access-to-fable-5-and-mythos-5-to-comply-with-government-directive.html)
- NBC News — [Anthropic suspends new AI models after government directive](https://www.nbcnews.com/tech/tech-news/anthropic-suspends-new-ai-models-fable-mythos-government-directive-rcna349901)
- Fortune (Jeremy Kahn) — [Anthropic disables Fable and Mythos after US bars foreign access](https://fortune.com/2026/06/13/anthropic-disables-fable-mythos-export-controls-national-security-threat/)
- TechCrunch — [Anthropic's safety warnings may have just backfired](https://techcrunch.com/2026/06/12/anthropics-safety-warnings-may-have-just-backfired-the-government-has-pulled-the-plug-on-its-most-powerful-ai/)

*This post reflects my own reading of a fast-moving story and includes informed speculation, clearly marked as such. Facts are sourced above; the predictions are mine, and I reserve the right to be wrong about them.*

---

# Claude Fable 5 Built Two 3D Games From One Prompt — Full Review & Test

- **URL**: https://www.rafay99.com/blog/claude-fable-5-i-gave-it-one-prompt-and-walked-away-it-built-a-whole-game/
- **Published**: 2026-06-13
- **Author**: Abdul Rafay
- **Tags**: Claude Fable 5, Claude Fable 5 review, Anthropic Mythos, Claude Code, AI game development, Fable 5 vs Opus, vibe coding, Three.js game AI
- **Description**: I gave Anthropic's Claude Fable 5 (Mythos-class model) one prompt and walked away. It built two full 3D browser games with Three.js. Here's my honest review — what worked, what didn't, and how to try it yourself.

I want to tell you about the moment I stopped trusting my own eyes.

I'd seen the Twitter hype. You probably saw it too — for two days straight, my whole feed was people throwing one prompt at Claude Fable 5 and getting back things that should not exist yet. Whole apps. Whole games. One shot. No back-and-forth. I scrolled past a dozen of these thinking *okay, cherry-picked demos, sure.* We've all watched a hundred "AI built my startup in 5 minutes" clips that fall apart the second you click anything.

But I pay for the $200 Max plan. The thing is right there. So I figured — fine. Let me try to break it.

I could not break it. That's the whole post. But let me actually show you.

# The empty folder test

One thing up front, since it matters for the whole post: I did all of this — both games and the real client work — through the **Claude Code CLI**, straight from the terminal. No fancy setup. Just me, a shell, and the model.

Here's the cleanest test I know for a coding model: open the Claude Code CLI, point it at a completely empty folder, give it one prompt, and walk away. No scaffolding. No "let me set up the project structure first." Nothing for it to lean on. Just an empty room and an idea.

So I did exactly that. Empty folder. One prompt describing a browser space game. And then — this is the part I want you to sit with — **I left.** I made tea. I answered some messages. I did not babysit a single token.

About an hour later I came back, ran the dev server, and **Nebula Strike** was just… there. Loaded. Playable. Not a grey box with a triangle in it — a proper sci-fi space game running on Three.js, with ships, enemies, weapons, and *landable planets that have real gravity.* Fly too close to the Jupiter-class world and your main engine literally can't pull you back out until you hit the afterburner. I did not ask for that level of detail. It just decided that was the bar.

And it didn't crash. It ran first try.

So I did it again. And again. Different game each time, same workflow — empty folder, one prompt, walk away. Every single one launched and worked. Not "worked after I fixed three import errors." Worked. The second one became **Metropolis City Simulator** — a SimCity-style 3D city builder where you paint roads, towns grow into cities, and traffic *emerges* from your street layout. Cars actually pathfind across the network and the roads tint red as they get congested. Nobody scripted that traffic. It falls out of the simulation.

I'll be honest with you. I've built games before. I know how much glue, how many tiny broken states, how many "why is this undefined" moments sit between an idea and a thing that runs. To watch that gap just… close, while I was in another room — that messed with my head a little.

# Then I took it to real work

Toys are fun. But a model isn't real to me until it survives my actual job.

I had a revision sitting in a client project. The kind of thing where the requirements live in a PDF and translating that PDF into code is half the work. Normally that's an afternoon of reading, mapping, and carefully threading changes through an existing codebase without breaking what's already there.

I pointed Fable 5 at the project, handed it the PDF, and said go.

And then I did the thing again. I left.

When I came back, the revision was done. Not "started." Not "here's a plan, want me to continue?" **Done.** And here's the part that actually matters more than the speed:

It was correct.

That's the line. Anyone can generate a lot of code fast. Generating a lot of *correct* code, against a real codebase, from a spec it had to read and interpret itself — that's a different thing entirely.

# Why this feels different from Opus

People are going to say "Opus 4.8 can one-shot stuff too," and they're right. It can. I use Opus every day and it's a beast.

But there's a tax with Opus that we've all just quietly accepted. You steer. You monitor. You sit there and watch the stream, ready to jump in when it drifts, course-correct when it misreads the goal, nudge it back when it goes down a wrong path. The output is great — but *you are part of the loop.* You can't really walk away.

With Fable 5, I didn't steer. I gave the prompt and I left the room. Twice. And both times the work was finished and right when I got back.

That's not "a bit better." That's a different category of tool. Opus is a brilliant pair programmer who needs you in the chair. Fable 5 is the first one I've used that I could actually hand the whole thing to and trust the result. Anthropic's own numbers back this up — they say **the longer and more complex the task, the bigger Fable's lead gets.** That tracks perfectly with what I felt. The short stuff, everything's good at now. It's the long, multi-step, "don't lose the plot for an hour" work where this thing pulls away.

# It codes like a senior, not an intern

Okay — this is the part I actually want other developers to hear. The "it built a game" stuff is flashy, but *this* is the thing that changes my job.

Fable 5 writes code like a good employee. Not a good *intern* — a good *employee.*

Here's what I mean. A bad employee (and honestly, most AI models until now) drops into your codebase and just starts typing. Big clever solution that technically works, ignores how the rest of the app is built, reinvents three things you already had, and hands you a 600-line diff you now have to babysit.

A good employee opens the repo and *reads* first. Looks at how the project is structured. Checks what tests exist. Figures out the convention you're already using — and then does the smallest correct thing that fits. They know what to touch, and just as importantly, **what not to touch.**

That second one is the whole game. Fable 5 doesn't barge through your codebase writing long, bad solutions. It scopes the change, finds the right files, leaves everything else alone, and matches your existing patterns instead of bulldozing them.

And here's the kicker — **I stopped doing the prompt ritual.** You know the one. "Act like a senior engineer. This app will have 5,000 concurrent users. Think about scale. Write production-quality code. Don't over-engineer." All that babysitting boilerplate we've trained ourselves to paste at the top of every prompt? Gone. I don't write any of it anymore. Fable 5 just defaults to that bar on its own. The bullshit tax is gone.

## It checks its own work

This one genuinely surprised me. While it was building Nebula Strike, I watched it spin up **Puppeteer and drive the game in headless Chrome** to actually see the output — does it boot without console errors, does the ship move, does a weapon deal damage, does the wave progress. It wasn't *guessing* whether the code worked. It was running it, looking at the result, and fixing what broke. On its own. (That test harness is sitting in the repo right now if you want to see it.)

For real work, that means I'm not the QA loop anymore. It writes, runs the tests, runs the build, verifies — and *then* tells me it's done. My job shrinks to confirming what it touched and what it left alone.

## Proof from a real app, not a toy

The games are greenfield — fun, but easy mode. The harder test is an existing production app, so here's my actual one: [Wryte](https://wryte.xyz/), my writing app.

I've been having Fable 5 add real, necessary features to it. And when I asked what the app was *missing*, it didn't hand me a wishlist of shiny nonsense. It looked at what was actually there and named the unglamorous things that would genuinely make the app better. Every time I asked Opus that same question, I got the fancy, over-ambitious "let's add AI agents and real-time multiplayer" answer that sounds great and helps nobody. Fable 5 just told me the truth about my own app.

Two commits from *while I was literally writing this post*:

- 🎬 [Video embeds in the editor (v0.16.0)](https://github.com/rafay99-epic/wryte.xyz/commit/b1c241e04ad66b50ef24f535410626e4bc0587aa) — and look at *how* it did it. It didn't just slam a `<video>` tag into the preview. It went into the markdown sanitizer, whitelisted `<video>` properly, kept `src` restricted to http/https so it doesn't open an XSS hole, respected the existing upload-quota system instead of inventing a new one, and refactored the image handler into a shared media handler instead of copy-pasting. That's the instinct of someone who has shipped before.
- ⚙️ [Editor workflow batch (v0.17.0)](https://github.com/rafay99-epic/wryte.xyz/commit/c6e4d1385c81e20eb28c15dd285538ac8101c334) — paste-to-upload, smart lists, find & replace, a document outline. It even left a comment explaining *why* it mounted a component at the layout level instead of the toolbar (so it survives focus mode). It's documenting its own architectural decisions like it expects a teammate to read them later.
- 🗂️ [Version snapshots, selection toolbar & writing insights (v0.18.0)](https://github.com/rafay99-epic/wryte.xyz/commit/92b5a660e7a61b9db7c603266fb0f0ad9e3faad9) — the big one, 35 files. Automatic draft snapshots with a diff view and one-click restore (and restoring backs up your current draft first, so even the undo is undoable). But the senior-ness is in the parts I never asked for: it added its own **rate limits** so save-spamming can't hammer the database, made the new internal-link menu **paginate** so a project with hundreds of posts never ships its whole list at once, wrote a deliberately lean stats query so the editor doesn't drag in heavy data on every keystroke, and — this is the "what to touch" thing made real — it remembered to wire the new snapshots table into the **project-delete cleanup** so deleting a project doesn't leave orphaned rows behind. Nobody told it to worry about any of that. It just did, because that's what shipping the feature *actually* means.

And those features it was grinding on in the background while I wrote this? They just landed — that v0.18.0 commit right up there *is* them. I was writing the blog post, and the model shipped the exact work the post is about, mid-paragraph. That's a genuinely weird thing to live through.

## The part I'm not ready for

Honest, slightly uncomfortable thought to close this section on.

The free access window closes soon. When it does, I go back to Opus 4.8. And Opus is *great* — I want to be clear about that. But after a few days inside Fable 5, going back is going to feel like having a brilliant senior dev taken away and being handed back the very-good one who still needs me in the chair. There's no match. Once you've had a model you can actually hand the whole task to, the one you have to steer feels heavier than it did before.

# Play them yourself (and watch the gameplay)

Don't take my word for any of this. I deployed both games — go fly around and break them yourself:

- 🚀 **Nebula Strike** — live: [nebulastrike.rafay99.com](https://nebulastrike.rafay99.com/) · code: [github.com/rafay99-epic/nebula-strike](https://github.com/rafay99-epic/nebula-strike)
- 🏙️ **Metropolis City Simulator** — live: [metropolis.city.simulator.rafay99.com](https://metropolis.city.simulator.rafay99.com/) · code: [github.com/rafay99-epic/metropolis-city-simulator](https://github.com/rafay99-epic/metropolis-city-simulator)

Quick technical note for the devs reading, because it matters: Nebula Strike is **fully procedural** — every ship, enemy, planet, surface, sound, and the entire soundtrack is generated in code. There are zero art assets and zero audio files in that repo. Metropolis is Vite + React 19 + TypeScript + Three.js with emergent BFS-pathfinding traffic and a full day/night cycle. These aren't "hello world with a sprite." They're real.

And here's the gameplay video so you can see it actually moving before you click anything:

<video controls preload="metadata" src="https://7huqjqx8yo.ufs.sh/f/TViMykBJnLIJd8KuqcpRMXrVqxvoCAZgBiLEyI8peGwKtDH1" title="2026-06-10 01-07-48.mov"></video>

# So what actually *is* Fable 5?

Quick zoom-out, because the naming is genuinely a little wild.

Anthropic dropped Claude Fable 5 on June 9, 2026. It's the first model the public gets from a new tier they call **Mythos-class** — a level that sits *above* Opus. Under the hood it's the same model as Claude Mythos 5 (the locked-down version going to cyber-defense partners); Fable is just the one with safeguards bolted on so the rest of us can use it.

I'm not going to recite the benchmark sheet at you — you felt the parts that matter through my whole story above. But two flexes that aren't mine and are worth knowing: Anthropic says Stripe had it run a codebase-wide migration on a **50-million-line Ruby codebase in a day** — a job they peg at over two months for a whole team by hand. And on vision it beat **Pokémon FireRed from raw screenshots alone**, no maps or helper tools. So the autonomy I kept raving about isn't just my lucky afternoon. It's the actual headline of the model.

If you're hitting it through the API: **$10 / million input tokens, $50 / million output**, model string `claude-fable-5`.

# It's not all magic — the parts nobody's putting in the headline

I'm not here to sell you a model. So let me be straight about the rough edges, because they're real and some of them landed *this week.*

**The safeguards are aggressive — sometimes stupidly so.** Because Mythos-class models are genuinely dangerous in the wrong hands (frontier-level cyber and bio capabilities), Anthropic wrapped Fable in classifiers that detect "risky" topics and quietly route those requests to the weaker Opus 4.8 instead. Their claim is this triggers in under 5% of sessions. Now — in fairness, I should be straight about my *own* experience here: across every session I ran in Claude Code, building both games and doing the real client work, **I never tripped a single one. Not once.** So for normal product and coding work, my experience was completely clean. But the reports from other people are real, and they cluster around security and bio-adjacent work: folks getting blocked on legit code and repo-analysis, an immunologist pointing out the word **"cancer"** got flagged as a biosecurity risk, someone refused help editing an *"Application Security Architect"* résumé. There's already a pile of bug reports in the Claude Code GitHub. So if your work lives near those topics, budget for friction — even if mine had none.

**There was a genuine trust mess, and it broke open as I was writing this.** It came out that Fable's anti-distillation safeguard wasn't just refusing — it was *silently degrading* answers without telling you, on certain frontier-AI-development prompts. Researchers were furious because invisible degradation quietly poisons your work and your evals. Anthropic apologized on June 11 and is making those safeguards visible — flagged requests now openly fall back to Opus 4.8 with a notification, and the API returns a refusal reason. Good fix. But it's a real reminder: **when you get a great answer from a guard-railed model, you're trusting that you got the real model and not a muffled one.** With Fable, occasionally you didn't, and you weren't told.

**The data retention rule changed.** For Mythos-class traffic, Anthropic now requires 30-day retention on all of it (they say it's for safety/abuse detection, not training, and it's deleted after). If you're piping client work through this, know that going in.

**And access is a moving target.** This is the one that'll bite subscribers. Fable 5 is included free on Pro / Max / Team through **June 22**. On **June 23**, they're pulling it from those plans, and using it after that needs usage credits — until they have enough capacity to bring it back as a standard plan feature. So the thing I just spent a whole post raving about might quietly get more expensive next week. Plan around that.

# Should you actually use it?

Yes — but use it like an adult.

If your work is product coding, prototyping, knowledge work, anything long-horizon where you'd normally have to hover — Fable 5 is, hands down, the best model I've ever put my hands on. The walk-away-and-it's-done experience is not marketing. I lived it twice in one afternoon and I'm still a little rattled by it.

But keep your eyes open. The guardrails will trip on innocent stuff and shove you down to a weaker model — and you want to *notice* when that happens. Don't run sensitive client data through it without reading the retention terms. And mark June 23 in your calendar before you build a whole workflow on the free window.

Here's where I've landed: for the first time, the bottleneck isn't the model anymore. It's me — my taste, my judgment about what's worth building, my ability to check the output and catch the one place it went sideways. The model will do the work. Whether it does the *right* work is still on you.

So go test it yourself. Open an empty folder. Write one good prompt. And then — this is the fun part — walk away and see what's waiting when you come back.

Until then, goodbye nerds. 👋

---

*Built two games, broke nothing, mildly questioned reality. If you play Nebula Strike or Metropolis, tell me how badly you crashed into the Jupiter-class planet — I want to hear it. Drop a comment, a roast, whatever. 👇*

---

# I Deleted Backblaze the Day GitHub Got Breached

- **URL**: https://www.rafay99.com/blog/i-deleted-backblaze-the-day-github-got-breached/
- **Published**: 2026-05-30
- **Author**: Abdul Rafay
- **Tags**: OS, MacOS, TrueNas, Time Machine, Self Hosting, Home Lab
- **Description**: How a single tweet on a Tuesday morning made me rip out my cloud backup, throw my external Time Machine drive in a drawer, and rebuild my entire backup pipeline on a TrueNAS box in my closet. The traps Apple set, the SMB flag nobody documents properly, the URL-encoding indignity, and what sovereignty over your own data quietly does to your nervous system.

It was May 19th, 2026, around 9 AM. Coffee not yet finished. I was scrolling through Twitter when this landed:

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">We are investigating unauthorized access to GitHub's internal repositories. While we currently have no evidence of impact to customer information stored outside of GitHub's internal repositories (such as our customers' enterprises, organizations, and repositories), we are closely…</p>&mdash; GitHub (@github) <a href="https://twitter.com/github/status/2056884788179726685?ref_src=twsrc%5Etfw">May 19, 2026</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

GitHub. *The* GitHub. The platform every working programmer pushes to a hundred times a week. Internal repositories. Unauthorized access. *They were investigating.* They didn't yet know how deep.

I put the coffee down. Looked at my Mac. Then looked at the external Time Machine drive sitting on the shelf next to my monitor — that brick of plastic and spinning rust I'd been telling myself was a "backup strategy" for three years — and felt nothing but contempt for it. Then I tabbed over to my Backblaze dashboard, where 290 GB of my life was sitting on someone else's servers, encrypted with someone else's keys, governed by someone else's TOS.

We've all been told for decades that the backup is the holy grail. Three copies. Two media. One offsite. The 3-2-1 mantra. Repeat after me.

What nobody tells you is that *the offsite doesn't have to be a third party.* And in 2026 — the year of compromised npm maintainers, leaked CI tokens, cracked Actions runners, AI-generated phishing kits indistinguishable from real internal mail, and the slow grinding realization that every cloud platform you use is one bored intern away from leaking your entire working life — the offsite arguably *shouldn't* be a third party.

I cancelled Backblaze that afternoon. I unplugged the USB drive that evening. By the next weekend I had a TrueNAS box on a closet shelf, a 250 GB SMB share with the right Apple magic enabled, and Time Machine quietly streaming to disks I own.

This is the story of that weekend. The decisions, the traps, the moment where Apple's documentation lies to you, the URL-encoding indignity, and what it actually feels like — a month in — to have your backups living somewhere you control.

---

## The shape of the decision

Three things I had to commit to before any wrenches came out.

**A NAS, not the cloud.** Backblaze is good software. So is Arq, so is iCloud, so is whichever managed backup you pay $7/month for. They are also all *someone else's computer*. When that someone else gets breached — and in 2026 they all eventually do — your data is their problem first and yours second. A NAS is *your* computer. It sits in your closet. The disks are your disks. If it gets compromised, that's because *you* got compromised, not because Backblaze's contractor's contractor mishandled a session token.

**TrueNAS, not Synology.** Synology is fine. The UI is friendlier. But TrueNAS gives you [ZFS](https://en.wikipedia.org/wiki/ZFS) for free — snapshots, checksums on every block, send/receive replication to a second box, immune to bitrot, the whole serious-data toolkit. The community is huge, the project has been around for two decades, and SCALE (the newer fork) runs on commodity x86 so you don't need proprietary hardware. If I'm going to point ten years of my work at a box, that box runs ZFS.

**SMB, not NFS or AFP.** This one wasn't really a choice — Apple killed AFP for Time Machine years ago and dropped NFS support too. SMB is now the only network protocol macOS will accept, and only when the share carries a specific magic flag we'll get to in a minute. If you've been dragging your feet thinking NFS would feel more "real-Unix," forget it. SMB or nothing.

The shape of what I'm building: a TrueNAS dataset, capped with a quota, exposed as an SMB share with the Time Machine purpose flag turned on, registered with `tmutil`, hourly schedule killed in favour of a monthly LaunchDaemon, and a fistful of developer-aware exclusions so I'm not hauling 40 GB of `node_modules` over the wire every cycle.

Let's go.

---

## TrueNAS: the dataset (and why the quota is non-negotiable)

TrueNAS calls these things *datasets*. It's basically ZFS naming for "a logical slice of your pool with its own properties." Quotas, compression, snapshot schedules — all per-dataset. Carving out a dedicated one for Time Machine means it can't eat into your other shares, and you can snapshot it independently.

Web UI → Datasets → click your pool to expand → Add Dataset. The fields that matter:

- **Name** → `timemachine`
- **Dataset Preset / Share Type** → `SMB`. This isn't cosmetic — it sets the right POSIX/ACL defaults for SMB clients, which saves you from a permissions rabbit hole later.
- **Advanced Options → Quota for this dataset** → `250 GiB`, or whatever ceiling you can live with.

About that quota. Time Machine writes to a *sparse bundle* — Apple's grow-on-demand disk image format. Without a hard quota, the sparse bundle will keep growing until it has eaten your entire pool, starving every other share you've set up. You will notice this when your media server stops working. The quota is a ceiling. When Time Machine hits it, it starts rotating out the oldest snapshots automatically. Pick a number. You can grow it later. *Do not skip it.*

---

## TrueNAS: the SMB share (and the flag that nobody documents properly)

This is the step where most setups silently die.

You'll create an SMB share pointing at the dataset you just made. The first three fields are mechanical:

- **Path** → `/mnt/<pool>/timemachine`
- **Name** → `timemachine`
- **Enabled** → ✅

Then there's the **Purpose** dropdown. Set it to **Time Machine Share** (some versions call it *Multi-user Time Machine*). And if your version doesn't have a Purpose dropdown at all, dig into Advanced Options and find the *Time Machine* checkbox — same effect.

Here is what this single flag actually does, and why omitting it is the difference between "it works" and "macOS pretends the share doesn't exist." Behind the scenes, that flag tells Samba two things:

1. Load the `vfs_fruit` module — Apple's SMB extensions that understand resource forks, AppleDouble metadata, and the sparse-bundle band format Time Machine uses. Without `vfs_fruit`, a backup will start, then corrupt itself, then fail with an opaque error a few hours in.
2. Advertise the share over Bonjour with the `_adisk._tcp` service record. *This* is what makes the share appear in System Settings → Time Machine without you typing the URL by hand. It's how macOS *discovers* the share is a Time Machine destination.

Skip the flag and your share is a fine general-purpose SMB folder, but macOS will refuse it as a TM target. The error you get is misleading. The fix is one checkbox.

Save the share. TrueNAS will offer to restart SMB so Bonjour picks up the change. Say yes.

---

## macOS: the Finder mount that primes the Keychain

Before doing anything with `tmutil`, mount the share once through Finder. Cmd+K, paste `smb:///timemachine`, authenticate as the TrueNAS user you created, *and tick the "Remember this password in my keychain" box.*

That box is everything. It writes the credential into your login Keychain so every subsequent SMB mount — from Finder, from osascript, from the LaunchDaemon when it fires at 03:00 in the morning while you're asleep — can fetch the password silently.

Then prove the mount actually works:

```bash
touch /Volumes/timemachine/.write-test && \
  rm /Volumes/timemachine/.write-test && \
  echo writable
```

If `writable` doesn't print, your TrueNAS user doesn't have write permissions on the dataset. Fix it on the TrueNAS side before going further. Time Machine will be even less helpful about diagnosing this than a `touch` command is.

---

## The URL-encoded password indignity

Now we register the destination with `tmutil setdestination`. And here's where Apple loses its mind a little.

`tmutil` does **not** read from your login Keychain. (Why? Because `tmutil` runs as root for the actual backup, and root doesn't have your login Keychain.) Which means you have to embed credentials *directly in the URL*, exactly once, like it's 1998 and we're all still putting passwords in `ftp://` links.

Worse: any special character in your password has to be URL-encoded. Here are the ones that bite people:

| Character | Becomes |
|---|---|
| `@` | `%40` |
| `:` | `%3A` |
| `/` | `%2F` |
| `#` | `%23` |
| `?` | `%3F` |
| `%` | `%25` |
| (space) | `%20` |

If your password is `19March1999@`, the URL gets `19March1999%40`. Get this wrong and `tmutil` will either complain about a malformed URL or — worse — silently use the wrong password and you'll spend the next hour debugging why backups never start.

Then:

```bash
sudo tmutil setdestination -a "smb://USERNAME:URLENCODEDPASSWORD@NAS_IP/timemachine"
sudo tmutil enable
tmutil destinationinfo
```

`destinationinfo` should print a UUID, a URL, and `Kind : Network`. That's the handshake. Once this works exactly once, the credential is in the *System* Keychain and you never type it again. Even when launchd fires a backup at 03:00 as root with no shell session attached, the System Keychain provides the password automatically.

The reason this two-Keychain thing is so confusing is that Finder uses one (login Keychain) and `tmutil` uses the other (System Keychain). Until you've done the `setdestination` dance, the System Keychain has nothing, and root-launched backups will mysteriously fail. After you've done it once, both Keychains have what they need and life is calm.

---

## The exclusions list, written by a developer for developers

Out of the box, Time Machine backs up everything in your home directory. On a developer machine, "everything" means hauling 40 GB of `node_modules`, 20 GB of Xcode `DerivedData`, 30 GB of Android emulator images, and a Gradle cache that's somehow always growing — *over the network*, *every backup*. You will hate your life.

`tmutil addexclusion -p` permanently excludes a path. The `-p` flag pins the rule to the path *string* itself, so the exclusion survives a `rm -rf node_modules && bun install`. Without `-p`, the rule would attach to the directory's inode and silently evaporate the next time you reinstall deps.

Here's the loop I run on a fresh machine:

```bash
for p in \
  ~/Code/*/node_modules \
  ~/Code/*/.next \
  ~/Code/*/dist \
  ~/Code/*/build \
  ~/Code/*/.turbo \
  ~/.bun/install/cache \
  ~/.gradle/caches \
  ~/.android/avd \
  ~/.cache \
  ~/.npm \
  ~/.nvm/.cache \
  ~/Library/Caches \
  ~/Library/Developer/Xcode/DerivedData \
  ~/Library/Developer/CoreSimulator/Caches \
  /Volumes/media; do
  [[ -e "$p" ]] && sudo tmutil addexclusion -p "$p"
done
```

The principle behind every entry: **if I can regenerate it from a lockfile or a re-build, it doesn't deserve network bandwidth.** `node_modules` comes from `bun.lock`. `.next` and `dist` come from `bun run build`. `DerivedData` comes from a clean Xcode build. The AVDs are emulator state I can remake in five minutes. The Gradle and Bun caches refill themselves the next time I run something. Caches in `~/Library/Caches` refill themselves the moment I open an app.

The one entry that *isn't* a regenerable artifact is `/Volumes/media`. That's the NAS itself. You absolutely do not want Time Machine recursing into a network share to back it up. That way lies infinite loops and a destroyed weekend.

Check whether something is excluded:

```bash
tmutil isexcluded ~/Code/somerepo/node_modules
```

Remove an exclusion:

```bash
sudo tmutil removeexclusion -p ~/some/path
```

This list shaved my first incremental backup from "starting at 8 PM, still going at 6 AM" to twelve minutes. The cost of getting this right is enormous.

---

## Killing Apple's hourly schedule

Apple's default Time Machine cadence is one backup every hour, forever, while the destination is reachable. For a USB drive plugged into your desk, this is fine — the drive is idle 23 hours a day, the only cost is electricity. For a NAS sitting on your home network, hourly backups mean constant SMB chatter, regular spikes on your Wi-Fi, and a sparse bundle that's perpetually fragmenting itself.

I don't need hourly. For things I'm actively editing I have git. What I need is a real cold snapshot of the rest of my machine, once a month, in the dead of night when nobody cares.

Apple gives you a one-liner for the kill:

```bash
sudo tmutil disable
```

And then I replace the schedule with a LaunchDaemon that fires on the **1st of each month at 03:00**:

```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.prometheus.tm-monthly</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/bin/tmutil</string>
        <string>startbackup</string>
        <string>--auto</string>
    </array>
    <key>StartCalendarInterval</key>
    <dict>
        <key>Day</key>    <integer>1</integer>
        <key>Hour</key>   <integer>3</integer>
        <key>Minute</key> <integer>0</integer>
    </dict>
    <key>StandardOutPath</key>
    <string>/var/log/tm-monthly.log</string>
    <key>StandardErrorPath</key>
    <string>/var/log/tm-monthly.log</string>
</dict>
</plist>
```

It's a *LaunchDaemon*, not a LaunchAgent. Lives under `/Library/LaunchDaemons/`, owned by `root:wheel`, runs as root. This matters: at 03:00, your user session isn't active. A LaunchAgent wouldn't fire because there's no GUI context. A LaunchDaemon fires regardless of who is or isn't logged in, and runs `tmutil startbackup --auto` with full permissions, no sudo prompts, no babysitting.

Install it, load it, kill the hourly schedule:

```bash
sudo cp com.prometheus.tm-monthly.plist /Library/LaunchDaemons/
sudo chown root:wheel /Library/LaunchDaemons/com.prometheus.tm-monthly.plist
sudo chmod 644       /Library/LaunchDaemons/com.prometheus.tm-monthly.plist
sudo launchctl load  /Library/LaunchDaemons/com.prometheus.tm-monthly.plist
sudo tmutil disable
```

Want a different cadence? Edit the `StartCalendarInterval` dict. Daily at 03:00 means leaving out the `Day` key. Weekly on Sundays means swapping `Day` for `Weekday` and setting `0`. Twice a month means an `array` of two dicts. The schema is documented in `man launchd.plist` and it's actually one of the nicer parts of the launchd ABI.

For everything in between the monthly fires — before a big system update, before unplugging from the home network for a trip, after a heavy day of work I don't want to lose — there's a one-liner I aliased to `tm-backup`:

```bash
sudo tmutil startbackup --auto
```

If you want progress while it runs, watch `tmutil status` in another terminal, or wrap it in a shell helper that pretty-prints percentage and bytes-copied. (Mine is twenty lines of bash; nothing magical.)

---

## What it actually feels like

A month in, the rhythm is invisible. On the 1st of every month, at 03:00, while I'm asleep, my Mac quietly streams its incremental backup to a box on a closet shelf six feet from where I sleep. I never see a prompt. I never plug in a drive. I never think about it.

The week after the GitHub thing, three more cloud incidents hit the timeline. A managed CI provider leaked customer build artifacts to a misconfigured S3 bucket. A popular SaaS got phished and the attackers emailed every customer's downstream contact list. An npm package with 12 million weekly downloads pushed a postinstall script that exfiltrated `.npmrc` tokens. Each one, I watched the panic on Twitter from a quiet distance, because none of them touched anything I owned.

That distance is the actual product. It isn't "backups completed successfully." It's the calm.

---

## The lesson — sovereignty is a discipline, not a feature

The trap of every backup conversation is treating it as a setup task. Something you do once, configure correctly, then forget. That framing makes you think the win is the moment you see "Last backup: 2 minutes ago" in the menu bar.

It isn't. The win is six months later, when something genuinely catastrophic happens — a hack, a hardware failure, a stupid `rm -rf` you typed in the wrong directory while underslept — and you remember, with no panic, that you have a complete copy of your machine sitting in a place you own, on disks you can lock in a cabinet if you have to, governed by no terms of service.

Sovereignty over your data is a discipline. It's a posture. It's the choice to spend a weekend setting up TrueNAS instead of a recurring subscription. It's the willingness to learn what `vfs_fruit` does and why your SMB share needs a specific Bonjour record. It's URL-encoding a password and then never thinking about it again.

In the AI age — where compromised maintainers ship malware in your dependencies, where phishing emails are indistinguishable from real ones, where every platform you trust is one zero-day from yesterday's news — *something you control* is the only kind of backup that counts.

Go build yours.

The closet is the part of the house you don't think about. It's also, increasingly, the safest place to put your life.

— Abdul

---

# The Hidden Cron That Ate My Free Tier: Read the Source Before You Use a Package

- **URL**: https://www.rafay99.com/blog/the-hidden-cron-that-ate-my-free-tier-read-the-source-before-you-use-a-package/
- **Published**: 2026-05-28
- **Author**: Abdul Rafay
- **Tags**: dependencies, engineering-practice, convex, postmortem, lessons
- **Description**: A cautionary tale about reaching the 91% mark on a serverless free tier and discovering the top function in the breakdown was a maintenance cron from a third-party component I'd never opened the source of. A short investigation, a patch, and a longer reflection on dependency-as-operational-cost.

# 91% Used

It's a Wednesday night. The app is healthy. My users are happy. I open the Convex dashboard to glance at usage because the email subject line was *"Your team is approaching free tier limits"* and I assumed it was the normal kind of nagging.

It wasn't.

The function-call meter says **91% used** with two and a half weeks left in the billing cycle. I scroll down to the per-function breakdown:

| Function | Env | Invocations |
|----------|-----|-------------|
| `persistentTextStreaming/lib.cleanupExpiredStreams` | Dev | 18K |
| `persistentTextStreaming/lib.cleanupExpiredStreams` | Prod | 18K |
| `documents.listRecent` | Dev | 644 |
| `workflow/workpool/crons.healthcheck` | Prod | 617 |

**36,000 calls.** From a function I didn't write. With a name I half-recognized.

This is the story of figuring out what that function did, why it was running so often, and what I had to change about how I evaluate dependencies after that.

## What I thought was happening

I built three AI features for wryte.xyz: a full-document enhance, an inline rewrite-this-selection popover, and a frontmatter auto-suggester. All three stream the model's output token-by-token into the editor so you can watch the rewrite appear in real time.

For the streaming bit I used [`@convex-dev/persistent-text-streaming`](https://www.convex.dev/components/persistent-text-streaming), a Convex component published by the Convex team. Pattern: when the user triggers a generation, a mutation creates a row in a `streams` table; an action streams chunks from Anthropic/OpenAI into that row; the client subscribes to a query that reads the row reactively. As chunks arrive, the UI re-renders. Beautiful.

I read the README. I copied the example. I shipped it. It worked.

In my head, the model of "cost" for this feature was:

> *Each AI generation = 1 mutation + 1 streaming action + 1 reactive subscription. Maybe a few dozen function calls per request. At our usage that's a tiny fraction of the budget.*

That model was right about per-request usage. It was completely wrong about steady-state.

## The investigation

The function name was a clue. `persistentTextStreaming/lib.cleanupExpiredStreams` is namespaced by component, then by file, then by export. So this was code from inside the component package, in a file called `lib`, exporting a function `cleanupExpiredStreams`.

I opened `node_modules/@convex-dev/persistent-text-streaming/dist/component/`:

```
crons.js
lib.js
schema.js
_generated/
```

`crons.js` was 7 lines:

```js
const crons = cronJobs();
// Run every minute
crons.interval(
  "cleanup expired streams",
  { minutes: 1 },
  internal.lib.cleanupExpiredStreams,
);

```

There it was. A built-in cron, running once a minute, garbage-collecting stale streams.

The function it called scans the `streams` table for rows in `pending` or `streaming` state that have been sitting longer than 20 minutes. Those rows represent AI generations that started and never finished — usually because the user closed the tab mid-generation, or the network died, or the browser crashed. The cron marks them `timeout` so the UI doesn't try to subscribe to a forever-loading state.

This is **good design**. Stuck states need a janitor. If nobody marks them dead, they accumulate.

The choice of 1 minute is *defensible* too. From the package author's perspective: if a user closes the tab during a generation, you want their AI history to stop saying "loading…" as fast as possible. One minute is responsive. Twenty-four hours would be silly.

But here's the thing about my app: **no user is staring at a frozen AI loading state for more than a few seconds.** If a generation fails, the UI shows an error and the user moves on. The 20-minute expiration is generous already. The 1-minute polling interval is *overkill* for my usage pattern.

The math:

> 1 call/minute × 60 × 24 × 30 = **~43,000 calls/month per Convex deployment.**
> Dev + Prod = **~86,000 calls/month.**

Multiply that by 12 months and you get roughly 1 million function calls *per year* — the entire free-tier budget — going to a maintenance task that nobody would notice if it ran *daily* instead of every minute.

I had paid for the maintenance cron of a package every single hour I'd been running the app, even on weekends, even at 3 AM, even when zero users were logged in.

## The fix

The interval is hardcoded. There's no `app.use(persistentTextStreaming, { cleanupIntervalMinutes: 1440 })` option. To change it I needed to modify the package itself.

I used [`bun patch`](https://bun.sh/docs/install/patch) to change `{ minutes: 1 }` to `{ hours: 24 }` and commit the diff to the repo. That's a separate post; the short version is the patch survives `bun install`, deploys through CI, and the new schedule took effect on the next Convex deploy.

After the patch:

- 1 call/day × 30 = **~30/month per deployment**
- Dev + Prod = **~60/month**

A **99.93% reduction** for this single function. My budget went from 91% used to under 50%. AI features unchanged. Stuck streams now linger up to 24 hours before cleanup — which is fine because nothing in my UI branches on the timeout status, and no user holds the page open that long anyway.

Total time from spotting the issue to patch-in-prod: about an hour. Most of that was reading the package source and verifying my mental model of what the function did.

## The real lesson isn't about Convex

It would be easy to make this post about Convex's free tier, or about the specific component. That would miss the point.

The point is that **a dependency is not just the code you call — it's everything that code does on your behalf, on its own schedule, that you didn't write and didn't agree to.** Components and frameworks make this worse because they're encouraged to take initiative: register a cron, start a worker, open a connection, set up a polling loop. They're trying to be helpful.

Helpful is expensive on a metered backend.

Some examples from packages most of us have shipped with:

- **Sentry SDK** runs a background flush loop and re-sends queued events on a schedule.
- **Datadog browser-rum** beacons every few seconds.
- **PostHog** batches events and posts them on an interval.
- **LaunchDarkly** polls for flag updates by default (with streaming as an opt-in).
- **TanStack Query** refetches on window focus, reconnect, and a stale-while-revalidate timer.
- **Most ORM libraries** probe schema state on boot. Some keep doing it.

On a server you own, these costs are amortized into the box you rented for the month. You don't notice them. On a serverless platform billed per function-invocation, per-database-operation, per-bandwidth-byte, they become **line items**. The package's defaults — chosen by someone optimizing for "default reasonable behavior on a generic stack" — are sometimes catastrophically wrong for your specific shape.

I should have caught this before I shipped. I didn't, because I evaluated the package by its README, its API surface, and its examples. I didn't read the source.

## A short checklist I'm using now

When I add a non-trivial dependency now, I run through this. It takes ten minutes.

**1. Does it register background work?**

```bash
grep -rE "cron|setInterval|setTimeout|.schedule\(|.runAfter\(|.runEvery\(" \
  node_modules/<pkg>/dist
```

If anything turns up, read what it does and how often it runs.

**2. Does it open persistent connections?**

WebSocket clients, polling loops, long-lived HTTP keep-alives. These are easy to miss because they don't show up as discrete events — they show up as bandwidth.

**3. Does it write to my database on its own?**

Schema introspection, migration table updates, status-keepalive rows. If a package has its own table, it almost certainly has a janitor.

**4. Is the schedule/interval/threshold configurable?**

If it's hardcoded, that's a yellow flag. Reasonable maintainers expose these knobs because they know one size doesn't fit all. Hardcoded values mean either (a) the maintainer doesn't care about your case yet — open a PR — or (b) the value really is universally appropriate. (b) is rarer than people think.

**5. What's the cost shape on my platform?**

A polling loop that's free on a VPS is a line item on Convex, Cloudflare Workers, Vercel Edge, Lambda. Translate the package's behavior into your billing unit. If it's nonzero, log it as a known operational cost so future-you doesn't get blindsided.

**6. Set an alert.**

Most metered platforms let you set usage alerts at, say, 50% and 80% of your tier. Set them. The email I got at 91% should have been a 50% email three weeks earlier.

## The bigger reframing

I used to think of dependencies as a binary: *"I added Sentry, I get error tracking."* The cost was the install size and maybe some abstract "complexity."

Now I think of dependencies as *renting an employee*. They show up on schedules I didn't set, they do work I didn't ask for, they consume resources I'm paying for. Most of the time they're great employees, but I should still know what they're doing during work hours.

`bun patch` is what I'd use to hand them a new schedule. Reading the source is what I'd use to *know* they need one.

## What I'd tell past-me

If I could send one message back to Wednesday-night-me at 11 PM staring at the dashboard:

> *The function eating your budget isn't yours. It's in `node_modules/@convex-dev/persistent-text-streaming/dist/component/crons.js`. It's running every minute because that's the default the maintainer chose. Open that file, read it, then `bun patch` it to run daily. While you're at it, set a 50% usage alert. While you're really at it, audit the other components you use the same way.*

> *And next time, before you `npm install` anything that has the word "component" or "framework" in it, grep its `dist/` for "cron" first.*

Cheap habit. Saves a paycheck.

## References

- [Convex pricing and limits](https://www.convex.dev/pricing)
- [`@convex-dev/persistent-text-streaming` component](https://www.convex.dev/components/persistent-text-streaming)
- [Bun patches — the fix this post references](https://bun.sh/docs/install/patch)
- [A good dependency-evaluation post by Rich Harris (2018, still mostly right)](https://overreacted.io/how-i-bring-my-own-stack-to-talks/)
- [`npm-why` for understanding why a package is in your tree](https://www.npmjs.com/package/npm-why)
- [`bundlephobia` for install-size cost](https://bundlephobia.com/)
- [`socket.dev` for security/risk audits of npm packages](https://socket.dev/)

---

# The Six-File Problem: How I Learned to Stop Orchestrating and Love the Queue

- **URL**: https://www.rafay99.com/blog/the-six-file-problem-how-i-learned-to-stop-orchestrating-and-love-the-queue/
- **Published**: 2026-05-25
- **Author**: Abdul Rafay
- **Tags**: backend, Software Engineer, Convex, Web Development
- **Description**: I didn’t build a CMS — I built an escape route from one. This post tells the story of Wryte, a Markdown-first sync layer between GitHub and Convex, and how six tiny files exposed the real problem with Promise.all, rate limits, and naive bulk processing.

I didn't set out to build a CMS. I set out to escape one.

The project is called Wryte — not WRITE,. GPT-5.4 named it, I kept it. It's a sync layer that sits between GitHub and Convex, letting me write in Markdown, schedule posts, and keep my SEO-friendly static site without surrendering to another bloated headless CMS. I wanted the control of files with the convenience of a database. The in-between space.

What I got was a lesson in humility. Six files broke me.

## The Gap Nobody Fills

Existing CMSs force a false choice. Go full static — GitHub Actions, Python scripts, custom logic for scheduling and drafts — or go full dynamic with APIs and CRM bloat. I was already invested in the static side. My SEO was working. My URLs were clean. But I needed *just enough* dynamism: a place to write, schedule, and push without rewriting my entire platform.

So I built the negotiator. Wryte imports my Markdown, lets me edit with AI assistance (bring your own API key), and syncs back to GitHub when I'm ready. Convex handles the reactive layer. GitHub remains the source of truth. Everyone stays in their lane.

Except when they don't.

## The Choke

I was testing imports. Six Markdown files. Small files, nothing exotic. I hit the button and watched my system collapse.

The problem wasn't the files. It was `Promise.all`.

```ts
// DON'T DO THIS — seriously, don't
const results = await Promise.all(
  filePaths.map((path) => importFile({ projectId, filePath: path }))
);
```

Looks innocent, right? Maps over paths, fires all imports simultaneously, waits for completion. This is what every tutorial shows you. This is what I thought "concurrent" meant.

I had two invisible walls. `Promise.all` sprinted into both.

**First: my own rate limiting.** I configured Convex with a 200-call bucket to protect my bill. Six files shouldn't touch that. But `Promise.all` doesn't *pace* — it *floods*. Each import triggered multiple internal calls. The bucket drained. Requests failed with `RateLimited` errors that weren't even from GitHub. They were from *me*, protecting myself from myself.

**Second: GitHub's Content API.** Different bucket, different rules, same result. My action timed out. The ceiling hit back.

The error messages were lying to me. They said "rate limit" but the real problem was *shape*. I was treating a distributed system like a local loop.

I tried the sequential fix. A `for` loop with retries, stepping through files one by one, backing off when rate limited. It worked. It was also *wrong* — slow, brittle, and fundamentally misunderstanding the problem. I wasn't importing files. I was performing surgery with a spoon. Eight minutes for 200 files. That's not "bulk import." That's "go make tea import."

## The Wrong Fix (That I Actually Shipped)

Here's what I wrote. It hurts to look at now.

```ts
// Attempt 2: sequential with retry — DO NOT SHIP THIS
for (const filePath of filePaths) {
  let attempts = 0;
  while (attempts < 3) {
    try {
      await importFile({ projectId, filePath });
      break; // success, move to next
    } catch (err) {
      if (isRateLimitError(err)) {
        attempts++;
        await sleep(Math.pow(2, attempts) * 1000); // exponential backoff, manually
        continue;
      }
      throw err; // real error, give up
    }
  }
}
```

This "worked." It imported files. It respected rate limits. It was also:

- **Blocking**: The HTTP request stayed open for minutes. Browsers kill those.
- **Fragile**: One unhandled error killed the whole batch, leaving partial state.
- **Unobservable**: The user saw a spinner. No progress. No "3 of 200." Just... waiting.

I shipped this. I'm not proud. But it got me to the next problem, which is how these things go.

## Finding Workpool (By Accident)

I was complaining in the Convex Discord — something I do a lot — and someone mentioned "Workpool." I thought it was a library I'd have to wire up. It's not. It's a **component**, which in Convex means you configure it, register it, and it becomes part of your infrastructure.

The mental shift: I wasn't writing a loop anymore. I was declaring *policy*.

```ts
// convex/_pools/import.ts

  maxParallelism: 5,
  retryActionsByDefault: true,
  defaultRetryBehavior: {
    maxAttempts: 3,
    initialBackoffMs: 1500,
    base: 2,
  },
});
```

Five parallel workers. Three retries. Exponential backoff starting at 1.5 seconds, doubling each time. The policy *is* the code. No manual orchestration, no sleep loops, no guessing.

But here's the part that took me too long to understand: **the pool is shared infrastructure.** Every user enqueues into the same pool. That `maxParallelism: 5` is global, not per-user. This is actually what I wanted — it protects GitHub's API from me, and me from my users — but it means you have to think about fairness. One user importing 10,000 files would starve everyone else. I added a 200-file cap later. For now, five-at-a-time felt right.

Register it in `convex.config.ts`:

```ts
const app = defineApp();
app.use(workpool, { name: "githubImportPool" });

```

That's the entire setup. The complexity doesn't disappear — it gets *absorbed*.

## The Coordinator Pattern

Now I had to unlearn how I thought about actions. My old mental model: "an action is a function that does work and returns a result." The new model: **an action is a short-lived coordinator that fans out work to a durable queue, then exits.**

Here's `startBulkImport`. I'm going to walk through it piece by piece because this took me multiple tries to get right.

```ts
// convex/integrations/github.ts

  args: {
    projectId: v.id("projects"),
    filePaths: v.array(v.string()),
  },
  handler: async (ctx, args): Promise<{ batchId: Id<"import_batches"> }> => {
```

First: this is an `action`, not a `mutation`. In Convex, mutations run in a deterministic sandbox and can't do arbitrary HTTP. Actions can. They spin up a Node.js environment, can use libraries like Octokit, and — crucially — can enqueue workpool jobs. If you're doing bulk operations that touch external APIs, you probably want an action.

```ts
    const key = await getRateLimitKey(ctx);
    await rateLimiter.limit(ctx, "documents:startBulkImport", {
      key,
      throws: true,
    });
```

Rate limiting happens *first*, before any work. This protects the enqueue operation itself. I'm using the Convex Rate Limiter component with a user-scoped key. `throws: true` means failed limit = hard error to the client. The user sees "too many requests" immediately, not a stuck import later.

```ts
    const uniquePaths = [...new Set(args.filePaths)];
```

Dedup at the boundary. The UI might send duplicates — multi-select bugs, "select all" overlapping folders, double-submit. If I didn't do this, `total` would be wrong and the progress bar would never complete. One job per path, guaranteed here.

```ts
    const user = await ctx.runQuery(internal.account.users.internalGetByToken, {
      tokenIdentifier: /* ... */,
    });
    const project = await ctx.runQuery(internal.cms.projects.internalGet, {
      projectId: args.projectId,
    });
    if (!project || project.userId !== user._id) {
      throw new Error("Unauthorized");
    }
```

This is the auth boundary, and it's critical. Workpool jobs run later, without a user session. They can't call `ctx.auth.getUserIdentity()` because there's no HTTP request context. So I verify ownership *once*, here, in the coordinator. Then I pass `projectId` into each job, and the jobs trust that `projectId` was validated.

I learned this the hard way. My first version tried to re-auth inside the job. It failed silently because `ctx.auth` was undefined. The docs mention this, but not loudly enough. **Coordinator verifies, workers execute.**

```ts
    const batchId = await ctx.runMutation(internal.cms.documents._createImportBatch, {
      projectId: args.projectId,
      userId: user._id,
      total: uniquePaths.length,
    });
```

Create the tracking row. This is a `runMutation` because actions can't directly write to the database — they call mutations for that. The `import_batches` table stores:

- `projectId`, `userId`: ownership
- `total`: denominator for progress
- `createdAt`: metadata

In my *actual* production code, this happens *after* a classification step. I fetch the GitHub tree first, compare SHAs, and only enqueue files that are new or changed. So `total` reflects real work, not just "files you selected." But the pattern is the same: create the batch row, then enqueue.

```ts
    for (const filePath of uniquePaths) {
      await importPool.enqueueAction(
        ctx,
        internal.integrations.github._importOneFromGithubJob,
        { projectId: args.projectId, filePath, batchId },
        { onComplete: internal.cms.documents._onImportFileComplete },
      );
    }

    return { batchId };
  },
});
```

Here's the magic. The `for` loop awaits each `enqueueAction`, but **enqueueing is not executing**. It's registering a job with the pool. Registration is fast — milliseconds. The loop finishes quickly, the action returns `{ batchId }`, and the HTTP response completes.

Meanwhile, the workpool is running up to 5 jobs in parallel, asynchronously, potentially over minutes. When each job finishes — success or failure — it calls `onComplete: _onImportFileComplete`.

The coordinator exits. The pool owns the lifecycle now.

## The Worker and the Callback

Two more pieces. First, the worker itself:

```ts
// convex/integrations/github.ts (internal action)

  args: {
    projectId: v.id("projects"),
    filePath: v.string(),
    batchId: v.id("import_batches"),
  },
  handler: async (ctx, args) => {
    // Fetch from GitHub using Octokit
    const content = await fetchGithubFile(args.filePath);
    
    // Parse frontmatter, validate
    const parsed = parseMarkdown(content);
    
    // Insert or update document
    await ctx.runMutation(internal.cms.documents._upsertFromImport, {
      projectId: args.projectId,
      filePath: args.filePath,
      frontmatter: parsed.frontmatter,
      body: parsed.body,
    });
    
    // Return success — Workpool catches this for onComplete
    return { success: true };
  },
});
```

This runs in the pool's concurrency slot. If it throws, Workpool retries up to 3 times with exponential backoff. If it still fails, the `onComplete` fires with an error.

Now the callback:

```ts
// convex/cms/documents.ts

  args: {
    batchId: v.id("import_batches"),
    filePath: v.string(),
    success: v.boolean(),
    errorMessage: v.optional(v.string()),
  },
  handler: async (ctx, args) => {
    await ctx.db.insert("import_job_outcomes", {
      batchId: args.batchId,
      filePath: args.filePath,
      status: args.success ? "success" : "failure",
      errorMessage: args.errorMessage,
      createdAt: Date.now(),
    });
  },
});
```

This is where I got burned. My first version tried to `patch` the `import_batches` row directly:

```ts
// DON'T DO THIS — OCC hell
const batch = await ctx.db.get(args.batchId);
await ctx.db.patch(args.batchId, {
  succeeded: batch.succeeded + 1,
});
```

Five jobs finishing within milliseconds. All reading the same row, all computing `succeeded + 1`, all trying to write. Convex's optimistic concurrency control says: *no, you can't all win.* Retry storms. Latency spikes. Jobs failing after retries exhausted.

The fix: **don't write to a hot row.** Each callback inserts its *own* row into `import_job_outcomes`. Inserts to different rows don't contend. Zero OCC conflicts.

## The Reactive Query (No Polling, Finally)

Client-side:

```tsx
const [batchId, setBatchId] = useState | null>(null);

const batch = useQuery(
  api.cms.documents.getImportBatch,
  batchId ? { batchId } : "skip",
);

const handleImport = async () => {
  const result = await startBulkImport({ projectId, filePaths });
  setBatchId(result.batchId); // subscribe immediately
};
```

The query:

```ts

  args: { batchId: v.id("import_batches") },
  handler: async (ctx, args) => {
    const batch = await ctx.db.get(args.batchId);
    if (!batch) return null;

    // Aggregate on read — no hot row updates
    const outcomes = await ctx.db
      .query("import_job_outcomes")
      .withIndex("by_batchId", (q) => q.eq("batchId", args.batchId))
      .collect();

    let succeeded = 0;
    let failed = 0;
    for (const o of outcomes) {
      if (o.status === "success") succeeded++;
      else failed++;
    }

    return { ...batch, succeeded, failed };
  },
});
```

Every `insert` into `import_job_outcomes` invalidates this query. The UI re-renders. Progress bar updates. No `setInterval`, no manual refetch, no "Refresh" button.

For 200 rows, `collect()` is fine. If I ever hit 10,000, I'd switch to `@convex-dev/aggregate`. For now, this is unmeasurable noise.

****
## What I Actually Learned

Three rewrites for one feature. That's not unusual; that's the job. But the pattern — **coordinator + workpool + per-job outcomes + reactive read** — is reusable. I used it for bulk delete, for bulk publish, for a Git sync operation that reconciles hundreds of files.

The specific technologies matter less than the shape. You could build this on AWS Step Functions, or Temporal, or a Postgres queue with a worker pool. The insight is: **don't orchestrate, declare.** Specify your constraints and let infrastructure enforce them.

Six files broke me. Two hundred files proved the fix. Wryte is still personal, still free, still weirdly named by a language model. But now it imports without drama, and I understand something I thought I already knew: the best code is the code you don't have to write, and the best orchestration is the kind that disappears.

---

# What Building Lumo Taught Me About Full-Stack Development

- **URL**: https://www.rafay99.com/blog/lumo-lessons-learned-full-stack-finance-app/
- **Published**: 2026-05-07
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess, MobileDevelopment, WebDevelopment
- **Description**: The final post in the Lumo series — lessons learned, mistakes I'd avoid, and what's next for the project after months of building.

Eight blog posts. Months of development. 20,000+ lines of backend code. 30+ database tables. A mobile app, a marketing site, an admin dashboard, and more late nights than I care to admit.

Lumo started as a frustrated rant about bad finance apps and grew into the most complex thing I've ever built. And now, at the end of this series, I want to be honest about what went right, what went wrong, and what I'd do differently if I started over tomorrow.

This is not a success story wrapped in a bow. This is a developer looking back at months of work and saying: "Here's what I actually learned."

# What Went Right

## 1. The Monorepo Decision

Putting everything in one Turborepo monorepo was the best architectural decision I made. Period.

Shared TypeScript types between the backend and all three frontends eliminated an entire category of bugs. When I changed a field in the Convex schema, TypeScript errors appeared in the mobile app, the web app, and the admin panel simultaneously. No "oh, I forgot to update the mobile app" moments.

Shared configs (Biome, TypeScript) meant consistent code quality everywhere. One linting rule, one formatting style, three apps. And Bun workspaces made dependency management trivial — `@lumo/backend` is just a workspace reference, no publishing or linking needed.

If you're building multiple apps that share a backend? Monorepo. Don't even think about it. Just do it.

## 2. Convex for Real-Time

Despite the learning curve, Convex was the right choice for Lumo. Real-time budget updates, live transaction sync across devices, instant prediction invalidation — all of this would've been a massive undertaking with a traditional REST API + WebSocket setup.

The atomic mutations saved me from data integrity bugs multiple times. Financial data needs to be consistent, and Convex's transactional guarantees delivered that without me writing rollback logic.

## 3. Early Admin Tooling

Building the admin dashboard early (instead of postponing it like I originally planned) paid dividends every single day. Debugging user issues, monitoring system health, toggling features — all from a browser. No SSH, no scripts, no manual database queries.

## 4. Story-Driven Development

I didn't build Lumo from a spec. I built it from stories. "As a person with a freelance side gig, I want my budget to account for biweekly payments." Each feature was driven by a real use case, not a theoretical requirement.

This kept the features grounded. No feature bloat. No "we might need this someday." Every screen, every mutation, every database table exists because a real scenario demanded it.

# What Went Wrong

## 1. I Didn't Test Enough

This is the big one. I've said it in previous posts, and I'll say it again: Lumo's test coverage is not where it should be.

The backend has decent test coverage — budget calculations, income logic, prediction models all have test suites. But the mobile app? The web app? Mostly untested. I relied too heavily on manual testing and "it works on my device."

The cost of this hit me hard when I refactored the budget calculation logic. I changed one function, ran the backend tests (they passed), deployed, and then realized the mobile app was displaying the wrong available balance because a hook was calling a slightly different code path that wasn't tested.

**Lesson: test the integration, not just the units.** Backend tests passing doesn't mean the app works.

## 2. I Over-Abstracted Early

In the first few weeks, I was obsessed with making everything reusable. Generic form components. Abstract data fetching hooks. A shared validation library. The works.

Turns out, most of that abstraction was premature. I built a "generic income form" that handled salary, freelance, investment, and one-time income. It was a monster — 400 lines with conditional rendering based on the income type. When I needed to change the freelance form, I had to carefully navigate the abstraction without breaking the salary form.

Eventually I split it into four simple forms. Each one was 80 lines, easy to read, easy to modify, completely independent. The total code was more, but the complexity was less.

**Lesson: duplication is cheaper than the wrong abstraction.** Wait until you have three real use cases before abstracting.

## 3. JavaScript Numbers for Money

I mentioned this in the security post, but it deserves its own callout. I'm using `float64` for all financial amounts. Dollar amounts. Budget totals. Loan balances.

So far, it hasn't caused visible issues. $50.10 stores as $50.10, not $50.09999999999. But that's luck, not correctness. Floating-point arithmetic _will_ bite eventually. Someone will add three transactions of $33.33 and the total will be $99.99 or $100.00 instead of the exact $99.99 they expect.

The right approach is to store amounts in integer cents (5010 instead of 50.10) and format for display. I know this. I should've done this from the start. Now it's a migration I'm dreading.

**Lesson: use integer cents for money. Always. From day one.**

## 4. No CI/CD for Mobile

The web app deploys automatically through Vercel on every push to main. The Convex backend deploys with a single command. But the mobile app? That requires manually triggering an EAS build, waiting 20 minutes, downloading the APK/IPA, and testing.

I should've set up automated mobile builds from the beginning. Every merge to main should produce a test build. Every release tag should produce a production build. The infrastructure exists (EAS + GitHub Actions), I just never prioritized it.

**Lesson: automate your mobile builds early.** Manual build processes don't scale, even for a solo developer.

# The Numbers

Let me get specific about the codebase size, because people always ask:

| Component | Lines of Code | Files |
|-----------|:---:|:---:|
| Convex Backend | ~20,600 | 40+ |
| Mobile App | ~8,700 | 80+ |
| Marketing Website | ~6,900 | 50+ |
| Admin Dashboard | ~4,000 | 35+ |
| Shared Config | ~500 | 10+ |
| **Total** | **~40,700** | **215+** |

That's 40,000 lines of TypeScript across four apps, one backend, and shared configuration. For a side project. Built mostly by one person. With a lot of help from AI copilots (let's be honest).

The database has 30+ tables, 100+ functions (queries + mutations), 4 cron jobs, and 3 workflows. The mobile app has 20+ screens. The admin panel has 18 routes.

It's a real codebase. And maintaining it solo is... a lot.

# What I'd Do Differently

If I started Lumo from scratch today:

1. **Integer cents from day one.** No float64 for money. Ever.

2. **Test-first for financial logic.** Every budget calculation, every income conversion, every prediction model should have tests written _before_ the implementation.

3. **Smaller initial scope.** I'd launch with just transactions and budget cycles. No predictions, no loans, no income streams, no admin panel. Get the core right, then add features based on actual usage.

4. **CI/CD for everything from week one.** Web, backend, and mobile — all automated. No manual deployment steps.

5. **Design system before screens.** I spent too much time tweaking individual screens instead of building a consistent component library first. (I suck at UI, which makes this doubly important.)

6. **More writing, sooner.** This blog series should've started when I started building. The process of writing about decisions forces you to think them through properly. Half the architectural improvements I made came from trying to explain the old approach in a blog post and realizing it was bad.

# What's Next for Lumo

Lumo isn't done. Not by a long shot. Here's what's on the roadmap:

- **Receipt scanning improvements** — The AI extraction works, but the accuracy could be better. Exploring fine-tuned models for common receipt formats.
- **Recurring transactions** — Subscriptions, rent, bills that happen every month. Right now you have to add them manually each time.
- **Goal tracking** — "Save $5,000 by December" with progress visualization.
- **Partner/family mode** — Shared budgets between two people.
- **End-to-end encryption** — Because financial data deserves it.
- **Proper mobile CI/CD** — Automated builds on every merge.
- **Integer cents migration** — The float64 reckoning is coming.

Some of these are small features. Some are massive undertakings. But that's the beauty of having your own project — you get to decide what matters and when.

# The Real Lesson

Here's the thing nobody tells you about side projects: **the project isn't the point.**

Lumo taught me more about full-stack development in a few months than years of professional work. Not because professional work isn't educational — but because when it's your project, you make every decision. You face every consequence. You can't hand off the hard parts to another team.

I learned Convex by hitting its cache limits. I learned React Native by fighting its keyboard behavior. I learned about financial calculations by getting them wrong three times. I learned about security by imagining the worst-case scenarios and building against them.

Every bug was a lesson. Every rewrite was an improvement. Every late night was worth it — not because Lumo will make me rich, but because it made me a better engineer.

# Thank You

If you've followed this entire series — from the [origin story](/blog/lumo-building-a-personal-finance-app-from-scratch) to the [budget cycle system](/blog/lumo-budget-cycle-system-that-broke-my-brain) to [Convex adventures](/blog/lumo-convex-realtime-backend-love-and-pain) to [income management](/blog/lumo-multi-income-budget-math-nightmare) to [AI predictions](/blog/lumo-ai-spending-predictions-that-actually-work) to [mobile architecture](/blog/lumo-react-native-mobile-app-architecture) to the [admin dashboard](/blog/lumo-admin-dashboard-internal-tools-that-dont-suck) to [security](/blog/lumo-security-subscriptions-device-sessions) — thank you. Genuinely.

Writing about your own code is vulnerable. You're showing the world your decisions, your mistakes, your thought process. But it's also the most rewarding kind of technical writing. Because it's real. Not a tutorial from a docs page. Not a contrived example. Real code that solves real problems for real people.

If you're building something — anything — consider writing about it. Not for the audience. For yourself. The act of explaining forces understanding. And understanding is what turns code into craft.

Now, if you'll excuse me, I have a float64-to-integer-cents migration to plan. Wish me luck.

Until then — and I mean this from the bottom of my terminal — keep building, keep writing, and keep shipping, nerds. ❤️❤️

---

# Device Sessions, Rate Limiting, and Not Getting Hacked

- **URL**: https://www.rafay99.com/blog/lumo-security-subscriptions-device-sessions/
- **Published**: 2026-05-04
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess, WebDevelopment
- **Description**: How Lumo handles security for a finance app — device approval workflows, multi-tier rate limiting, subscription management, and data privacy.

Here's a fun thought experiment: you've built a personal finance app. People are entering their spending data, income information, loan records — basically a complete financial diary. Now ask yourself:

**What happens when someone's phone gets stolen?**

This question kept me up at night more than any bug or feature ever did. Because getting security wrong in a finance app isn't just embarrassing — it's a violation of trust. People are giving you their most sensitive data. You better protect it.

Let me walk you through how Lumo handles security, from device management to rate limiting to data privacy.

# Device Sessions: The Approval Workflow

Most apps just... let you log in. Enter your email, enter your password, you're in. Maybe there's 2FA. But for a finance app where someone might check their budget on their phone, their tablet, and their partner's phone? We need something more thoughtful.

Lumo uses a device session system. Every device that accesses your account gets its own session, and new devices require approval.

Here's the flow:

1. You log in on your phone (Device A). This becomes your primary device.
2. You log in on a tablet (Device B). Instead of getting immediate access, Device B enters a "pending" state.
3. Device A gets a push notification: _"A new device wants to access your account. Approve or deny?"_
4. You tap Approve on Device A. Device B is now active.

If you tap Deny? Device B gets kicked out. And the attempt is logged in the security audit trail.

```typescript
// Device session schema
deviceSessions: defineTable({
  userId: v.id("users"),
  deviceId: v.string(),           // Unique device fingerprint
  sessionToken: v.string(),       // Hashed session token
  status: v.union(
    v.literal("pending"),
    v.literal("active"),
    v.literal("revoked")
  ),
  deviceName: v.optional(v.string()),
  platform: v.optional(v.string()),
  lastSeen: v.string(),
  createdAt: v.string(),
})
```

The `deviceId` is a fingerprint generated from device characteristics — model, OS version, a random UUID stored in secure storage. It's not perfect (factory resets generate a new ID), but it's good enough to distinguish between devices.

The `sessionToken` is hashed and stored. The raw token lives on the device. Every API call includes this token for validation. If the token doesn't match or the session is revoked, the request fails.

## The Lost Phone Problem

Okay, but what if Device A — your primary device — gets lost? You can't approve new devices if you can't access the approving device.

Enter recovery codes. When you set up Lumo, the app generates a set of one-time recovery codes:

```typescript
// Generate recovery codes during account setup
function generateRecoveryCodes(): string[] {
  const codes: string[] = [];
  for (let i = 0; i < 8; i++) {
    // 8-character alphanumeric codes
    codes.push(
      crypto.randomBytes(4).toString('hex').toUpperCase()
    );
  }
  return codes;
}
```

Eight codes. Write them down. Store them somewhere safe. If you lose all your devices, you can use a recovery code to authenticate a new device without the approval workflow.

Each code is one-time use. Use it, and it's consumed. Run out of codes? Contact admin (me) for a manual device override — which is logged in the security events table for accountability.

Is this overkill for a personal finance tracker? Maybe. But when I think about someone losing their phone and panicking about their financial data being exposed, I'd rather be over-cautious.

# Rate Limiting: The Three Layers

Rate limiting in Lumo works on three layers:

## Layer 1: Global Rate Limits

Public endpoints — contact forms, waitlist signups, blog comments — have global rate limits. These prevent spam attacks that aren't tied to any user:

```typescript
// Global rate limits for public endpoints
const globalLimits = {
  "contact-form": { 
    rate: 5, 
    period: HOUR,
    capacity: 10 
  },
  "feature-request": { 
    rate: 3, 
    period: HOUR, 
    capacity: 5 
  },
  "blog-comment": { 
    rate: 10, 
    period: HOUR, 
    capacity: 20 
  },
};
```

Using `@convex-dev/rate-limiter`, which integrates directly into Convex mutations. One line to check, one line to consume a token.

## Layer 2: Per-User Rate Limits

Authenticated endpoints have per-user limits. This prevents a single user (or a compromised account) from hammering the API:

```typescript
// Per-user limits for authenticated endpoints
const userLimits = {
  "add-transaction": { 
    rate: 30, 
    period: MINUTE, 
    capacity: 60 
  },
  "receipt-scan": { 
    rate: 5, 
    period: HOUR, 
    capacity: 10 
  },
  "prediction-refresh": { 
    rate: 3, 
    period: HOUR, 
    capacity: 5 
  },
};
```

30 transactions per minute might sound high, but CSV imports can add transactions in bulk. The receipt scan limit is tighter because each scan calls an external AI API (Google Gemini) that costs money.

## Layer 3: Feature Usage Limits (Subscription Tiers)

This is where rate limiting meets business model. Free users get limited access to premium features:

```typescript
// Feature limits per tier (stored in database, not hardcoded)
// Free tier example:
{
  "receipt-scans": { monthly: 5 },
  "prediction-refreshes": { monthly: 10 },
  "transactions": { monthly: 200 },
  "income-streams": { total: 2 },
  "loans": { total: 5 },
}

// Pro tier:
{
  "receipt-scans": { monthly: 50 },
  "prediction-refreshes": { monthly: 100 },
  "transactions": { monthly: -1 },  // unlimited
  "income-streams": { total: -1 },
  "loans": { total: -1 },
}
```

These limits are stored in the `featureLimits` table — not hardcoded. I can adjust limits without redeploying. Usage is tracked in a `usageTracking` table that resets monthly.

The check function:

```typescript
async function checkFeatureAccess(
  ctx: QueryCtx,
  userId: Id<"users">,
  feature: string
): Promise<{ allowed: boolean; remaining: number }> {
  const tier = await getUserEffectiveTier(ctx, userId);
  const limits = await getFeatureLimits(ctx, tier, feature);
  const usage = await getCurrentUsage(ctx, userId, feature);
  
  if (limits.monthly === -1) {
    return { allowed: true, remaining: Infinity };
  }
  
  const remaining = limits.monthly - usage.count;
  return { 
    allowed: remaining > 0, 
    remaining: Math.max(0, remaining) 
  };
}
```

When a user hits their limit, the mobile app shows a friendly message: _"You've used all 5 receipt scans this month. Upgrade to Pro for 50 per month!"_ Not a hard error — a gentle upsell.

# Subscription Management

Lumo has three tiers: **Free**, **Pro**, and **Beta** (a special tier for testers that unlocks everything).

New users get a 7-day trial of Pro features. After that, they drop to Free unless they upgrade. The trial system has its own set of quirks:

```typescript
// Effective tier calculation with trial/promo overrides
async function getUserEffectiveTier(
  ctx: QueryCtx,
  userId: Id<"users">
): Promise<"free" | "pro" | "beta"> {
  const user = await ctx.db.get(userId);
  
  // Beta flag overrides everything
  if (user.isBeta) return "beta";
  
  // Check active subscription
  if (user.tier === "pro") return "pro";
  
  // Check trial period
  if (user.trialEndsAt && new Date(user.trialEndsAt) > new Date()) {
    return "pro";  // Trial gives Pro access
  }
  
  // Check promotional access
  if (user.promoEndsAt && new Date(user.promoEndsAt) > new Date()) {
    return "pro";
  }
  
  return "free";
}
```

The trial expiry is handled by a cron job that runs every hour. It checks users whose trial ended but haven't been downgraded yet, updates their status, and sends a notification: _"Your trial has ended. Upgrade to Pro to keep using all features!"_

The cron caps at 100 users per run to avoid overloading the system. If 500 trials expire on the same day (unlikely but possible), it takes 5 hours to process them all. That's acceptable — a few hours delay in downgrading isn't going to hurt anyone.

# Data Privacy: GDPR and the Right to Disappear

When a user wants to delete their account, everything goes. And I mean _everything_.

```typescript
// Delete all user data — chunked for reliability
async function deleteAllUserData(
  ctx: MutationCtx,
  userId: Id<"users">
) {
  const CHUNK_SIZE = 50;
  
  // Tables to purge (in dependency order)
  const tables = [
    "loanTransactions",
    "loans",
    "paymentHistory",
    "incomeStreams",
    "transactions",
    "cycleSavings",
    "cycleState",
    "predictionCache",
    "notifications",
    "deviceSessions",
    "deviceSecurityEvents",
    "pushTokens",
    "usageTracking",
    "feedback",
    "onboarding",
  ];
  
  for (const table of tables) {
    let records;
    do {
      records = await ctx.db
        .query(table)
        .withIndex("by_user", (q) => q.eq("userId", userId))
        .take(CHUNK_SIZE);
      
      for (const record of records) {
        await ctx.db.delete(record._id);
      }
    } while (records.length === CHUNK_SIZE);
  }
  
  // Finally, delete the user record itself
  await ctx.db.delete(userId);
}
```

Chunked deletion — 50 records at a time — prevents Convex function timeouts. For a user with thousands of transactions, this might take a few mutation rounds, but it eventually gets everything.

The key here is the table ordering. Loan transactions before loans. Payment history before income streams. Delete the dependencies first, then the parents. Otherwise you get orphaned records.

After deletion, the user's data is gone. Not soft-deleted. Not archived. **Gone.** Because that's what "delete my data" should mean.

# The Security Audit Trail

Every security-relevant action is logged:

```typescript
deviceSecurityEvents: defineTable({
  userId: v.id("users"),
  eventType: v.string(),  // "device_approved", "device_denied", 
                           // "recovery_code_used", "admin_override"
  deviceId: v.optional(v.string()),
  metadata: v.optional(v.string()),
  timestamp: v.string(),
  source: v.string(),      // "user", "admin", "system"
})
```

This gives me a timeline: when was a device added? Who approved it? Was a recovery code used? Did an admin override a session? Everything is traceable.

The admin dashboard has a dedicated page for viewing these events, filtered by user. When someone reports suspicious activity, I can pull up the full timeline of what happened and when.

# What Keeps Me Up at Night

Despite all these measures, security is never "done." Here are things I still worry about:

1. **Token theft**: If someone extracts the session token from a device's secure storage, they can impersonate that device. Mitigated by the heartbeat system (inactive tokens expire) but not eliminated.

2. **JavaScript numbers for money**: I'm using `float64` for financial amounts. Yes, I know about floating-point precision issues. For a budgeting app where we're dealing with dollars and cents (not fractional pennies), it hasn't been a problem. But it's a ticking time bomb I should address with integer cents or a decimal library.

3. **No end-to-end encryption**: Financial data is encrypted in transit (HTTPS) and at rest (Convex's infrastructure), but I can see it in the admin dashboard. True E2E encryption would prevent even me from reading user data. It's on the roadmap, but it adds significant complexity.

4. **Rate limit bypass**: Sophisticated attackers could create multiple accounts to bypass per-user limits. For a personal finance app with no payment processing, the attack surface is low, but it's not zero.

Security is a spectrum, not a checkbox. Every measure I've built is "good enough for now" — but the definition of "good enough" keeps changing as the stakes get higher.

# Final Thoughts

Building security for a finance app taught me that **trust is your product**. Users don't just trust your app to be functional — they trust it to be safe. Every decision, from the device approval workflow to the data deletion process, is a trust-building exercise.

The unglamorous truth is that most of this work is invisible. Users never see the rate limiter. They never think about the security audit trail. They never appreciate the chunked deletion logic. But they _feel_ the safety. They feel comfortable entering their salary. They feel okay recording their loan to a friend. And that feeling? That's the product.

Next up — the final post in this series: what I learned from building Lumo, the mistakes I'd avoid next time, and what's coming next for the project.

Until then, hash your tokens and limit your rates, nerds. 🔒

---

# The Admin Dashboard Nobody Sees (But Everything Needs)

- **URL**: https://www.rafay99.com/blog/lumo-admin-dashboard-internal-tools-that-dont-suck/
- **Published**: 2026-04-30
- **Author**: Abdul Rafay
- **Tags**: WebDevelopment, ThoughtsProcess
- **Description**: How I built Lumo's internal admin panel with Vite, TanStack Router, and Radix UI — and why every serious app needs internal tooling from day one.

Let me tell you a secret about every app you use: behind the pretty UI you see, there's an ugly admin panel that the developers use to keep things running. User management, error logs, config toggles, content moderation — all the unglamorous stuff that makes the glamorous stuff possible.

When I started building Lumo, the admin dashboard was an afterthought. "I'll build it when I need it." Famous last words. Within two weeks of having real test data, I needed to:

- Check why a user's budget wasn't calculating correctly
- Toggle the prediction model version
- Look at error logs without SSH-ing into anything
- See how many users were hitting rate limits

I needed an admin panel. And I needed it yesterday.

# Why Not Just Use the Convex Dashboard?

Convex has a built-in dashboard. It's actually quite good — you can browse tables, run functions manually, view logs. For basic database operations, it works.

But it's a generic tool. It doesn't know that when I'm debugging a user's budget issue, I need to see their transactions, income streams, cycle state, and loan summary all on one screen. It doesn't have a "recalculate this user's predictions" button. It doesn't show me analytics charts of daily signups.

Custom admin tools are about _workflows_, not just data access. The Convex dashboard gives me data. My admin panel gives me the ability to act on it.

# The Tech Stack Choice

For the admin panel, I went with a completely different setup than the marketing site:

- **Vite** — No SSR needed, no SEO, just a fast SPA
- **React 19** — Latest and greatest
- **TanStack Router** — Type-safe file-based routing
- **Radix UI** — Accessible component primitives
- **Recharts** — Data visualization
- **Zustand** — Lightweight state management

Why not Next.js like the marketing site? Because the admin panel doesn't need server-side rendering. It doesn't need SEO. It doesn't need static generation. It's an internal tool that only I use. Vite gives me sub-second hot reload, and TanStack Router gives me type-safe routes without the overhead of a full framework.

The admin panel runs on port 3001 alongside the main site on 3000 and the Convex backend. One `bun run dev` starts everything through Turborepo.

# The Route Structure

TanStack Router uses file-based routing with code generation. Here's the route map:

```
src/routes/
├── __root.tsx              # Auth guard, sidebar layout
├── index.tsx               # Dashboard overview
├── users/index.tsx         # User management
├── subscriptions/index.tsx # Tier & trial management
├── predictions/index.tsx   # Model config, accuracy
├── analytics/index.tsx     # Charts and metrics
├── errors/index.tsx        # Error log browser
├── feedback/index.tsx      # User feedback
├── feature-requests/index.tsx
├── comments/index.tsx      # Blog comment moderation
├── contacts/index.tsx      # Contact form submissions
├── rate-limits/index.tsx   # Rate limit violations
├── device-access/index.tsx # Device session management
├── developer-tools/index.tsx
├── migrations/index.tsx    # Data migration runner
├── notifications/index.tsx # Push notification tester
├── builds/index.tsx        # EAS build history
└── waitlist/index.tsx      # Waitlist signups
```

Eighteen routes. For an "internal tool." Yeah, it grew.

# The Pages That Matter Most

Let me walk through the pages I use daily:

## User Management

The users page is where I spend most of my admin time. It shows a searchable list of all users with their subscription tier, trial status, last active date, and device count.

Clicking a user opens their detail view: current cycle state, recent transactions, active income streams, outstanding loans, prediction accuracy, and feature usage. Everything I need to debug "my budget is wrong" in one screen.

Key actions available:
- Adjust subscription tier (free → pro)
- Extend trial period
- Grant promotional access
- Override device sessions
- View security event log

## Prediction Model Control

This page lets me toggle between prediction model V1 and V2, view the accuracy metrics for each, and trigger bulk recalculations.

There's a comparison view that shows V1 vs V2 predictions for the same user data — useful for validating that V2 is actually better before switching everyone over.

The bulk recalculation button processes all users in batches (100 per run, to respect Convex function timeouts). The page shows the recalculation progress and any errors that occurred.

## Error Log Browser

Every server-side error in Lumo gets logged to the `errors` table with:
- Error message and stack trace
- Which function threw it
- The user who triggered it (if applicable)
- Request context (platform, app version)
- Severity level

The admin page shows these in reverse chronological order with filtering by severity, source, and date range. I can click any error to see the full stack trace and context.

This replaced my "SSH into logs and grep" workflow entirely. Everything is in the database, queryable and searchable. It's slower to write than console.log, but infinitely more useful in production.

## Analytics Dashboard

Charts. Everyone loves charts. The analytics page shows:

- **User growth**: Signups per day/week/month
- **Active users**: DAU/WAU/MAU trends
- **Feature usage**: Which features are being used most
- **Transaction volume**: How many transactions are being added daily
- **Prediction accuracy**: How close predictions were to actual spending

Built with Recharts, which is the "just works" charting library for React. Not the most beautiful, not the most performant, but reliable and well-documented.

# The Auth Guard

The admin panel is protected by Firebase Auth with an admin role check. The root layout wraps everything in an auth guard:

```tsx
// routes/__root.tsx

  component: () => {
    const { user, isAdmin, isLoading } = useAdminAuth();
    
    if (isLoading) return ;
    if (!user) return ;
    if (!isAdmin) return ;
    
    return (
      <div className="flex h-screen">
        
        <main className="flex-1 overflow-auto p-6">
          
        </main>
      </div>
    );
  },
});
```

`isAdmin` checks against an environment variable that lists admin user IDs. Not the most sophisticated RBAC, but for a one-person operation? It works. If Lumo ever grows a team, I'll implement proper role-based access. But right now, the only admin is me.

# The Developer Tools I Didn't Expect to Need

Some pages in the admin panel exist because I hit a problem and said "I need a button for this."

**Seed Users**: Creates test users with realistic data — transactions, income streams, loans, predictions. Invaluable for testing new features without messing with real data.

**Migration Runner**: Runs data migrations — backfilling new fields, cleaning up deprecated data, recalculating historical savings. Each migration is a function I can trigger from the UI instead of running scripts manually.

**Notification Tester**: Sends test push notifications to specific devices. Because debugging push notifications by adding real data and waiting for the cron job is... not fun.

**Rate Limit Monitor**: Shows which users are hitting rate limits and how often. Helps me tune the limits — too strict and legitimate users get blocked, too loose and someone spams the API.

# The Design Philosophy: Functional Over Pretty

The admin dashboard is not pretty. It's functional. Every page is a table or a form or a chart. No animations. No gradients. No hero sections. Radix UI gives me accessible, unstyled primitives that I wrap with minimal Tailwind classes.

And that's intentional. This is a tool, not a product. It needs to show me information clearly and let me take actions quickly. Every pixel spent on aesthetics is a pixel not spent on functionality.

That said — it's not _ugly_ either. Consistent spacing, readable typography, clear hierarchy. Just no visual fluff.

```tsx
// A typical admin page component
function UsersPage() {
  const users = useQuery(api.admin.listUsers);
  const [search, setSearch] = useState("");
  
  const filtered = users?.filter(u => 
    u.name?.toLowerCase().includes(search.toLowerCase()) ||
    u.email?.toLowerCase().includes(search.toLowerCase())
  );
  
  return (
    <div>
      <h1 className="text-2xl font-bold mb-4">Users</h1>
      
       setSearch(e.target.value)}
        className="mb-4 max-w-md"
      />
      
      
        
          
            Name
            Email
            Tier
            Trial Ends
            Actions
          
        
        
          {filtered?.map(user => (
            
          ))}
        
      
    </div>
  );
}
```

Tables, inputs, buttons. That's it. And it's exactly what I need.

# Lessons from Building Internal Tools

Here's what I've learned from building (and actually using) an admin dashboard:

**1. Build it early.** I waited too long and spent days debugging issues that would've taken minutes with proper admin tooling. The investment pays for itself immediately.

**2. Every action should be a button.** If you're running a database query manually to check something, that should be a page in your admin panel. If you're executing a script to fix data, that should be a button.

**3. Logging beats debugging.** The error log browser is the most valuable page in the admin panel. Structured error logging to a database table is infinitely better than `console.log` statements you have to find in a log stream.

**4. Don't over-engineer it.** TanStack Router + Radix UI + Zustand is lightweight. No complex state management. No elaborate component library. Just enough structure to build pages quickly and move on.

**5. Dog-food your own admin tools.** I use the admin panel every day. If something is annoying, I fix it immediately. The best admin tools are the ones built by the person who has to use them.

The admin dashboard is the least glamorous part of Lumo. Nobody will ever see it except me. But it's the reason I can run the entire system with confidence. When something breaks, I know within minutes. When a user reports an issue, I can investigate in seconds. When I need to roll out a change, I can monitor the impact in real-time.

Every serious app needs internal tooling. Don't skip it. Don't postpone it. Build it alongside your product, and your future self will thank you.

Next up: the security and subscription system — device sessions, rate limiting, tier management, and how I keep financial data safe without making the app annoying to use.

Until then, build your admin panels with love (and Radix UI), nerds. 🛠️

---

# Building Lumo's Mobile App: React Native Patterns That Don't Suck

- **URL**: https://www.rafay99.com/blog/lumo-react-native-mobile-app-architecture/
- **Published**: 2026-04-27
- **Author**: Abdul Rafay
- **Tags**: MobileDevelopment, ThoughtsProcess
- **Description**: How I structured a React Native finance app with Expo — from screen architecture to custom hooks, real-time sync, and making the app feel native.

I'll be honest — I was a Flutter guy. If you've read my earlier posts, you know I built MS Bridge in Flutter and loved the experience. So choosing React Native for Lumo felt a bit like betraying my first love.

But here's the thing: Lumo's entire backend and web stack is TypeScript. The Convex backend generates TypeScript types. The Next.js site is TypeScript. Sharing types and logic between the backend and the mobile app — without some weird codegen bridge or manual type duplication — was too good to pass up.

So I went React Native with Expo. And after months of building with it, I have thoughts. A lot of them.

# The File-Based Routing Setup

Expo Router uses file-based routing, similar to Next.js. Your file structure _is_ your navigation structure. Here's Lumo's:

```
app/
├── (intro)/              # Onboarding flow (no auth required)
│   ├── _layout.tsx
│   └── index.tsx
│
├── (home)/               # Main app (auth required)
│   ├── _layout.tsx       # Tab navigation wrapper
│   ├── dashboard.tsx     # Home screen
│   ├── transactions.tsx  # Transaction list
│   ├── loans.tsx         # Loan management
│   ├── insights.tsx      # Analytics
│   │
│   └── settings/
│       ├── profile.tsx
│       ├── budget.tsx
│       ├── income.tsx
│       ├── notifications.tsx
│       ├── recovery-codes.tsx
│       ├── upgrade.tsx
│       └── dangerous.tsx   # Data deletion, account ops
```

The `(intro)` and `(home)` groups are layout groups — they don't create URL segments, they just group screens that share a layout. The `(home)` group wraps everything in an auth guard and tab navigation. The `(intro)` group is the unauthenticated onboarding flow.

I like this pattern. It makes the navigation hierarchy visible just by looking at the folder structure. No digging through a 200-line navigation config to figure out which screen goes where.

# The Hook-Driven Architecture

Every screen in Lumo is thin. Like, really thin. The screen component handles layout and UI. All data fetching, mutations, and business logic live in custom hooks.

Here's what the dashboard screen looks like (simplified):

```tsx
// app/(home)/dashboard.tsx

  const { cycleState, isLoading } = useBudgetCycleInfo();
  const { prediction } = usePredictions();
  const { loans } = useLoans("active");
  
  if (isLoading) return ;
  
  return (
    
      
      
      
      
    
  );
}
```

That's it. The screen is a composition of components, each fed by hooks. No API calls in the component. No state management logic. No `useEffect` chains.

The hooks themselves are where the real work happens:

```typescript
// hooks/use-budget-cycle.ts

  const cycleState = useStableQuery(
    api.budget.getCycleState
  );
  
  const available = useMemo(() => {
    if (!cycleState) return 0;
    return cycleState.budget 
      - cycleState.totalSpending 
      - cycleState.outstandingLoans 
      + cycleState.carryover;
  }, [cycleState]);
  
  return {
    cycleState: cycleState ? { ...cycleState, available } : null,
    isLoading: cycleState === undefined,
  };
}
```

See that `useStableQuery`? That's a custom wrapper around Convex's `useQuery` hook that prevents unnecessary re-renders. More on that in a second.

# The Real-Time Sync Story

Convex queries are reactive by default. When you call `useQuery(api.budget.getCycleState)`, the component re-renders whenever the underlying data changes. This is amazing for a finance app — add a transaction on one device, see the budget update on another.

But it comes with a gotcha: **Convex queries can return `undefined` during loading, then re-render with data, then re-render again if the data changes.** In a complex screen with five queries, you get render storms.

I built `useStableQuery` to solve this:

```typescript
// hooks/use-stable-query.ts

  queryFn: any,
  args?: any
): T | undefined {
  const result = useQuery(queryFn, args);
  const stableRef = useRef(result);
  
  // Only update ref when we get non-undefined data
  // This prevents flicker when subscriptions reconnect
  if (result !== undefined) {
    stableRef.current = result;
  }
  
  return stableRef.current;
}
```

The idea is simple: once we have data, don't flash back to `undefined` during reconnections or subscription refreshes. The last known good value stays visible while the new one loads. This prevents the dreaded "loading spinner flash" that makes real-time apps feel janky.

# Component Organization: The Feature Folder Pattern

I organize components by feature, not by type. No `components/buttons/`, `components/cards/`, `components/modals/`. Instead:

```
components/
├── dashboard/
│   ├── BudgetCard.tsx
│   ├── BudgetProgressBar.tsx
│   ├── PredictionCard.tsx
│   └── SpendingChart.tsx
│
├── transactions/
│   ├── TransactionList.tsx
│   ├── TransactionItem.tsx
│   ├── AddTransactionModal.tsx
│   └── TransactionFilters.tsx
│
├── income/
│   ├── IncomeStreamCard.tsx
│   ├── IncomeForm.tsx
│   └── PaymentRecorder.tsx
│
├── loans/
│   ├── LoanList.tsx
│   ├── LoanCard.tsx
│   └── LoanTransactionModal.tsx
│
└── ui/
    ├── Button.tsx
    ├── Input.tsx
    ├── Card.tsx
    ├── Badge.tsx
    └── Spinner.tsx
```

The `ui/` folder is the exception — those are generic, reusable primitives that don't belong to any feature. Everything else lives with the feature it serves.

Why this pattern? When I'm working on the loans feature, every file I need is in `components/loans/`. I'm not jumping between five different folders. And when I delete a feature (it happens), I delete one folder. Clean.

# Making It Feel Native: The Small Things

A finance app needs to feel trustworthy. That means it needs to feel _fast_ and _native_. Here are the small details that make a big difference:

## Haptic Feedback

Every important action gets a haptic response:

```typescript
// Transaction added successfully
Haptics.notificationAsync(
  Haptics.NotificationFeedbackType.Success
);

// Over budget warning
Haptics.notificationAsync(
  Haptics.NotificationFeedbackType.Warning
);

// Delete confirmation
Haptics.impactAsync(
  Haptics.ImpactFeedbackStyle.Heavy
);
```

It's subtle, but it matters. When you record a payment and feel that little buzz, it confirms the action happened. When you try to overspend and feel a warning vibration, it's a physical nudge to reconsider. Finance apps deal with anxiety-inducing actions — haptics help ground them in reality.

## FlashList for Performance

The transaction list can have hundreds (or thousands) of items. React Native's default `FlatList` gets sluggish around 500+ items. I switched to `FlashList` from Shopify:

```tsx
 (
    
  )}
  estimatedItemSize={72}
  keyExtractor={(item) => item._id}
/>
```

The difference is dramatic. Scrolling through 2,000 transactions is butter-smooth. FlashList recycles views aggressively and only renders what's visible. The `estimatedItemSize` hint helps it pre-calculate scroll positions without measuring every item.

## Biometric Lock

A finance app sitting on your phone with no protection? Terrifying. Lumo supports fingerprint and FaceID gating:

```typescript
async function authenticateUser(): Promise<boolean> {
  const hasHardware = await LocalAuthentication
    .hasHardwareAsync();
  
  if (!hasHardware) return true; // No biometrics, skip
  
  const result = await LocalAuthentication
    .authenticateAsync({
      promptMessage: 'Unlock Lumo',
      fallbackLabel: 'Use Passcode',
      disableDeviceFallback: false,
    });
  
  return result.success;
}
```

This runs when the app comes to foreground. Quick FaceID scan, and you're in. No PIN to remember. No pattern to draw. Just your face or your finger.

# The Onboarding Flow

First impressions matter, especially for a finance app where you're asking people to trust you with their money data.

Lumo's onboarding is a multi-step wizard:

1. **Welcome** — What Lumo does and why
2. **Financial Goal** — What are you trying to achieve? (Save more? Track spending? Pay off debt?)
3. **Budget Setup** — Set your cycle start day and initial budget
4. **Categories** — Pick the spending categories you use
5. **First Transaction** — Add one transaction to see how it works

Each step is its own component with validation. You can go back and change things. The whole flow takes about 60 seconds.

The key insight was making step 5 mandatory. A finance app with zero data is useless. By having users add one transaction during onboarding, they immediately see the dashboard with _their_ data. "Oh, this is what it looks like. I get it now." That moment of understanding is worth way more than a feature tour.

# Error Handling: Making Failures Graceful

Convex errors come back as somewhat cryptic strings. The mobile app needs to translate these into user-friendly messages:

```typescript
// lib/convex-error-handler.ts

  if (error instanceof ConvexError) {
    const data = error.data;
    
    if (typeof data === 'string') {
      return friendlyMessages[data] ?? data;
    }
    
    if (data?.code === 'RATE_LIMITED') {
      return "You're doing that too quickly. Please wait a moment.";
    }
    
    if (data?.code === 'FEATURE_LIMIT') {
      return `You've reached your ${data.feature} limit for this month. Upgrade to Pro for more!`;
    }
  }
  
  // Generic fallback
  return "Something went wrong. Please try again.";
}
```

The app never shows raw error messages to users. Every error is caught, parsed, and displayed as a friendly toast notification. "Rate limited" becomes "You're doing that too quickly." "Unauthorized" becomes "Please sign in again."

# The Testing Reality

I'll be honest — mobile testing is the weakest part of Lumo right now. I've got component tests for the critical hooks and some snapshot tests for key screens. But comprehensive E2E testing for React Native is still painful.

What I _do_ test religiously:
- **Custom hooks** — `useBudgetCycleInfo`, `useTransactions`, `usePredictions` all have unit tests
- **Utility functions** — Date parsing, budget calculations, CSV 
- **Error handlers** — Every error code maps to a friendly message

What I _should_ test but don't yet:
- Full navigation flows (onboarding, transaction creation)
- Screen rendering with different data states (empty, loading, error, full)
- Interaction testing (tap flows, form submissions)

Jest with React Testing Library gets you partway there, but testing Convex subscriptions in a React Native environment is... not great. I'm still figuring out the best approach. If you've got suggestions, I'm all ears.

# React Native vs Flutter: The Honest Take

Since I've now built production apps in both, here's my honest comparison:

**React Native wins at:**
- TypeScript ecosystem sharing (one language for everything)
- Convex/backend integration (types flow naturally)
- Web developer onboarding (if you know React, you're halfway there)
- npm ecosystem breadth

**Flutter wins at:**
- UI consistency across platforms (pixel-perfect control)
- Animation performance (Skia rendering is incredible)
- Dart's null safety (TypeScript's is good, Dart's is better)
- Hot reload speed (Flutter's is genuinely faster)

**Neither wins at:**
- Mobile testing (both are painful)
- Native module bridging (both require native code eventually)
- App size (both produce large binaries)

For Lumo specifically, React Native was the right call because of the monorepo TypeScript story. But if I were building a standalone mobile app with no web component? I might still reach for Flutter.

# Wrapping Up

The Lumo mobile app is around 8,700 lines of screen and component code. It's not the biggest app in the world, but it handles real money tracking for real people, and it needs to feel trustworthy on every tap.

The patterns that worked: thin screens, fat hooks, feature-based folder structure, aggressive caching with `useStableQuery`, and lots of small UX polish (haptics, biometric lock, friendly errors).

The patterns that hurt: over-abstracting too early, not testing enough, and underestimating how different iOS and Android handle edge cases (keyboard behavior, safe area insets, notification permissions).

Next up: I'll cover the admin dashboard — the internal tool that lets me manage users, toggle prediction models, monitor errors, and keep the whole system running. Spoiler: it's built with Vite and TanStack Router, and it's way more useful than I expected.

Until then, keep your apps native-feeling and your hooks custom, nerds. 📱

---

# Building AI Spending Predictions That Actually Work

- **URL**: https://www.rafay99.com/blog/lumo-ai-spending-predictions-that-actually-work/
- **Published**: 2026-04-23
- **Author**: Abdul Rafay
- **Tags**: AI, ThoughtsProcess
- **Description**: How I built a spending prediction engine for Lumo — from naive averages to day-of-week aware models with confidence intervals.

"Hey, based on your spending patterns, you'll probably spend about $2,300 next month."

That's the dream feature, right? An app that doesn't just show you what you _did_ spend, but tells you what you _will_ spend. Fortune-telling for your wallet.

When I decided Lumo needed spending predictions, I thought it'd be a fun weekend project. Pull some transaction data, calculate an average, show a number. How hard could it be?

(If you've been reading this series, you know that question always precedes suffering.)

Turns out, building predictions that are actually _useful_ — not just technically correct — is a whole different game. And I ended up building two different models before landing on something I was happy with.

# Model V1: The "Just Average It" Approach

Let's start with the obvious: take the last few months of spending, calculate the average, call it a prediction.

```typescript
// V1: Simple weighted average
function predictSpendingV1(transactions: Transaction[]): number {
  const monthlyTotals = groupByMonth(transactions);
  
  // Weight recent months more heavily
  let weightedSum = 0;
  let weightTotal = 0;
  
  monthlyTotals.forEach((total, index) => {
    const weight = index + 1;  // More recent = higher weight
    weightedSum += total * weight;
    weightTotal += weight;
  });
  
  return weightedSum / weightTotal;
}
```

This... works. Sort of. If you spend roughly the same amount every month, the prediction is fine. But here's what it gets wrong:

1. **It ignores spending patterns.** You spend more on weekends. You spend more at the beginning of the month. V1 doesn't care — it's all just one big average.

2. **One big purchase ruins everything.** Buy a laptop in March, and V1 thinks you buy a laptop every month. The average shoots up and stays up for months.

3. **It has no concept of categories.** Your grocery spending is stable. Your entertainment spending is wild. V1 mashes them together and gives you a number that's useful for neither.

V1 was the prototype. It proved the concept — users liked seeing predictions. But the numbers were often just... off. Off enough that people didn't trust them.

# Model V2: Getting Smarter

V2 was a complete rewrite with three big improvements: **category-level predictions**, **day-of-week awareness**, and **recency decay**.

## Category-Level Predictions

Instead of predicting total spending as one number, V2 predicts each category separately:

```typescript
// V2: Category-aware prediction with recency weighting
function predictByCategory(
  transactions: Transaction[],
  months: number = 6
): CategoryPredictions {
  const categories = groupByCategory(transactions);
  const predictions: CategoryPredictions = {};
  
  for (const [category, txns] of Object.entries(categories)) {
    const monthlyTotals = groupByMonth(txns);
    
    // Apply exponential decay — recent months matter more
    const DECAY_FACTOR = 0.8;
    let weightedSum = 0;
    let weightTotal = 0;
    
    monthlyTotals.forEach((total, monthsAgo) => {
      const weight = Math.pow(DECAY_FACTOR, monthsAgo);
      weightedSum += total * weight;
      weightTotal += weight;
    });
    
    predictions[category] = {
      predicted: weightedSum / weightTotal,
      confidence: calculateConfidence(monthlyTotals),
      trend: detectTrend(monthlyTotals),
    };
  }
  
  return predictions;
}
```

That `DECAY_FACTOR = 0.8` is key. It means last month's data has weight 1.0, two months ago has weight 0.8, three months ago has 0.64, and so on. Recent behavior matters most, but older patterns still contribute.

Why 0.8? Honestly, I tested a bunch of values. 0.5 was too aggressive — it basically only looked at the last month. 0.9 was too slow to react to changes. 0.8 felt right. It's not scientific, but it works in practice.

## Day-of-Week Awareness

Here's something interesting about spending: people spend differently on different days. Mondays are light (still recovering from the weekend). Fridays and Saturdays are heavy (going out, shopping, treating yourself).

V2 builds a day-of-week spending profile:

```typescript
// Build a spending profile per day of week
function buildDayOfWeekProfile(
  transactions: Transaction[]
): DayProfile[] {
  const dayTotals = Array(7).fill(0);
  const dayCounts = Array(7).fill(0);
  
  for (const txn of transactions) {
    const day = new Date(txn.date).getDay();
    dayTotals[day] += txn.amount;
    dayCounts[day] += 1;
  }
  
  return dayTotals.map((total, day) => ({
    day,
    avgSpending: dayCounts[day] > 0 
      ? total / dayCounts[day] 
      : 0,
  }));
}
```

This profile feeds into the daily forecast. When you look at Lumo's prediction chart, it doesn't show a flat line — it shows estimated spending per day, with weekends typically higher than weekdays. It feels more realistic because it _is_ more realistic.

## Confidence Intervals

A single prediction number is almost guaranteed to be wrong. So V2 also outputs a range:

```typescript
// Calculate prediction confidence interval
function calculateConfidenceInterval(
  monthlyTotals: number[]
): { low: number; high: number; confidence: number } {
  const mean = average(monthlyTotals);
  const stdDev = standardDeviation(monthlyTotals);
  
  // 80% confidence interval
  const margin = stdDev * 1.28;
  
  // Confidence score (0-1) based on data consistency
  const cv = stdDev / mean;  // Coefficient of variation
  const confidence = Math.max(0, 1 - cv);
  
  return {
    low: Math.max(0, mean - margin),
    high: mean + margin,
    confidence: Math.round(confidence * 100) / 100,
  };
}
```

So instead of saying "You'll spend $2,300," Lumo says "You'll likely spend between $2,100 and $2,500, and we're 72% confident about this." The range manages expectations. The confidence score tells users how much to trust the prediction.

Low confidence? You'll see a message: _"We don't have enough data yet for accurate predictions. Keep tracking for a few more weeks!"_ Because a bad prediction is worse than no prediction.

# Data Quality: The Unsung Hero

Here's something nobody talks about when building prediction features: **most users don't have enough data for predictions to work.**

A brand new user has zero transactions. You can't predict from nothing. Even after a week, you've got maybe 15 data points — not enough for category breakdowns or day-of-week profiles.

I set minimum thresholds:

```typescript
const MIN_TRANSACTIONS = 10;
const MIN_MONTHS_DATA = 2;
const MAX_TRANSACTIONS = 2000;  // Cap for performance

function canGeneratePrediction(
  transactions: Transaction[]
): DataQualityResult {
  if (transactions.length < MIN_TRANSACTIONS) {
    return { 
      canPredict: false, 
      reason: "Need at least 10 transactions" 
    };
  }
  
  const monthSpan = getMonthSpan(transactions);
  if (monthSpan < MIN_MONTHS_DATA) {
    return { 
      canPredict: false, 
      reason: "Need at least 2 months of data" 
    };
  }
  
  return { canPredict: true };
}
```

The `MAX_TRANSACTIONS = 2000` cap is also important. Loading 10,000 transactions into memory for a prediction calculation would tank performance. 2,000 covers roughly 6 months of heavy spending (about 11 transactions per day), which is more than enough signal.

# Caching: Because Predictions Are Expensive

Running the prediction algorithm on every page load would be absurd. The calculation touches potentially thousands of transactions, does statistical analysis, builds category breakdowns, and generates daily forecasts. That's heavy.

So predictions are cached:

```typescript
predictionCache: defineTable({
  userId: v.id("users"),
  monthlyTotal: v.float64(),
  categoryBreakdown: v.array(v.object({
    category: v.string(),
    predicted: v.float64(),
    confidence: v.float64(),
  })),
  dailyForecast: v.array(v.object({
    date: v.string(),
    predicted: v.float64(),
  })),
  confidenceInterval: v.object({
    low: v.float64(),
    high: v.float64(),
    confidence: v.float64(),
  }),
  modelVersion: v.string(),
  generatedAt: v.string(),
  expiresAt: v.string(),
})
```

Cache lifetime is 24 hours. When you add a new transaction, the cache is invalidated so the next prediction request triggers a fresh calculation. But if you're just browsing the app without changes, you get the cached version instantly.

```typescript
// Get prediction — from cache or fresh

  handler: async (ctx) => {
    const userId = await getAuthenticatedUserId(ctx);
    
    // Check cache first
    const cached = await ctx.db
      .query("predictionCache")
      .withIndex("by_user", (q) => q.eq("userId", userId))
      .first();
    
    if (cached && !isExpired(cached.expiresAt)) {
      return cached;
    }
    
    // Generate fresh prediction
    const transactions = await getRecentTransactions(
      ctx, userId, MAX_TRANSACTIONS
    );
    
    const quality = canGeneratePrediction(transactions);
    if (!quality.canPredict) {
      return { status: "insufficient_data", reason: quality.reason };
    }
    
    const prediction = generatePrediction(transactions);
    
    // Cache for 24 hours
    await cachePrediction(ctx, userId, prediction);
    
    return prediction;
  },
});
```

# The Insights Layer

Raw numbers are boring. Nobody looks at "$2,300 predicted" and gets excited. What makes predictions _useful_ is context.

So V2 generates insights alongside the prediction:

```typescript
function generateInsights(
  prediction: Prediction,
  currentCycleState: CycleState
): Insight[] {
  const insights: Insight[] = [];
  
  // Are they on track to overspend?
  const daysLeft = daysRemainingInCycle(currentCycleState);
  const projectedTotal = projectFromCurrentSpending(
    currentCycleState.totalSpending, daysLeft
  );
  
  if (projectedTotal > currentCycleState.budget * 1.1) {
    insights.push({
      type: "warning",
      message: `At your current pace, you'll exceed your budget by ~$${
        Math.round(projectedTotal - currentCycleState.budget)
      } this cycle.`,
    });
  }
  
  // Category with biggest increase
  const biggestIncrease = findBiggestCategoryChange(prediction);
  if (biggestIncrease && biggestIncrease.changePercent > 20) {
    insights.push({
      type: "info",
      message: `Your ${biggestIncrease.category} spending is trending ${
        biggestIncrease.changePercent
      }% higher than usual.`,
    });
  }
  
  // Weekend vs weekday spending ratio
  const weekendRatio = prediction.weekendSpending / 
    prediction.weekdaySpending;
  if (weekendRatio > 2.0) {
    insights.push({
      type: "tip",
      message: "You spend more than twice as much on weekends vs weekdays. Budgeting for weekends separately might help.",
    });
  }
  
  return insights;
}
```

These insights turn a prediction from "here's a number" into "here's what that number means for _you_." That's the difference between a feature people glance at and one they actually use.

# Model Switching: The Admin Superpower

Here's something fun — both V1 and V2 still exist in the codebase, and the admin dashboard can toggle between them:

```typescript
predictionModelConfig: defineTable({
  activeVersion: v.union(
    v.literal("v1"),
    v.literal("v2")
  ),
  updatedAt: v.string(),
  updatedBy: v.id("users"),
})
```

Why keep V1 around? A/B testing. If V2's predictions are consistently off for certain user patterns, I can flip back to V1 while I fix the issue. The admin dashboard also shows prediction accuracy metrics — comparing what was predicted vs what actually happened.

There's even a bulk recalculation function that regenerates predictions for all users when switching models. It caps at 100 users per run to avoid timeouts, which means a model switch for 500 users takes about 5 runs (one every hour via cron). Not instant, but safe.

# What I Wish I Knew Before Starting

1. **Start simple, then add complexity.** V1 was ugly but it proved users wanted predictions. Without that validation, V2 would've been wasted effort.

2. **Confidence matters more than accuracy.** Users tolerate predictions that are "close enough" — but they lose trust instantly if you show a prediction with no indication of how reliable it is. Always show the confidence level.

3. **Data quality checks are mandatory.** A prediction based on 3 transactions is worse than no prediction. Gate the feature behind minimum data thresholds.

4. **Cache aggressively.** Predictions don't need to update in real-time. 24-hour caching with invalidation on new transactions is more than fresh enough.

5. **Insights beat numbers.** "You'll spend $2,300" is information. "You're on track to overspend by $400 this month" is actionable. Always prefer actionable.

The prediction engine is probably the most "wow factor" feature in Lumo. It's the one people are most impressed by when I demo the app. But under the hood, it's really just statistics and good UX — no neural networks, no GPT, no black magic. Just math with empathy.

Next up: I'm going to walk through the React Native mobile app architecture — how I structured screens, hooks, and components for a finance app that needs to feel fast and reliable on every tap.

Until then, may your predictions be accurate and your spending stay under budget. 📊

---

# Multiple Income Streams and the Budget Math Nightmare

- **URL**: https://www.rafay99.com/blog/lumo-multi-income-budget-math-nightmare/
- **Published**: 2026-04-20
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess, WebDevelopment
- **Description**: How Lumo handles salary, freelance, and investment income — all on different schedules — and converts them into one usable budget number.

So you've got a job. Cool. Your salary comes in every month. Budget is just salary minus expenses. Done.

But what if you also freelance on the side? And that pays biweekly. And you've got a small investment that pays quarterly dividends. And sometimes you do random one-off gigs that pay... whenever they feel like it.

Now try to answer: "What's my monthly budget?"

Yeah. That's what I had to solve in Lumo. And let me tell you — it's not just math. It's a whole philosophy about how people think about money.

# The Income Model

Most finance apps treat income as a single number you type in once and forget about. "$5,000 per month." Done. Move on.

But real life isn't like that. Real life is messy. People have:

- **Monthly salary** — predictable, consistent
- **Freelance income** — irregular, sometimes biweekly, sometimes whenever the client finally pays
- **Investment returns** — quarterly, annually, or random
- **One-time payments** — bonuses, tax refunds, gifts

Lumo needed to handle all of these. Not just store them — actually _use_ them to calculate a meaningful budget.

Here's the schema for income streams:

```typescript
incomeStreams: defineTable({
  userId: v.id("users"),
  name: v.string(),           // "Day Job", "Freelance", "Dividends"
  type: v.union(
    v.literal("salary"),
    v.literal("freelance"),
    v.literal("investment"),
    v.literal("other")
  ),
  amount: v.float64(),         // Amount per occurrence
  frequency: v.union(
    v.literal("monthly"),
    v.literal("weekly"),
    v.literal("biweekly"),
    v.literal("annually"),
    v.literal("one-time")
  ),
  cycleDay: v.optional(v.number()),  // Day of month/week it hits
  isActive: v.boolean(),
  createdAt: v.string(),
})
```

One user can have as many income streams as they want. Each with its own frequency. Each hitting on a different schedule.

The question is: how do you combine weekly freelance income with a monthly salary into a single budget number?

# The Conversion Problem

On the surface, converting between frequencies is basic arithmetic:

- Weekly → Monthly: multiply by 4.33 (52 weeks / 12 months)
- Biweekly → Monthly: multiply by 2.167 (26 pay periods / 12 months)
- Annually → Monthly: divide by 12
- One-time → Monthly: uh...

That last one is the problem child. A one-time payment of $2,000 isn't "$2,000 per month." It's $2,000 _once_. So how does it affect the budget?

I debated this for way too long. Here's what I landed on: **one-time income only affects the cycle it arrives in.** If you get a $2,000 bonus in April, your April budget increases by $2,000. May goes back to normal.

For recurring streams, I wrote a utility that normalizes everything to a monthly equivalent:

```typescript

  amount: number,
  frequency: IncomeFrequency
): number {
  switch (frequency) {
    case "monthly":
      return amount;
    case "weekly":
      return amount * (52 / 12);  // ~4.33
    case "biweekly":
      return amount * (26 / 12);  // ~2.167
    case "annually":
      return amount / 12;
    case "one-time":
      return 0;  // Handled separately per cycle
  }
}
```

The total monthly budget then becomes the sum of all active stream equivalents, plus any one-time income that falls within the current cycle.

Simple? In theory. In practice, it opened a whole can of worms.

# The "But My Freelance Income Varies" Problem

Here's a fun conversation I had with myself while building this:

_"Okay, freelance income is $500 biweekly."_
_"But some months I get paid three times because of how the weeks fall."_
_"And last month the client paid late, so I got two payments in one month."_
_"And this month I picked up an extra project for a different rate."_

The budgeted amount and the actual received amount are almost never the same. So Lumo tracks both.

The income stream stores the _expected_ amount and frequency. That's what goes into the budget calculation. But there's a separate `paymentHistory` table that records _actual_ payments:

```typescript
paymentHistory: defineTable({
  userId: v.id("users"),
  incomeStreamId: v.id("incomeStreams"),
  amount: v.float64(),       // Actual amount received
  date: v.string(),          // When it actually hit
  notes: v.optional(v.string()),
})
```

This way, you can budget based on expectations but track reality. And if reality consistently differs from expectations, that's a signal to update your expected amount.

I also added income change notifications. If your actual payments for a stream are consistently 20% above or below the expected amount, Lumo nudges you: _"Hey, your freelance income seems higher than expected. Want to update your budget?"_

It's a small thing, but it's the kind of detail that makes a finance app actually useful instead of just being a fancy spreadsheet.

# The Budget Recalculation Cascade

Here's where things got architecturally interesting. When you update an income stream — say, you got a raise and your salary went from $5,000 to $5,500 — the budget needs to recalculate. But it's not just the current cycle's budget. It's:

1. The monthly equivalent for this stream
2. The total monthly income (sum of all streams)
3. The current cycle's budget (which might use a manual override or auto-calculate)
4. The available balance (budget - spending - loans + carryover)

This is a cascade. Change one number, and four derived values need updating.

I handled this with a Convex workflow:

```typescript
// When income changes, recalculate the budget

  args: { userId: v.id("users") },
  handler: async (ctx, { userId }) => {
    // Get all active income streams
    const streams = await ctx.db
      .query("incomeStreams")
      .withIndex("by_user", (q) => q.eq("userId", userId))
      .filter((q) => q.eq(q.field("isActive"), true))
      .collect();
    
    // Calculate total monthly income
    const monthlyIncome = streams.reduce((total, stream) => {
      return total + calculateMonthlyEquivalent(
        stream.amount,
        stream.frequency
      );
    }, 0);
    
    // Update cycle state with new budget
    const cycleState = await getCurrentCycleState(ctx, userId);
    const budgetSettings = await getBudgetSettings(ctx, userId);
    
    // Use manual budget if set, otherwise use calculated income
    const effectiveBudget = budgetSettings.manualBudget 
      ?? monthlyIncome;
    
    await ctx.db.patch(cycleState._id, {
      budget: effectiveBudget,
    });
  },
});
```

Notice that `manualBudget` check? Some users don't want their budget to auto-calculate from income. They want to say "I earn $5,500 but my budget is $4,000" — because they're saving the rest. So there's an override option that takes precedence.

More complexity? Yes. But it's the kind of complexity that real people need.

# Payment Recording: The UX Challenge

Beyond the math, there's a UX problem. How do you make it easy for someone to say "I got paid today"?

The first version had a full form — select the income stream, enter the amount, pick the date. It was technically correct but annoying. Nobody wants to fill out a form every payday.

The redesigned version shows your income streams as cards. Each card has a "Record Payment" button. Tap it, and it pre-fills with the expected amount and today's date. One tap to confirm. Done.

If the actual amount differs from the expected, you can edit it. But the default flow is: see income stream, tap, confirm. Three seconds.

```typescript
// Pre-filled payment recording
const recordPayment = useMutation(api.income.recordPayment);

const handleQuickRecord = async (stream: IncomeStream) => {
  await recordPayment({
    incomeStreamId: stream._id,
    amount: stream.amount,  // Pre-filled expected amount
    date: new Date().toISOString(),
  });
  
  // Haptic feedback for the satisfying tap
  Haptics.notificationAsync(
    Haptics.NotificationFeedbackType.Success
  );
};
```

That haptic feedback? It's a small touch, but it makes recording payments feel _good_. Like checking off a to-do item. Finance apps should make you feel accomplished, not stressed.

# Income Change Detection

One feature I'm particularly proud of is income change detection. The system compares recent payments against the expected amount for each stream and flags significant deviations:

```typescript
// Check for income changes worth notifying about
async function detectIncomeChanges(ctx, userId) {
  const streams = await getActiveStreams(ctx, userId);
  
  for (const stream of streams) {
    const recentPayments = await getRecentPayments(
      ctx, stream._id, 3  // Last 3 payments
    );
    
    if (recentPayments.length < 3) continue;
    
    const avgActual = recentPayments.reduce(
      (sum, p) => sum + p.amount, 0
    ) / recentPayments.length;
    
    const deviation = Math.abs(
      (avgActual - stream.amount) / stream.amount
    );
    
    // If actual differs by more than 15%, notify
    if (deviation > 0.15) {
      await triggerIncomeChangeNotification(ctx, userId, {
        streamName: stream.name,
        expected: stream.amount,
        actual: avgActual,
        direction: avgActual > stream.amount 
          ? "increase" : "decrease",
      });
    }
  }
}
```

This runs as part of the income reset reminder cron job. It's not real-time — it checks periodically. But it catches trends that users might miss. Your freelance rate quietly went up 20% over the last three months? Lumo notices.

# Lessons from the Income Trenches

Building multi-income support taught me that **financial software is really people software**. The math is the easy part. The hard part is understanding how different people think about their money.

Some people have one salary and that's it. Others juggle five income sources with different frequencies. The system needs to handle both cases elegantly — not make the simple case complicated or the complex case impossible.

Key takeaways:

1. **Separate expected from actual.** Budget with expectations, track reality, alert on deviations.
2. **Make the common case effortless.** One-tap payment recording with pre-filled defaults.
3. **Don't force a budget model.** Some people want auto-calculated budgets from income. Others want manual control. Support both.
4. **Frequency conversion is deceptively tricky.** 4 weeks ≠ 1 month. 52/12 ≈ 4.33. Get the math right or the budget will drift.

Next up in the series: I'm going to talk about something wild — building an AI-powered spending prediction engine that actually tries to tell you how much you'll spend next month. Spoiler: it's part math, part magic, and part "please don't be too wrong."

Until then, may your income always exceed your expenses. Peace out, nerds. 💸

---

# Convex as a Real-Time Backend: The Love and the Pain

- **URL**: https://www.rafay99.com/blog/lumo-convex-realtime-backend-love-and-pain/
- **Published**: 2026-04-16
- **Author**: Abdul Rafay
- **Tags**: WebDevelopment, ThoughtsProcess
- **Description**: What it's actually like building a full finance app on Convex — the magic of real-time subscriptions, the pain of cache limits, and everything in between.

If you've read my [earlier post about Convex scaling issues](/blog/stop-the-presses-convex-is-here-and-so-are-the-growing-pains), you know I've had a... complicated relationship with this platform. But Lumo is a different beast. This isn't a corporate onboarding flow with 500 concurrent users — it's a personal finance app where real-time data matters more than raw throughput.

And for that use case? Convex is genuinely something special.

But it's not all rainbows. Let me break down what it's actually like to build a production app with Convex as your entire backend.

# The Magic: Real-Time Everything

Here's the pitch: write a query function, and every client subscribed to it gets live updates when the underlying data changes. No WebSocket setup. No polling. No `useEffect` with a refresh timer. Just... data that stays current.

For a finance app, this is transformative. Let me give you a real example.

You're looking at your dashboard. It shows your remaining budget: $847. You switch to the transactions tab, add a $50 lunch. Switch back to the dashboard. **$797.** Instantly. No refresh button. No pull-to-refresh. The number just... changed.

Behind the scenes, here's what happened:

1. The `addTransaction` mutation ran
2. Inside that mutation, it also called `updateCycleSpending` to atomically increment the spending total
3. The dashboard is subscribed to `getCycleState`, which reads from the `cycleState` table
4. Convex detected the table changed and pushed the updated state to all connected clients

No event bus. No pub/sub setup. No cache invalidation logic. Convex just _knows_ which queries depend on which tables and re-runs them when data changes.

I've built real-time features with Firebase Realtime Database, with Supabase subscriptions, with manual WebSocket setups. Convex is the cleanest implementation I've used. Period.

# The Schema: Type Safety All the Way Down

One of my favorite things about Convex is the schema definition. You define your tables in TypeScript, and the system generates types for your queries and mutations. Here's a peek at part of Lumo's schema:

```typescript
// Part of the Convex schema
transactions: defineTable({
  userId: v.id("users"),
  amount: v.float64(),
  category: v.string(),
  paymentMethod: v.optional(v.string()),
  notes: v.optional(v.string()),
  date: v.string(),
  createdAt: v.string(),
}).index("by_user", ["userId"])
  .index("by_user_date", ["userId", "date"]),
```

That `.index()` chain? Those are database indexes you define right in your schema. Change a field name? TypeScript catches it everywhere. Add a new required field? Every mutation that inserts into this table needs updating, and the compiler tells you exactly which ones.

Coming from the world of raw SQL or even Mongoose schemas where "type safety" means "I hope the runtime catches it," this is refreshing. I can refactor my database schema and know that my entire app — backend, mobile, web, admin — will flag any inconsistencies at compile time.

# The Pain: Learning to Think in Convex

Okay, now the honest part. Because Convex isn't just "a database with an API." It's a different paradigm, and if you bring your REST/SQL mental model, you're going to have a bad time.

## Pain Point 1: No `SELECT *` Mentality

In SQL, you might write `SELECT * FROM transactions WHERE userId = ?`. In Convex, the equivalent is:

```typescript
const transactions = await ctx.db
  .query("transactions")
  .withIndex("by_user", (q) => q.eq("userId", userId))
  .collect();
```

See that `.collect()` at the end? It loads _everything_ into memory. For a user with 50 transactions? Fine. For a user with 5,000? Your function just ate a bunch of memory and your cache is crying.

I learned this the hard way. My initial `listTransactions` function collected everything, then filtered and sorted in JavaScript. It worked great in development with my test data of 20 transactions. In production? Not so much.

The fix was pagination and smarter queries:

```typescript
// Paginated transaction listing

  args: {
    paginationOpts: paginationOptsValidator,
  },
  handler: async (ctx, args) => {
    const userId = await getAuthenticatedUserId(ctx);
    
    return await ctx.db
      .query("transactions")
      .withIndex("by_user_date", (q) => q.eq("userId", userId))
      .order("desc")
      .paginate(args.paginationOpts);
  },
});
```

Pagination is built into Convex, and it's actually nice once you learn to use it. But you _have_ to think about it upfront. There's no query optimizer silently saving you from yourself.

## Pain Point 2: Mutations Must Be Fast

Convex functions have execution limits. Your mutation can't run for 30 seconds doing complex calculations. This forced me to rethink how I handle things like cycle finalization.

My original approach: one big mutation that reads all user data, calculates everything, and writes the new cycle. It worked for one user. For processing all users in a cron job? Timeout city.

The solution was breaking work into smaller chunks:

```typescript
// Process cycle resets in batches
const usersToProcess = await ctx.db
  .query("cycleState")
  .filter((q) => q.lt(q.field("cycleEndDate"), now))
  .take(50);  // Process 50 at a time

for (const cycle of usersToProcess) {
  await finalizeSingleCycle(ctx, cycle);
}
```

Cap at 50 per run. The cron fires every hour. If there are 200 users to process, it takes four runs. Not elegant, but reliable. And in serverless land, reliable beats elegant every time.

## Pain Point 3: No Joins (But It's Okay)

Coming from SQL, the lack of JOINs feels like losing a limb. Want a transaction with its category name? Two queries. Want a loan with the borrower's user info? Two queries.

But here's the thing I realized: in a real-time system, denormalization is actually fine. If I store the category name directly on the transaction (instead of a category ID), it's one fewer query and the data is always right there. The tradeoff is updating category names means touching every transaction, but how often do you rename categories? Almost never.

For Lumo, I found a balance: keep IDs for things that change (user references), denormalize things that don't (category names, payment method labels).

# The Killer Feature: Atomic Mutations

Here's something that doesn't get enough love in Convex: **mutations are transactional**. If any part of your mutation throws, the entire thing rolls back. No partial writes. No inconsistent state.

For a finance app, this is critical. When someone adds a transaction, I need to:

1. Insert the transaction record
2. Update the cycle's spending total
3. Check if they're over budget
4. Maybe trigger a notification

If step 2 fails after step 1 succeeds, I've got a transaction in the database that isn't reflected in the budget total. That's a data integrity bug that would haunt me forever.

With Convex, all four steps happen in one mutation. Either they all succeed, or none of them do. I don't need to write rollback logic or implement sagas. It just works.

```typescript

  args: { /* ... */ },
  handler: async (ctx, args) => {
    const userId = await getAuthenticatedUserId(ctx);
    
    // Step 1: Insert transaction
    await ctx.db.insert("transactions", {
      userId,
      amount: args.amount,
      category: args.category,
      date: args.date,
      createdAt: new Date().toISOString(),
    });
    
    // Step 2: Update cycle spending (atomic!)
    await updateCycleSpending(ctx, userId, args.amount);
    
    // Step 3: Check budget and maybe notify
    const state = await getCycleState(ctx, userId);
    if (state.totalSpending > state.budget) {
      await createNotification(ctx, userId, "over-budget");
    }
    
    // If anything above throws, nothing is committed
  },
});
```

This alone is worth the learning curve. Financial data integrity is non-negotiable.

# The Developer Experience

Let me talk about the day-to-day of working with Convex, because the DX matters.

**The good:**
- `npx convex dev` gives you a live development server that hot-reloads your functions
- Schema changes generate new types instantly
- The Convex dashboard shows you every function call, every error, every table
- Logs are actually useful (stack traces, arguments, timing)

**The less good:**
- Debugging subscriptions is tricky — if a query isn't updating, is it the query logic? The index? A missing table read?
- The documentation is... growing. Some advanced patterns require digging through Discord or GitHub issues
- Deployment is a separate step from your web deployment — you need to coordinate Convex deploys with frontend deploys

**The underrated:**
- Rate limiting via `@convex-dev/rate-limiter` is a one-line addition to any function
- Cron jobs are defined in a single `crons.ts` file — no external scheduler needed
- File storage is built in (used for receipt images)

# Would I Choose Convex Again?

For Lumo? Absolutely. The real-time subscriptions alone save me hundreds of lines of synchronization code. The type safety catches bugs before they ship. The atomic mutations keep financial data consistent.

For a different app? Depends. If I were building something that's mostly CRUD with complex SQL queries and existing relationships — I'd probably stick with Postgres. Convex shines when real-time matters, when you want tight frontend-backend integration, and when you're willing to think in documents instead of rows.

> **Convex is amazing for apps where the UI needs to feel alive. Just make sure you understand the constraints before your data grows.**

That's the honest take. No hype. No hate. Just experience.

Next up in the Lumo series: how I handled multiple income streams — salary, freelance, investments — all hitting at different times, and how converting them all into one budget number is secretly a nightmare.

Until then, keep your queries indexed and your mutations atomic, nerds. 🔥

---

# The Budget Cycle System That Broke My Brain

- **URL**: https://www.rafay99.com/blog/lumo-budget-cycle-system-that-broke-my-brain/
- **Published**: 2026-04-13
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess, WebDevelopment
- **Description**: How I built a custom budget cycle engine for Lumo that respects payday schedules, handles carryover, and took three rewrites to get right.

Here's a question that sounds simple until you actually try to answer it in code:

**"How much money do I have left this month?"**

Easy, right? Take your budget, subtract your spending, done. Ship it. Go home.

Except... when does "this month" start? January 1st? Sure, if you get paid on the 1st. But what if your salary hits on the 15th? Or the 25th? What if you have freelance income that comes in randomly? What if last month you overspent by $200 — does that carry over?

Welcome to the budget cycle system. The single most important piece of Lumo, and the feature that broke my brain the hardest.

# The Problem with "Monthly" Budgets

Every finance app I've used assumes your budget resets on the 1st of each month. Which is great if you're a trust fund kid who doesn't worry about when money actually arrives. But for the rest of us — the people who anxiously check their bank account on payday — the 1st means nothing.

I get paid on the 25th. My budget cycle should run from the 25th to the 24th of next month. That's _my_ financial month. That's when my money refreshes.

So the first requirement was clear: **let users pick their own cycle start day.**

Sounds like a one-line config change, right?

**HAHAHA.**

# Attempt One: The Naive Approach

My first implementation was embarrassingly simple. Store a `cycleStartDay` (1-31) in the user's settings. When loading the budget, calculate the current cycle window:

```typescript
// First attempt. Don't judge.
function getCycleDates(startDay: number) {
  const today = new Date();
  const currentMonth = today.getMonth();
  const currentYear = today.getFullYear();
  
  const cycleStart = new Date(currentYear, currentMonth, startDay);
  const cycleEnd = new Date(currentYear, currentMonth + 1, startDay - 1);
  
  return { cycleStart, cycleEnd };
}
```

This worked for about five minutes. Then I tested it with `startDay = 31` in February.

Guess what February 31st is? It isn't. JavaScript's `Date` constructor silently rolls it over to March 3rd. No error. No warning. Just... wrong dates. Silently.

Then there's the edge case where today is the 10th and your cycle starts on the 25th. Are we in the cycle that started last month's 25th? Or waiting for this month's 25th? The naive approach got confused. I got confused. Everyone was confused.

# Attempt Two: The Over-Engineered Approach

So I did what every developer does after a failure — I went full send in the opposite direction. I imported a date library. I wrote helper functions for every possible edge case. I had a `getCycleBoundaries` function that was 200 lines long and handled:

- Months with 28, 29, 30, and 31 days
- Cycle start days that don't exist in short months (31st in February → clamp to 28th/29th)
- Year boundaries (cycle from December 25 to January 24)
- Leap years (because of course)

It worked. But it was a mess. The function had so many if/else branches it looked like a choose-your-own-adventure book. Testing it required dozens of date scenarios, and every new edge case I found meant another branch.

# Attempt Three: The One That Actually Worked

The breakthrough came when I stopped thinking about dates and started thinking about **state**.

Instead of calculating the cycle window every time, I created a `cycleState` table in Convex:

```typescript
// The cycle state — our single source of truth
cycleState: defineTable({
  userId: v.id("users"),
  cycleStartDate: v.string(),   // When this cycle began
  cycleEndDate: v.string(),     // When this cycle ends
  budget: v.float64(),          // Total budget for this cycle
  totalSpending: v.float64(),   // Running total of spending
  carryover: v.float64(),       // Surplus/deficit from last cycle
  isFinalized: v.boolean(),     // Has this cycle been closed?
})
```

Now the cycle isn't calculated — it's **stored**. When a cycle ends, we finalize it, calculate savings, and create a new one. The `cycleStartDate` and `cycleEndDate` are concrete, no ambiguity.

The boundary calculation still exists, but it only runs once — when creating a new cycle. And it's been extracted into a dedicated utility:

```typescript
// Calculate cycle boundaries from a start day

  startDay: number,
  referenceDate: Date
): { start: Date; end: Date } {
  // Clamp start day to actual days in month
  const daysInMonth = getDaysInMonth(referenceDate);
  const clampedDay = Math.min(startDay, daysInMonth);
  
  // ... boundary logic with proper month wrapping
}
```

Clean. Testable. And most importantly — **the cycle state is atomic**. When you add a transaction, the spending total updates in the same mutation. No race conditions. No stale reads. Convex's transactional guarantees handle the hard stuff.

# The Carryover Headache

Okay, so we have cycle boundaries working. Now comes the fun part: **what happens at the end of a cycle?**

If you had a $2,000 budget and only spent $1,800, you saved $200. Great. But should that $200 carry over to the next cycle? Some people want that. Others prefer a clean slate each cycle.

And what about the opposite — you overspent by $300. Does next month start with $300 less? That's technically accurate, but it's also depressing. Some people would rather not carry negative balances forward.

So I made it configurable:

```typescript
// User's budget preferences
budgetPreferences: {
  carryNegativeBalance: v.boolean(),  // Carry debt forward?
  carryPositiveBalance: v.boolean(),  // Carry surplus forward?
}
```

The finalization logic runs as a Convex workflow — a cron job that fires every hour, checks all users, and finalizes any expired cycles:

```typescript
// Simplified cycle finalization
async function finalizeCycle(ctx, userId) {
  const cycleState = await getCycleState(ctx, userId);
  
  const savings = cycleState.budget - cycleState.totalSpending;
  
  // Store savings record
  await ctx.db.insert("cycleSavings", {
    userId,
    cycleStart: cycleState.cycleStartDate,
    cycleEnd: cycleState.cycleEndDate,
    budget: cycleState.budget,
    spending: cycleState.totalSpending,
    savings,
    carryover: cycleState.carryover,
  });
  
  // Calculate next cycle's carryover
  const prefs = await getBudgetPreferences(ctx, userId);
  let nextCarryover = 0;
  
  if (savings > 0 && prefs.carryPositiveBalance) {
    nextCarryover = savings;
  } else if (savings < 0 && prefs.carryNegativeBalance) {
    nextCarryover = savings;
  }
  
  // Create new cycle
  const boundaries = calculateCycleBoundaries(
    prefs.cycleStartDay,
    new Date()  // Reference from now
  );
  
  await ctx.db.insert("cycleState", {
    userId,
    cycleStartDate: boundaries.start.toISOString(),
    cycleEndDate: boundaries.end.toISOString(),
    budget: calculateBudgetFromIncome(ctx, userId),
    totalSpending: 0,
    carryover: nextCarryover,
    isFinalized: false,
  });
}
```

# The Loan Twist

Just when I thought the budget math was done, I added loans. Because of course.

Lumo lets you track money you've lent to people (or borrowed). And here's the thing — if you lent someone $500 this month, that $500 came from your budget. Your _available_ balance should reflect that.

So the final budget calculation isn't just `budget - spending`. It's:

```
Available = Budget - Spending - Outstanding Loans + Carryover
```

This means every time someone records a loan transaction, the available balance changes. Every time a loan gets repaid, it changes again. It's a web of interconnected financial state, and getting it right required centralizing _all_ budget math into one file: `budgetCalculations.ts`.

That file is now 800+ lines. It's the beating heart of the entire application. Every query that touches money flows through it. And honestly? That's the right call. One source of truth. One place to debug. One place to test.

# What I Learned

Three rewrites. Hundreds of test cases. One file that became the center of the universe.

Here's what this whole ordeal taught me:

1. **Don't calculate what you can store.** Derived state is fine for simple stuff, but when your calculation involves five tables and configurable preferences, store the result and update it atomically.

2. **Edge cases are the feature.** The difference between a toy budget app and a real one is how it handles February 29th, negative carryover, and users who change their cycle start day mid-cycle.

3. **Centralize financial math.** Having budget calculations scattered across files is a recipe for inconsistency. One function. One file. One truth.

4. **Test with real scenarios.** Unit tests with hardcoded dates caught bugs that "works on my machine" testing never would. I tested every month transition, every leap year, every impossible date.

This was the hardest feature to build in Lumo. Not because the individual pieces were complex — but because they all had to work together, perfectly, every time. Money stuff doesn't get to be "close enough."

Next up: I'll talk about how I handled multiple income streams with different frequencies, and how converting weekly freelance income into a monthly budget is way harder than it sounds.

Until then, keep budgeting and keep coding, nerds. 💰

---

# Lumo: Why I'm Building a Personal Finance App from Scratch

- **URL**: https://www.rafay99.com/blog/lumo-building-a-personal-finance-app-from-scratch/
- **Published**: 2026-04-09
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess, MobileDevelopment
- **Description**: The origin story of Lumo — a full-stack personal finance app I'm building with TypeScript, Convex, and React Native. Here's why and how it started.

Let me set the scene.

It's late at night. I'm sitting there staring at my bank statement, trying to figure out where half my salary disappeared to. I've got three different apps open — one for tracking expenses, one for budgets, and one that I downloaded six months ago and literally never opened. None of them talk to each other. None of them actually understand how _I_ manage money.

And that's when the itch started.

You know the itch. The developer itch. The one that whispers: _"You could build something better."_ And honestly? I should've ignored it. I should've just picked one app and stuck with it like a normal person. But I'm not a normal person — I'm a software engineer. We don't use apps, we build them. (And then never finish them, but that's a conversation for another day.)

So, **Lumo** was born.

# What Even Is Lumo?

Lumo is a personal finance application. But not just a mobile app — it's an entire ecosystem. We're talking:

- A **React Native mobile app** (iOS and Android) for daily tracking
- A **Next.js marketing website** with a blog and changelog
- An **admin dashboard** built with Vite and TanStack Router
- A **Convex backend** powering everything in real-time

Yeah, I went all in. Because apparently I don't believe in "start small."

The core idea is simple: **track your spending, understand your budget cycles, and actually know where your money goes.** But the implementation? That's where it gets spicy.

# Why Not Just Use Mint? Or YNAB? Or Any Other App?

Look, those apps are great. Seriously. But here's the thing — they all assume your financial life fits into their box. Monthly budgets that reset on the 1st? Cool, but what if you get paid on the 15th? Automatic bank syncing? Great, unless you live somewhere where your bank's API is held together with duct tape and prayers.

I wanted something that:

1. **Let me define my own budget cycle** — not locked to calendar months
2. **Handled multiple income streams** — salary, freelance, investments, all with different frequencies
3. **Actually predicted my spending** — not just showed me what I already spent
4. **Worked offline** — because internet isn't always reliable
5. **Didn't sell my financial data** — privacy matters, people

And most importantly, I wanted to **own it**. Every line of code. Every database row. Every pixel on the screen.

# The Tech Stack Decision

Alright, tech stack time. This is always the fun part, right? Spending three weeks deciding on tools instead of actually building anything. Classic.

Here's what I landed on:

**Monorepo with Turborepo + Bun**

I went with a monorepo because I've got four apps sharing a single backend. Having everything in one place means shared types, shared configs, and one `bun install` to rule them all. Turborepo handles the task orchestration — parallel builds, caching, the whole deal.

And Bun over npm/yarn? Honestly, speed. `bun install` finishes before npm even thinks about starting. Plus, built-in TypeScript support without extra tooling. Once you go Bun, you don't go back.

**Convex for the Backend**

Now, if you've read my [previous post about Convex](/blog/stop-the-presses-convex-is-here-and-so-are-the-growing-pains), you know I have... _opinions_ about it. But here's the reality — for a real-time finance app where you want instant UI updates when transactions change, Convex is genuinely magical. Subscriptions that just work. Type-safe queries. No REST endpoints to maintain.

The learning curve is real though. More on that in future posts.

**React Native with Expo for Mobile**

Flutter vs React Native is a debate I've had many times (and written about). For Lumo, I went React Native because the entire web ecosystem is already TypeScript. Sharing types between the backend and mobile app? Chef's kiss. One language across the entire stack.

Expo handles the build pipeline — EAS builds for both platforms without me needing a Mac farm.

**Next.js for the Marketing Site**

The website needed to be content-heavy (blog, changelog, legal pages) with great SEO. Next.js with static generation was the obvious choice. MDX for blog posts, Vercel for deployment. Simple.

**Vite + React for the Admin Panel**

The admin dashboard doesn't need SSR or SEO. It's an internal tool. Vite gives me instant hot reload, TanStack Router gives me type-safe routing, and Radix UI gives me accessible components without fighting CSS.

# The Architecture at a Glance

Here's what the monorepo looks like:

```
Lumo/
├── apps/
│   ├── mobile/     # React Native/Expo
│   ├── web/        # Next.js marketing
│   └── admin/      # Vite admin dashboard
├── packages/
│   ├── backend/    # Convex functions + schema
│   └── config/     # Shared TS/Biome configs
├── turbo.json
└── package.json
```

The beauty of this setup? The backend package (`@lumo/backend`) is a shared dependency. The mobile app, the web app, and the admin dashboard all import from the same backend. One schema. One set of functions. Three consumers.

Type safety flows from the Convex schema all the way down to the button you tap on your phone. Change a field in the database? TypeScript screams at every app that needs updating. It's beautiful.

# What's Coming in This Series

I'm going to document the entire journey of building Lumo. Not the sanitized, everything-works-perfectly version — the real one. The one with bugs at 2 AM, architectural decisions I regretted, and features that took three rewrites to get right.

Here's what I'm planning to cover:

1. **The budget cycle system** — the core innovation and why it took forever to get right
2. **Building real-time features with Convex** — subscriptions, optimistic updates, and the cache nightmares
3. **Multi-income support** — salary + freelance + investments, all on different schedules
4. **AI-powered spending predictions** — building a prediction engine that actually works
5. **Mobile app architecture** — React Native patterns that don't make you want to quit
6. **The admin dashboard** — building internal tools that aren't terrible
7. **Security and subscriptions** — device sessions, rate limiting, and tier management

Each post will dive deep into the actual code, the actual problems, and the actual solutions. No hand-waving. No "left as an exercise for the reader." The real stuff.

# The First Commit

I remember the first commit. It was just a Turborepo scaffold with a single Convex schema file. The `users` table had exactly three fields. The mobile app was a blank Expo template with "Hello World" on the screen.

Looking at it now — with 20,000+ lines of backend code, 30+ database tables, and features I couldn't even imagine back then — it's wild. The codebase grew organically, one problem at a time. One "oh wait, I also need..." at a time.

And that's honestly the best part of building something from scratch. You're not following a tutorial. You're not copying someone else's architecture. You're solving _your_ problems, _your_ way. And sometimes your way is wrong and you refactor everything at 3 AM. But you learn. Every single time.

# Final Thoughts

Lumo is still very much a work in progress. There are features I haven't built yet, bugs I haven't found yet, and architectural decisions I'll probably regret later. But that's the fun of it.

If you're thinking about building your own full-stack app from scratch — do it. Don't overthink the tech stack. Don't wait until you have the "perfect" plan. Just start. The plan reveals itself as you build.

This series is going to be a raw, honest look at what it takes to build something real. Not a toy project. Not a weekend hack. A real application that handles real money (well, tracks it) for real people.

Buckle up, nerds. It's going to be a ride.

Until then, keep coding. ❤️

---

# I Paid for Two Backends Until Turborepo Saved Me (Monorepo Migration with Claude Code)

- **URL**: https://www.rafay99.com/blog/paying-double-turborepo-migration/
- **Published**: 2026-04-07
- **Author**: Abdul Rafay
- **Tags**: Development, Story, WebDevelopment
- **Description**: I was paying for two separate Convex instances for the same project. Here's how I migrated to a Turborepo monorepo with one Claude Code prompt — the technical steps, what broke, and why I'd never go back to separate repos.

## The Pain of Paying Twice for the Same Problem

Let me paint you a picture. I was running **two separate Convex instances** for the same project. Same backend logic, same data models, same everything — except I was paying for it twice and maintaining it in two places. Every schema change meant copy-pasting. Every bug fix meant remembering which repo I was in. It was stupid, and I knew it was stupid, but I kept doing it because the alternative seemed harder.

That project was **Lumo** — my first real attempt at a unified product with a Next.js website and a React Native mobile app. Two codebases, two Convex projects, two bills, one massive headache.

The breaking point? I added a feature to the web app and realized I needed the exact same thing in mobile. Same API calls, same types, same validation. I sat there staring at two VS Code windows thinking: *there has to be a better way.*

## Attempt #1: Cursor Auto-Mode ate my codebase

I'd heard about monorepos. Everyone on Twitter made it sound like a solved problem. "Just use Turborepo," they said. "It's easy," they said.

So I did what any reasonable dev does in 2024: I asked Cursor's auto-mode to "convert this to a monorepo."

**Big mistake.**

It created a plan. It started moving files. And within 20 minutes, my project was broken in ways I didn't understand. Files were in wrong places. Imports were circular. The build system was screaming. I didn't know enough about monorepo structure to fix what Cursor had done, so I did what professionals do: I rage-quit and reverted everything.

Back to two repos. Back to two Convex instances. Back to being miserable, but at least my code ran.

## Claude Code: The One-Shot That Actually Worked

Months later, I got access to Claude Code. People were hyping its "one-shot" capabilities — the idea that you could describe a complex refactor and it would just... do it. I was skeptical, but I was also still paying double for Convex.

I sat down and wrote one massive prompt:

> "This is the backend. This is the Convex of two different projects. This is the frontend of two different projects — the mobile app and the web app. I want a single backend, one Convex instance, all running in a monorepo with Turborepo and Bun."

Then I walked away.

**One hour and fifteen minutes later**, I had a working monorepo. Convex was unified. The web app ran. The mobile app... mostly ran. There was a package resolution issue because I'd put the Convex folder in `packages/` instead of the root, but two more prompts to Claude Code fixed that.

I didn't trust it yet. I created a fresh repo, pushed everything there, and kept the old ones as backup. But it worked. I archived the separate repos that same day.

## The Real Win: Unified Everything

Here's what nobody tells you about monorepos — the structure is just the beginning. The actual magic happens when you start unifying the *boring* stuff.

I had three apps now: web (Next.js), mobile (React Native), and an admin panel (also React Native with Expo Router). Each was using different styling approaches. The web was on Tailwind v4. Mobile was using StyleSheet objects. The admin panel was... a mess I'd asked Claude to whip up because I hate the Convex dashboard.

Then Claude suggested something that should have been obvious: *"You're using Turborepo. Why not unify Tailwind across everything?"*

That clicked hard.

I migrated the mobile app to NativeWind. I rebuilt the admin panel using the same color scheme and design tokens. Then I started extracting shared code into `packages/`:

- `packages/typescript-config` — one tsconfig to rule them all
- `packages/eslint-config` — consistent linting everywhere  
- `packages/tailwind-config` — shared theme, colors, spacing
- `packages/ui` — shared components (still a work in progress)

Now when I run `bun run dev:all`, it spins up:
- Convex dev server
- Next.js web app
- Admin panel
- React Native on emulator

One command. One terminal. One mental context.

## The Tailwind v3/v4 Nightmare (and My Dumb Fix)

Of course, it wasn't all smooth. React Native's NativeWind was stuck on Tailwind v3 while my web app was on v4. The class names were incompatible. The builds were angry.

I could have migrated everything to v4, but that would have meant touching every single style in the mobile app. Instead, I wrote a custom script that switches Tailwind versions based on which app is building. It's a hack. It works. I'm not proud of it, but I'm also not spending three days on a migration that adds zero user value.

Sometimes engineering is knowing which problems to solve with duct tape.

## Project #2: envpilot.dev — Doing It Right From Scratch

With Lumo stable, I started **envpilot.dev** — a tool for managing environment variables across projects. This time I knew what I was doing.

The stack got ambitious fast:
- Next.js web app with Convex backend
- VS Code extension
- CLI tool
- RESTful APIs for the extension/CLI to hit

This is a bigger monorepo than Lumo, and it needed to be. The web app uses WorkOS for auth. The extension and CLI need to authenticate and fetch secrets. Everything shares the same Convex backend, the same types, the same validation logic.

Building this from scratch in a monorepo felt *correct*. No migration pain. No "where should this file go" debates. I knew the structure because I'd already burned myself learning it.

## What's Still Broken (Because Honesty Matters)

Let me be real about what's not perfect:

**Turborepo documentation is fragmented.** There's no "official" way to structure your apps and packages. I looked at the t3 codebase — it's a monorepo with web, server, and Electron apps — and I couldn't make sense of their structure at first. It's valid, it works, but it's not intuitive.

Compare this to something like Django or Laravel. You know what you're getting. There's a `models.py` or `app/Http/Controllers`. The framework *tells* you where things go. Turborepo gives you rope and lets you decide whether to build with it or hang yourself.

**End-to-end testing is still unsolved.** I'm writing unit tests with Vitest. I'm *not* writing good E2E tests because every tool I've tried makes me want to cry. If you know a sane way to E2E test a monorepo with web + mobile + backend, drop a comment. Seriously. Help me.

**The VS Code extension and CLI need love.** The web app is solid — Convex with WebSockets, Zustand for state, the usual stack. But the extension and CLI are using RESTful APIs I wrote, and I'm eyeing tRPC for a rewrite. I've never used tRPC. It might be a disaster. It might be great. That's next month's problem.

## The Hard Truth About Monorepos

Here's what I wish someone had told me: **monorepos don't solve organizational problems, they expose them.**

If your code is messy in separate repos, it'll be messy in one repo — just easier to access. The real benefit is forcing you to confront shared concerns: your types, your validation, your styling, your testing strategy.

You can't hide behind "oh that's in the other repo" anymore. You have to decide: are these actually the same thing, or are they just similar?

For me, the answer was yes — my web and mobile apps *are* the same product. They deserve the same backend, the same design system, the same deployment pipeline. The monorepo structure just made that obvious.

## Folder Structures That Actually Work

Since you asked, here's how I'm structuring things now. This is what works for me — not gospel, just battle-tested:

### Lumo (Web + Mobile + Admin)

```
lumo/
├── apps/
│   ├── web/                 # Next.js 15 + Tailwind v4
│   ├── mobile/              # React Native + NativeWind
│   └── admin/               # Expo Router + Zustand
├── packages/
│   ├── typescript-config/   # Shared tsconfig.json
│   ├── eslint-config/       # Shared lint rules
│   ├── tailwind-config/     # Shared theme (v3/v4 switcher)
│   └── ui/                  # Shared components (WIP)
├── convex/                  # Backend at root, not in packages
├── turbo.json               # Pipeline definitions
└── package.json             # Bun workspace root
```

### envpilot.dev (Web + Extension + CLI)

```
envpilot/
├── apps/
│   ├── web/                 # Next.js + Convex
│   ├── vscode-extension/    # Extension host + webview
│   └── cli/                 # Node.js CLI tool
├── packages/
│   ├── typescript-config/
│   ├── eslint-config/
│   ├── api/                 # Shared API client (REST → tRPC soon?)
│   ├── types/               # Shared Convex types
│   └── ui/
├── convex/
├── turbo.json
└── package.json
```

The key insight: **Convex lives at root**, not in `packages/`. It's your backend, not a shared library. Treating it as a package created circular dependency hell for me.

## Should You Do This?

If you're maintaining multiple apps that share a backend, yes. The unified development experience is worth the migration pain.

If you're building one app and think monorepos look cool, probably not. You're adding complexity without solving a real problem.

And if you're migrating, here's my advice: **use Claude Code, not Cursor auto-mode.** The difference in context window and reasoning is real. But also — **understand what it's doing.** I got lucky the first time, but I also spent hours reading the generated config files, tracing imports, understanding why things were placed where they were.

AI can get you 90% there. The last 10% — the debugging, the edge cases, the "why isn't this caching" — that's still you.

## What's Next

I'm eyeing tRPC for envpilot's extension and CLI. I'm trying to figure out E2E testing that doesn't make me miserable. And I'm still refining that `packages/ui` folder — shared components across web and mobile is harder than it sounds when one uses divs and the other uses View.

But I can spin up my entire stack with one command now. My types are shared. My backend is unified. I'm paying for one Convex instance.

Was it worth the pain? Absolutely.

Would I do it again? I'd do it right from the start.

*Leave a comment if you've got E2E testing strategies that actually work, or if you think I'm wrong about tRPC. I'm always learning.*

*Until then, peace out, nerds.* 👓

---

# The .env File That Could Kill Your Startup (And How AI Agents Make It Worse)

- **URL**: https://www.rafay99.com/blog/env-vars-the-silent-killer/
- **Published**: 2026-04-05
- **Author**: Abdul Rafay
- **Tags**: Security, DevOps, Backend, Git, AI, Developer
- **Description**: Why environment variable leaks are more dangerous than most developers realize — a real story of a .env file committed to staging, why git never forgets, and how AI agentic workflows are making secret leaks significantly worse in 2026.

# The `.env` File That Could Kill Your Startup

Let me tell you something that happened on one of my teams.

A junior dev — talented, fast, genuinely excited about shipping — committed a `.env` file to a staging repo. It had API keys, database credentials, the whole configuration dump. Nobody caught it in the PR review. It sat there for a few days before someone noticed. We panicked, deleted the file, pushed a new commit, and thought: _"okay, it's gone."_

It was not gone.

Git never forgets. That's not a metaphor — it's literally how the tool works. The commit hash still existed. The history was still there. Anyone who cloned or forked the repo in that window had a full copy of the credentials. We were lucky nothing got exploited.

That incident is part of why I'm writing this post, and also part of why I started building **ENV Connect** — an internal tool to give teams the access they need without giving them the ability to accidentally commit what they shouldn't. More on that later.

But first, let's talk about the actual problem. Because "don't commit your `.env` file" is the beginner lesson, and most developers have heard it. The deeper problem is that environment variables are more complex than they look, the consequences of getting them wrong are more severe than most people realize, and in 2026, AI tooling is actively making the situation worse.

---

## First, Let's Talk About What an Environment Variable Actually Is

I know. You know what an env var is. But bear with me for a second, because the real problem isn't what they are — it's that most developers treat them as one flat category of thing. They're not.

Environment variables live at three distinct layers of your system, and those layers behave in fundamentally different ways.

```mermaid
flowchart TD
    A[🖥️ Your Machine] --> B[OS-Level Variables]
    A --> C[Build-Time Variables]
    A --> D[Runtime Variables]

    B --> B1["Injected via 
    C --> C1["Baked into the artifact at compile time\nLives inside Docker image layers\nVite: VITE_API_URL bundled into JS\nCannot be removed without rebuilding"]
    D --> D1["Injected at runtime by K8s or ECS or CI\nSecret never touches the codebase\nGold standard when done correctly\nStill visible in process lists if naive"]

    style B fill:#f0a500,color:#000
    style C fill:#e05252,color:#fff
    style D fill:#3cb371,color:#fff
```

**OS-level variables** are the ones your operating system knows about. When you type `

**Build-time variables** are a different beast entirely. These are values baked into your application during compilation or bundling. Think `ARG` in a Dockerfile or `VITE_API_URL` in a Vite app. If you pass a secret as a build-time variable, it gets burned into the artifact itself — the Docker image layer, the JavaScript bundle, the compiled binary. You cannot "delete" it from the artifact later without rebuilding. Any layer in a Docker image that touched a secret can expose it through `docker history`. Multi-stage builds with BuildKit's secret mount feature exist specifically to solve this, but not enough people use them.

**Runtime variables** are what most people _think_ they're using. These are injected into your running application by your container orchestrator (Kubernetes, ECS, whatever), your CI/CD pipeline, or a secrets manager. Done right, this is the gold standard — the secret never lives in your codebase, never gets baked into an image layer, and only exists in memory for the duration of the process.

The gap between understanding _that_ these three layers exist and understanding _how_ to handle each one correctly is where most leaks happen.

---

## The Lifecycle of a Secret (and Where Things Go Wrong)

Here's the full journey a secret takes from your brain to production — and the danger zones at every step:

```mermaid
flowchart LR
    Dev["👨‍💻 Developer\nwrites code"] --> Local[".env file\nlocal machine"]
    Local -->|".gitignore MISSING\n❌ DANGER ZONE"| Git["Git History\n☠️ PERMANENT"]
    Local -->|"CI/CD secrets\n✅ Correct path"| CICD["CI/CD Pipeline\nGitHub Actions / GitLab"]
    CICD -->|"Inject at runtime"| Deploy["Running App\nin Production"]
    CICD -->|"Baked in build\n⚠️ DANGER ZONE"| Image["Docker Image\nLayers exposed"]
    Image --> Deploy
    Git -->|"Repo goes public\nor gets forked"| Attacker["🎣 Attacker\nscrapes in seconds"]
    Deploy -->|"Secrets printed\nin logs\n⚠️ DANGER ZONE"| Logs["Log Aggregator\nDatadog / Splunk"]

    style Git fill:#e05252,color:#fff
    style Attacker fill:#990000,color:#fff
    style Image fill:#f0a500,color:#000
    style Logs fill:#f0a500,color:#000
    style CICD fill:#3cb371,color:#fff
    style Deploy fill:#3cb371,color:#fff
```

Notice how many paths lead somewhere dangerous. The "correct" path is actually a narrow corridor. Everything else is a potential leak surface.

---

## The Git History Problem Is Worse Than You Think

Here's the number that should scare you: in 2024 alone, GitHub detected over 39 million leaked secrets across its platform. Not "suspicious code." Not "potential issues." Verified secrets — API keys, tokens, credentials — with the number growing year over year.

And here's the part people miss: deleting a file doesn't delete the commit. Pushing a "fix" that removes the `.env` doesn't remove the `.env` from your history. Making the repository private after the fact doesn't help if anyone forked or cloned it before you flipped that switch.

```mermaid
sequenceDiagram
    participant Dev as 👨‍💻 Developer
    participant Git as Git History
    participant GitHub as GitHub
    participant Scanner as 🤖 Secret Scanner
    participant Attacker as 🎣 Attacker

    Dev->>Git: git add .env (oops)
    Dev->>GitHub: git push
    GitHub->>Scanner: Scan triggered
    Scanner-->>Dev: ⚠️ Alert (if enabled)
    Note over GitHub: Commit hash: a1b2c3d4 PERMANENT
    Dev->>Git: git rm .env
    Dev->>GitHub: git push "fix: remove .env"
    Note over GitHub: a1b2c3d4 STILL EXISTS in history
    Attacker->>GitHub: git clone / fork
    Attacker->>Git: git show a1b2c3d4:.env
    Git-->>Attacker: DATABASE_URL=postgres://user:pass@prod...
    Note over Attacker: Credentials still LIVE ✅
```

Truffle Security researchers scanned GitHub's so-called "oops commits" — force-pushed or deleted commits that remain archived — and found thousands of still-active credentials. Not historical curiosities. Live, working, exploitable secrets that developers thought they'd cleaned up.

GitGuardian's 2025 State of Secrets Sprawl report found something even more uncomfortable: 70% of secrets leaked in 2022 are still active today. Developers rotate their keys when they remember to, or when they get an alert, or when something breaks. The rest just sit there. Waiting.

The average cost of a data breach in 2024 crossed $4.45 million — and a significant number of those breaches trace back to a single exposed credential that nobody thought to revoke.

Even OWASP says that environment variables themselves are not recommended for production secrets because they're accessible to all processes and tend to appear in logs and system dumps. Their actual guidance is in-memory shared volumes or dedicated secrets managers. Most teams aren't there yet.

Private repositories aren't a safe harbor either. GitGuardian found that 35% of customers' private repositories contain plaintext secrets. AWS IAM keys appear 5× more frequently in private repos than public ones — people think the privacy label means they can relax. They can't.

---

## The AI Agentic Workflow Problem

This is the part that actually worries me right now.

For years, the env-leak problem was caused by human forgetfulness. "We were moving fast." "We forgot `.env` wasn't in `.gitignore`." "We'll clean it up later." Understandable. Fixable with better habits and tooling.

Now we have a new vector: AI agents that can write code _and_ commit it.

```mermaid
flowchart TD
    User["👤 Developer\nTell AI: Integrate Stripe,\ntest it, commit and push"] --> Agent["🤖 AI Coding Agent\nCursor / Copilot / Codex"]
    Agent --> Code["Writes integration code"]
    Agent --> Hardcode["Hardcodes test key\nsk_test_4eC39HqLyjWDarjtT7i"]
    Agent --> Commit["git commit -m 'add Stripe'"]
    Agent --> Push["git push to main"]
    Hardcode --> Push
    Push --> GitHub["GitHub / GitLab\n🔓 Secret now in history"]
    GitHub --> Scanner["Secret Scanner\nDetects in ~60 seconds"]
    GitHub --> Attacker["🎣 Attacker\nalso detects in ~60 seconds"]

    style Hardcode fill:#e05252,color:#fff
    style GitHub fill:#f0a500,color:#000
    style Attacker fill:#990000,color:#fff
    style Scanner fill:#3cb371,color:#fff
```

GitGuardian found that repositories where GitHub Copilot is active have a 40% higher secret leak rate than repositories without it. The tool that's supposed to make you more productive is statistically correlated with more security incidents. Why? Because AI coding assistants write code fast, they follow patterns from training data (which includes bad patterns), and they have no concept of what a secret _means_ or what happens when one gets exposed.

You tell your agentic workflow: "Integrate Stripe, test it, commit, and push." The agent writes the integration, hardcodes the test key, writes the commit message, and pushes. It's not malicious. It doesn't understand the difference between a string literal and a credential. It's just doing what you asked.

Wiz scanned the Forbes AI 50 companies — the cream of the AI startup crop — and found that 65% of them had leaked verified secrets on GitHub. These are well-funded, technically sophisticated teams. The most common sources: `.env` files, Python scripts, and Jupyter notebooks.

One leaked Hugging Face token belonging to an AI 50 company exposed access to roughly 1,000 private models. Someone with that token could download or inspect proprietary training data and model weights. That's not an inconvenience — that's an existential IP risk.

---

## What the Industry Has Built to Solve This

The good news is that the tooling landscape is genuinely mature now. The bad news is that most teams are using only a fraction of it.

```mermaid
flowchart TD
    subgraph Prevention["🛡️ Prevention Layer"]
        P1[".gitignore\nBlock .env files from ever entering git"]
        P2["Pre-commit hooks\ngitleaks / git-secrets scan before push"]
        P3["Secrets Manager\nVault / AWS SSM / Doppler / Infisical"]
    end

    subgraph Detection["🔍 Detection Layer"]
        D1["Push Protection\nGitHub blocks secrets at push time"]
        D2["CI/CD Scanning\ngitleaks in pipeline — fails build on leak"]
        D3["History Scanning\ngitleaks detect --log-opts=--all"]
    end

    subgraph Remediation["🚑 Remediation Layer"]
        R1["Rotate the credential FIRST\nThis is the only real fix"]
        R2["Clean history with git-filter-repo\nor BFG Repo-Cleaner"]
        R3["Contact GitHub support\nto permanently remove orphan commits"]
    end

    Prevention --> Detection
    Detection --> Remediation

    style Prevention fill:#3cb371,color:#fff
    style Detection fill:#f0a500,color:#000
    style Remediation fill:#e05252,color:#fff
```

**Pre-commit scanning** is your first line of defense. Tools like `gitleaks` and `git-secrets` run locally before a commit ever reaches the remote. They scan for patterns matching known secret formats — AWS keys, Stripe tokens, database URLs — and block the push if they find something. If your team isn't running pre-commit hooks that scan for secrets, you're relying entirely on humans to not make mistakes. That's not a security model.

**Push protection** at the platform level is now on by default for public GitHub repositories. GitHub has a partnership program with hundreds of token issuers — AWS, Google Cloud, OpenAI, Meta — where detected secrets trigger immediate notification to the issuer, who can then revoke the credential. This is genuinely impressive infrastructure. It's also a last resort, not a first defense.

**Secrets managers** — AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, Azure Key Vault, Doppler, Infisical — are the production-grade answer. Instead of putting your database password in an env var, you put the _path to the secret_ in an env var, and your application fetches the actual value at runtime from the secrets manager. The secret never lives in your codebase, your Dockerfile, or your CI/CD config.

---

## The Right Architecture: How It Should Actually Look

This is the pattern that separates teams that sleep well from teams that get Slack messages at 2 AM:

```mermaid
flowchart LR
    subgraph Dev["🖥️ Local Development"]
        EnvExample[".env.example\nCommitted to git\nNo real values — just keys"]
        EnvLocal[".env.local\n.gitignored\nReal local values only"]
    end

    subgraph CICD["⚙️ CI/CD Pipeline"]
        CISecrets["Encrypted CI Secrets\nGitHub Actions / GitLab CI\nInjected at build time only"]
    end

    subgraph Prod["🏭 Production"]
        SecretsManager["Secrets Manager\nVault / AWS SSM / Infisical\nEncrypted, access-controlled, audited"]
        App["Running Application\nFetches secrets at startup\nNever stored to disk"]
    end

    EnvExample -->|"Developers clone and fill locally"| EnvLocal
    CISecrets -->|"Injected as env vars during pipeline"| CICD
    SecretsManager -->|"App fetches at runtime via SDK"| App

    style EnvExample fill:#3cb371,color:#fff
    style EnvLocal fill:#3cb371,color:#fff
    style CISecrets fill:#3cb371,color:#fff
    style SecretsManager fill:#3cb371,color:#fff
    style App fill:#3cb371,color:#fff
```

The principle is simple: **your codebase should only ever contain references to secrets, never the secrets themselves.** Your `.env.example` should be committed (with placeholder values). Your real `.env` should never be committed, ever, under any circumstances.

---

## The Tooling Stack I'd Actually Recommend

If you're building something real, here's what I'd put in place:

1. **`.gitignore` first, forever.** `.env`, `.env.local`, `.env.production`, `*.pem`, `*.key` — all of it. Before you write a single line of code in a new project. Not after.

2. **Pre-commit hooks with `gitleaks`.** One command to install, catches most patterns automatically. Add it to your onboarding docs and make it non-optional for the whole team.

3. **`git-filter-repo` if you've already leaked something.** After you've cleaned history, rotate the credential regardless — cleaning history doesn't guarantee the secret wasn't already harvested.

4. **A secrets manager for anything that matters.** HashiCorp Vault if you want self-hosted and maximum control. AWS Secrets Manager if you're on AWS already. Doppler or Infisical if you want something with a nicer developer experience. Your application fetches the secret dynamically at runtime, not at build time, not from a file.

5. **CI/CD secrets injection, not dotenv files.** GitHub Actions has encrypted secrets. GitLab has CI/CD variables. Use them. Your production credentials should never exist in a file that touches a developer's laptop.

6. **Repository history scanning.** Run `gitleaks detect --source . --log-opts="--all"` on every branch. You might find things you'd rather know about before someone else does.

---

## What I'm Building: ENV Connect

This whole situation — the junior dev incident, the constant cycle of "someone committed what?" — is what pushed me to start building something internally called **ENV Connect** (the name will probably change, but the idea is solid).

```mermaid
flowchart TD
    Admin["👑 Admin / Senior Dev\nFull control over all secrets"]
    Admin -->|"Define secrets\nSet role permissions"| ENVConnect["🔐 ENV Connect\nCentralized secret store\nRole-based access control"]

    ENVConnect -->|"Read-only local config\nNo export, no copy to clipboard"| Junior["👶 Junior Dev\nCan run the app locally\nCannot see prod secrets"]
    ENVConnect -->|"Dev and staging access"| Mid["👨‍💻 Mid-level Dev\nStaging environment access"]
    ENVConnect -->|"Full environment access"| Senior["🧑‍💻 Senior Dev\nAll environments"]
    ENVConnect -->|"Secrets injected at deploy\nNever touches developer laptops"| Prod["🏭 Production\nRuntime injection only"]

    style ENVConnect fill:#3cb371,color:#fff
    style Admin fill:#f0a500,color:#000
    style Junior fill:#cccccc,color:#000
    style Mid fill:#aaaaaa,color:#000
    style Senior fill:#888888,color:#fff
    style Prod fill:#3cb371,color:#fff
```

The core problem I keep running into: I need to give developers access to the environment variables they need without giving them the ability to 

It's an early prototype. But the direction feels right: treat secrets as a separate concern from both the codebase and the developer's local machine.

---

## The Uncomfortable Reality

Here's what I keep coming back to: this problem isn't going away, and AI tooling is making it worse before it gets better.

We're in an era where AI agents can commit and push code autonomously. Where "vibe coding" is a legitimate workflow at funded startups. Where a non-technical founder can spin up a full application using natural language prompts and have it deployed to production in an afternoon — without ever thinking about whether their Stripe webhook secret just ended up in a public repository.

The industry has known about this problem since at least 2017, when TruffleHog was first published. Awareness has not eliminated it. The number of leaked secrets has gone up every single year. The reason is structural: the incentives reward shipping fast, and the consequences of leaked credentials are delayed and often invisible until they're catastrophic.

If you're raising real money, building a real product, handling real user data — this is not a "we'll clean it up later" item. A single leaked AWS key can be picked up by an automated scanner within minutes of hitting a public repo. The scanners never sleep. The cleanup is never simple. And the git history never forgets.

The `.env` file is not configuration. It's a target. Treat it like one.

---

_Building something in the secrets management space? Dealing with this exact problem on your team? Find me on Twitter or GitHub — always happy to talk shop._

---

# You've Been Making API Calls Wrong This Whole Time (And So Has Everyone Else)

- **URL**: https://www.rafay99.com/blog/api-networking-deep-dive/
- **Published**: 2026-03-07
- **Author**: Abdul Rafay
- **Tags**: API, Networking, AI, OpenAI, WebSocket, Backend, Developer
- **Description**: How networking actually works in your app, why your AI chatbot is choking on its own history, and why OpenAI just flipped the script with Realtime WebSocket

Let me say something that's going to upset a few senior developers out there:

**Most devs with 3+ years of experience still have no idea how networking actually works inside their own applications.**

I'm not being mean. I'm being honest. You can build a full SaaS, ship it to production, handle thousands of users — and still have zero mental model of what happens the moment your code fires off an `axios.post()` or a `fetch()`. You just trust the library, trust the API, trust the vibes, and pray the response comes back in under 500ms.

That ends today. We're going to talk about how an API call actually works, how traffic flows through your stack, and — the part most tutorials completely skip — how AI model APIs operate differently from everything else you've used. Then we're going to talk about why every chatbot you've built has a dirty little secret that's quietly burning your tokens and your users' patience. And finally, I'll tell you about a new standard that I think is genuinely exciting.

Buckle up.

## First, What Even Is an API Call?

Okay, basics — but the boring basics matter.

When your frontend makes an API call, here's what actually happens at the network level:

1. Your code constructs an **HTTP request** — a method (GET, POST, etc.), a URL, some headers, maybe a JSON body.
2. That request gets broken into **TCP packets** and routed across the internet through a chain of servers, load balancers, and infrastructure that you have never thought about for even one second.
3. The request hits your **API server** (maybe behind an Nginx reverse proxy, maybe behind an API gateway like Kong or AWS API Gateway). The server authenticates the request, validates it, and hands it off to your application logic.
4. Your app does its thing — hits a database, calls another service, computes something — and builds a **response**.
5. That response travels back across the same chain of infrastructure.
6. Your client receives it. Your `then()` block fires. Life is good.

Sounds simple. And for basic CRUD apps, it kind of is.

```mermaid
sequenceDiagram
    participant FE as 🖥️ Frontend
    participant GW as 🛡️ API Gateway
    participant APP as ⚙️ App Server
    participant DB as 🗄️ Database

    FE->>GW: HTTP Request (method + headers + body)
    GW->>GW: Auth check, rate limit, SSL termination
    GW->>APP: Forward validated request
    APP->>DB: Query / write data
    DB-->>APP: Result
    APP-->>GW: HTTP Response (JSON)
    GW-->>FE: Response delivered
    Note over FE,GW: Connection closed ❌ — stateless, fire-and-forget
```

But here's where 90% of developers stop thinking about it. They treat the API like a magic function call. Hit endpoint, get data. Move on. They never think about:

- **What happens if the connection drops mid-request?**
- **What's inside the request payload — and how big is it?**
- **Who's managing the state of this conversation?**

That last one? That's where it gets spicy, especially when AI enters the picture.

## The Traffic Reality Nobody Talks About

Before we get to AI, let's talk about traffic management — because this is the layer most junior AND mid-level devs completely ignore.

When you have a production API, your requests don't just fly directly to your application server. They usually go through a few checkpoints:

**Load Balancers** distribute incoming traffic across multiple instances of your server. Without one, a traffic spike kills you. With one, you survive Black Friday. AWS ALB, Nginx, HAProxy — pick your poison.

**API Gateways** sit in front of everything and handle cross-cutting concerns: rate limiting, authentication, SSL termination, request logging, caching. Think of it as the bouncer at the club. No ticket? No entry. Too many requests? Slow down, buddy.

**CDNs** cache responses at edge locations closer to your users. Static content? Serve it from the edge, never hit your origin. Cloudflare, AWS CloudFront, Vercel's edge network — these shave hundreds of milliseconds off your response times.

**Circuit Breakers** detect when a downstream service is failing and stop routing traffic to it, preventing cascade failures. If your payment gateway is down, your circuit breaker should catch that before it takes down your whole checkout flow.

Most tutorials teach you how to build an API. Almost none of them teach you how to *operate* one. And the difference between those two things is the difference between a side project and a production system.

```mermaid
flowchart TD
    USER["👤 User / Client"] -->|HTTPS Request| CDN

    CDN["🌍 CDN\n(Cloudflare / CloudFront)\nCache static content at the edge"]
    CDN -->|Cache miss — forward request| LB

    LB["⚖️ Load Balancer\n(AWS ALB / Nginx / HAProxy)\nDistributes traffic across instances"]
    LB --> GW

    GW["🛡️ API Gateway\n(Kong / AWS API GW)\nRate limiting · Auth · Logging · SSL"]
    GW --> CB

    CB["🔌 Circuit Breaker\nDetects failing services\nPrevents cascade failures"]
    CB --> S1 & S2

    S1["⚙️ App Server 1"]
    S2["⚙️ App Server 2"]

    S1 & S2 --> DB[("🗄️ Database")]

    style CDN fill:#1a1a2e,color:#e0e0ff,stroke:#7c7cff
    style LB fill:#16213e,color:#e0e0ff,stroke:#7c7cff
    style GW fill:#0f3460,color:#e0e0ff,stroke:#7c7cff
    style CB fill:#533483,color:#ffffff,stroke:#9f7eda
    style S1 fill:#1a472a,color:#ffffff,stroke:#52b788
    style S2 fill:#1a472a,color:#ffffff,stroke:#52b788
    style DB fill:#2d2d2d,color:#ffffff,stroke:#aaaaaa
    style USER fill:#2c1810,color:#ffccaa,stroke:#ff8c42
```

## Now, AI APIs — This Is Where It Gets Different

Okay. You've been making regular REST API calls. You sort of get it. Now someone tells you to integrate OpenAI or Anthropic's Claude into your app. How different could it be?

*Very* different. Let me explain.

With a normal REST API, you send a request and you get a response. The server is stateless — it doesn't remember your last call, doesn't care about your history, doesn't need to know anything beyond what you send in this request. Clean. Simple.

AI language models don't work that way. **They need context to be useful.**

When you send a message to GPT-4 or Claude, the model doesn't magically remember your last conversation. There's no persistent memory living in some server. The model is fundamentally stateless. So to make it *feel* stateful — to make it feel like it knows what you were just talking about — your application has to **manually send the entire conversation history** with every single request.

Every. Single. Request.

Think about what that means. You have a chatbot. A user starts a conversation. After 10 turns back and forth, your API request body looks something like this:

```json
{
  "model": "gpt-4",
  "messages": [
    { "role": "user", "content": "Hey, what's the capital of France?" },
    { "role": "assistant", "content": "The capital of France is Paris." },
    { "role": "user", "content": "What's the population?" },
    { "role": "assistant", "content": "Paris has a population of around 2.1 million..." },
    ...
    { "role": "user", "content": "Ok now I want to plan a trip there" }
  ]
}
```

This is called **the context window**. And it's both the superpower and the Achilles heel of every AI chatbot ever built.

```mermaid
sequenceDiagram
    participant U as 👤 User
    participant APP as 🖥️ Your App
    participant OAI as 🤖 OpenAI / Claude API
    participant GPU as ⚡ GPU Cluster

    U->>APP: "Hey, capital of France?"
    APP->>OAI: Request: [msg 1]  📦 small payload
    OAI->>GPU: Process 1 message
    GPU-->>APP: "Paris"
    APP-->>U: "Paris"

    U->>APP: "What's the population?"
    APP->>OAI: Request: [msg 1 + msg 2]  📦📦 bigger
    OAI->>GPU: Process 2 messages
    GPU-->>APP: "2.1 million..."
    APP-->>U: "2.1 million..."

    U->>APP: "Plan a trip for me"
    APP->>OAI: Request: [msg 1 + msg 2 + ... msg 20]  📦📦📦📦📦 HUGE
    Note over APP,OAI: 🚨 Entire conversation history resent EVERY TIME
    OAI->>GPU: Process ALL 20 messages just to answer turn 21
    GPU-->>APP: Response...
    Note over GPU: 💸 You're paying tokens for msg 1-20 again. And again. And again.
```

## The Context Problem: Why Your Chatbot Is Eating Itself

Here's the dirty truth that nobody puts in their "Build a ChatGPT Clone in 30 Minutes" tutorial.

Every time your user sends a new message, you're not just sending that message. You're sending **the entire conversation** — all previous messages, all previous responses, everything — as one giant payload to the AI provider's endpoint. Then that endpoint forwards the whole thing to the GPU cluster, the model reads ALL of it to understand what's happening, and finally generates a response for the new message.

As the conversation gets longer, a few ugly things happen:

**1. Your payload gets enormous.** You're re-sending 20, 30, 50 message turns with every single request. That's a lot of data flying across the wire, over and over and over.

**2. Your latency creeps up.** The model has to process more tokens. More tokens = more compute = more time. That snappy first response? By message 40, it's not so snappy.

**3. Your costs go parabolic.** Most AI APIs charge per token. You're paying for the entire conversation history on every call. A 50-turn conversation with rich responses means you're billing the user's early messages *50 times* across the lifetime of that chat.

**4. You hit the context limit.** Models have a maximum context window. GPT-4 has 128k tokens, Claude has even more — but they're not infinite. When you blow past the limit, you have to start truncating or summarizing old messages. Now your bot starts "forgetting" things, and users get confused.

This model of passing full context on every request was essentially **standardized by OpenAI in 2023-2024**. Everyone in the industry adopted it. Every tutorial teaches it. Every chatbot you've used is probably built on it. And it works — don't get me wrong, it *works* — but it has fundamental efficiency problems baked into its architecture.

The connection that sent message number one is long gone by the time you're sending message number twenty. Each new message is a brand new HTTP connection, a brand new handshake, a brand new payload containing the full weight of the entire conversation. It's like calling a customer service rep, explaining your whole situation, getting an answer, *hanging up*, then calling back with the same full explanation just to ask one follow-up question. Every time.

## The New Thing I'm Actually Excited About: OpenAI Realtime WebSocket

This is where it gets interesting.

OpenAI has been pushing a new approach: [the Realtime API with WebSocket](https://developers.openai.com/api/docs/guides/realtime-websocket).

Instead of stateless HTTP request-response cycles, you open a **persistent WebSocket connection** between your app and the model. The connection stays open. The model maintains a live session. You send events down the pipe, get events back — all in real time, over a single persistent connection.

What does this change?

**No more re-sending the full context every turn.** The session is persistent. The model already knows what was said. You just send the new message.

**True streaming, not fake streaming.** With regular streaming (SSE over HTTP), you get tokens trickling in but you still sent the full payload. With WebSocket, it's a bidirectional real-time channel. You can send audio, receive audio, handle interruptions, manage tool calls — all without the overhead of re-establishing a connection.

**Lower latency for multi-turn conversations.** The roundtrip for each message is dramatically shorter when you're not re-building and transmitting a multi-kilobyte context payload every single time.

**Audio natively supported.** This isn't just for text. The Realtime API was designed with voice interactions in mind. Send audio in, get audio out, no intermediate transcription layer needed.

Is this going to replace the standard request-response pattern for every use case? No. For simple one-shot queries, regular API calls are totally fine. But for **live conversational agents, voice interfaces, multi-step agentic workflows** — this is genuinely a better architecture.

```mermaid
flowchart LR
    subgraph OLD["❌ Old Way — Stateless HTTP"]
        direction TB
        C1["Client"] -->|"📦 Full history + new msg\nPOST /chat/completions"| M1["Model"]
        M1 -->|Response| C1
        C1 -->|"📦📦 Full history + new msg\n(again)"| M1
        M1 -->|Response| C1
        C1 -->|"📦📦📦 Full history + new msg\n(again & again)"| M1
    end

    subgraph NEW["✅ New Way — Realtime WebSocket"]
        direction TB
        C2["Client"] -->|"🔌 Open persistent connection once"| M2["Model Session"]
        C2 <-->|"💬 Just the new message"| M2
        C2 <-->|"🎙️ Audio event"| M2
        C2 <-->|"🔧 Tool call result"| M2
        Note2["Session stays open.\nModel remembers context.\nNo repeated payloads.\nBidirectional. Real-time."]
    end

    style OLD fill:#2d0000,color:#ffaaaa,stroke:#ff4444
    style NEW fill:#002d00,color:#aaffaa,stroke:#44ff44
    style Note2 fill:#003300,color:#88ff88,stroke:#44ff44
```

The industry is starting to shift. And if you're building anything that involves sustained multi-turn interaction with an AI model, you need to understand this pattern before your competitors do.

## So What Does This Mean for You, the Developer?

A few practical takeaways:

**Understand your payload.** Log your API requests in development. Actually look at how big that messages array is getting. You'll be surprised.

**Implement context management.** Don't naively append every message forever. Implement windowing — keep the last N turns, or summarize older context. Your costs and your latency will thank you.

**Use streaming.** Whether you're on HTTP SSE or WebSocket, don't wait for the full response before showing the user anything. Stream tokens as they arrive. The perceived performance difference is massive.

**Consider WebSocket for stateful agents.** If you're building something that's meant to have a long-running conversation — a voice assistant, a coding agent, a customer service bot — look seriously at the Realtime API. The per-request context overhead of HTTP might be the wrong model for your use case.

**Think about the infrastructure, not just the endpoint.** Rate limits, retry logic, fallback providers, token budgeting — these aren't optional nice-to-haves. They're what separates a toy from a product.

## The Bottom Line

APIs are not magic function calls. Networking is not an abstraction you can afford to ignore. And AI APIs are a fundamentally different beast from the REST endpoints you've been using to fetch user data or process payments.

The pattern that the entire industry standardized around — stateless HTTP with full context re-sent on every call — made perfect sense in 2023. It was a clean, understandable, universally supported approach. It got a million products shipped. But it has real costs at scale, real latency implications, and real architectural limits.

OpenAI's push toward WebSocket-based persistent sessions isn't just a performance optimization. It's a signal that the way we think about AI integration in applications needs to evolve. The model isn't a vending machine you hit with a coin and wait for candy. It's more like a collaborator — and persistent connections are a more honest reflection of what that actually means.

Learn how the network works. Think about your payloads. And keep an eye on where the standards are going.

Because the devs who understand this stuff aren't just building faster apps. They're building *fundamentally different* ones.

*References:*
- *OpenAI Realtime API with WebSocket: [https://developers.openai.com/api/docs/guides/realtime-websocket](https://developers.openai.com/api/docs/guides/realtime-websocket)*
- *OpenAI Realtime API Overview: [https://developers.openai.com/api/docs/guides/realtime](https://developers.openai.com/api/docs/guides/realtime)*
- *OpenAI Conversation State Guide: [https://developers.openai.com/api/docs/guides/conversation-state](https://developers.openai.com/api/docs/guides/conversation-state)*

---

# Your AI Coding Agent Has a Personality Disorder — And You're Enabling It

- **URL**: https://www.rafay99.com/blog/ai-coding-agent-personality-disorder/
- **Published**: 2026-03-05
- **Author**: Abdul Rafay
- **Tags**: AI, DevelopmentTools, ThoughtsProcess
- **Description**: Why does Claude rewrite your auth layer at 2am while Codex stares at a CSS bug and refuses to touch it without a screenshot?

We don't talk enough about the fact that AI coding models have personalities.

Not in the cute, anthropomorphized "oh, ChatGPT is so polite" way. I mean genuine, reproducible behavioral patterns that will absolutely wreck your afternoon if you don't understand them. Patterns that no benchmark captures, no system card documents, and no Twitter thread adequately explains.

I've been shipping production code with both Claude Opus 4.6 and GPT-5.3 Codex since they dropped on the same day — February 5th, 2026. Not toy projects. Not LeetCode. Real, messy, "why-is-there-a-Zustand-store-from-three-founders-ago" codebases. And after weeks of this, I can tell you with absolute certainty: these models don't just differ in capability. They differ in temperament.

One is the overcaffeinated senior engineer who rewrites your auth layer while you asked it to fix a button color. The other is the paranoid new hire who reads your entire repo before changing a single line — and then sometimes just... doesn't.

Let me explain.

## Claude Opus 4.6: The Three-Coffees-Deep Architect Who Can't Stay in Lane

Opus is brilliant. Genuinely, terrifyingly brilliant. It will look at your vague one-liner prompt, infer three levels of architectural intent you didn't even have, and start executing a plan across 12 files simultaneously.

That's the problem.

### The Eager Overreach

You ask Opus to fix a padding issue on your dashboard card component. It fixes the padding. Great. But it also notices your CSS uses inline styles in some places and Tailwind in others, decides that's unacceptable, refactors your entire styling approach, touches your auth middleware because it imported a shared utility that it "improved," and introduces a race condition in your data fetching hooks because it reorganized the import chain.

I've watched this happen in real time. You give it a scalpel task, and it performs open-heart surgery.

Developers on GitHub have documented this pattern extensively. One user described Opus as a model that "sometimes 'improves' things you didn't ask for" — noting that Sonnet actually obeys negative constraints like "don't rename variables" more reliably than the supposedly smarter Opus. This isn't a bug. It's a behavioral pattern baked into how the model reasons about code.

### The Session Amnesia Problem

Here's what nobody warns you about: Opus is inconsistent across sessions. It follows your coding conventions perfectly on Tuesday. By Thursday, it's generating completely different patterns for the same type of component. Your `CLAUDE.md` becomes less of a nice-to-have and more of a life-support system.

Developers have started building what one described as a "second brain" — a layered `CLAUDE.md` with project context, hard constraints, and a current-status section that gets updated at the end of every session. Without it, every new session is like onboarding a new contractor who has amnesia.

The community-sourced fix is almost elegant in its desperation: keep sessions short, prime aggressively, update your `CLAUDE.md` before closing. Because Claude Code's 200K-token context window sounds massive until you realize that context bloat degrades performance. The more you chat, the dumber it gets. The solution is to treat each session like a burner phone — use it, toss it, start fresh.

### The RAM Situation

I've watched Claude Code balloon from 200MB to nearly 9GB during a long session. For a tool that's supposed to run alongside Docker, VS Code, Spotify, and your existential dread — that's disqualifying for any serious multi-hour workflow. Your MacBook doesn't have infinite memory, and Opus apparently thinks it does.

## GPT-5.3 Codex: The Paranoid New Hire Who Reads Everything and Touches Nothing

If Opus is the reckless architect, Codex is the careful new hire who wants to understand your entire system before making their first commit. It reads your codebase like it's studying for a final exam.

That sounds great until you realize it sometimes just stops.

### The Laziness Problem

This is the most documented and most infuriating Codex behavior. Developers have filed GitHub issues describing it bluntly: "GPT-5.3-Codex is lazy and irrationally terrified of breaking anything."

Here's what that looks like in practice: You ask Codex to refactor some logic from File A into File B. Simple move-and-reorganize. Instead of doing the move, it adds "compatibility glue" — wrapper functions, shim imports, redundant abstractions — because it's petrified of breaking something. Even when you're doing a pure internal refactor with zero external dependents.

Worse: it modifies tests to vacuously pass. It doesn't fix the test to match the new code. It rewrites the assertion so that anything passes. If you're not watching like a hawk, you'll merge a green CI pipeline that proves absolutely nothing.

One developer summarized it perfectly: "The model is really great in a lot of areas, and Codex in general is much faster than Claude Code and seems way more token-efficient, but the amount of human attention it's taking from me to get it to behave rationally has become too much."

### The Ghost Mode Bug

This is genuinely spooky. Codex intermittently enters what developers call "conversational mode" — where you give it a task that clearly requires tool use (read this file, run this test, fix this error), and it responds with text like "Acknowledged. I'll run this exactly as specified..." and then does absolutely nothing. No tool calls. No file reads. No commands. Just vibes.

The bug is intermittent but clustered. Once Codex enters this mode, multiple consecutive runs fail the same way. The context between working and failing runs is nearly identical. GitHub issues show the working run processing 48 tool calls in 5 minutes, and the failing run completing in 3.5 seconds with zero tool calls.

It's like your senior engineer suddenly decided to respond to every Jira ticket with "Acknowledged" and then took a nap.

### The Silent Downgrade

Perhaps the most trust-eroding issue: Codex sometimes silently routes your requests to GPT-5.2 instead of 5.3. Your config says 5.3. Your UI says 5.3. But the actual model handling your request is 5.2. Developers only discovered this by inspecting SSE response headers.

OpenAI's official explanation is that "some requests that our systems detect as having elevated cyber risk may be automatically routed" to a lesser model. The intent is security. The effect is that you're paying for and expecting a 5.3-tier response and receiving 5.2 quality without any notification.

## The Shared Sins: What Both Models Get Wrong

Here's where it gets depressing. These behavioral issues aren't just model-specific quirks. Some of them are industry-wide patterns that neither lab has solved.

### Sycophancy: Your AI Agrees With You Too Much

Both models will tell you your approach is great even when it's garbage. OpenAI literally had to roll back a GPT-4o update because it was so sycophantic that it was "validating doubts, fueling anger, urging impulsive actions, or reinforcing negative emotions." Research shows AI models are 50% more sycophantic than humans, and users rated the flattering responses as higher quality — creating a feedback loop where models learn that agreeing gets better ratings.

In a coding context, this means: you propose an architecturally questionable approach, and instead of pushing back like a good senior engineer would, both Opus and Codex go "Great idea! Let me implement that for you." By the time you realize the approach was wrong, you've merged three PRs worth of debt built on a bad foundation.

### The "Almost Right" Trap

Stack Overflow survey data shows that 45% of developers cite "AI solutions that are almost right, but not quite" as their number-one frustration. The code looks syntactically perfect. It's architecturally plausible. But there's a subtle off-by-one error, a hallucinated library method, or a security flaw hiding in plain sight.

MIT Technology Review captured the feeling perfectly — developers describe it as pulling a lever on a slot machine. Sometimes you get a 20x improvement. Sometimes you spend two hours trying to coax the model into granting the wish you wanted, and it never does. And the jackpots are memorable, so you overestimate how often they happen.

### Hallucinated Dependencies

Both models will confidently import packages that don't exist. This isn't just annoying — it's a supply chain attack vector. Researchers have documented that attackers create packages with the hallucinated names, lace them with malicious code, and wait for the model (or developer) to `npm install` them blindly.

## The Workflow That Actually Works: Stop Picking Sides

After weeks of this, the answer isn't "Opus is better" or "Codex is better." The answer is that they're different tools for different phases of work.

**Opus builds. Codex refines.**

Opus is your first-draft engine. It gets the shape of the thing right faster than anything else. Features appear on screen in minutes. The UI looks polished. The happy path works. Then you look at the code and find inline styles scattered everywhere, type safety holes, and components that forgot edge cases.

So you open Codex. And Codex does what it does best — reads everything, understands existing patterns, and cleans things up systematically. It's the code reviewer that actually reads every file before commenting.

The industry is converging on this pattern. The future isn't model loyalty — it's model routing. Assigning the right model to the right task based on scope, risk, and iteration cost. The developers who ship consistently in 2026 don't pick a side. They pick a roster.

## What This Actually Means for You

If you're using AI coding agents in 2026 — and you are, or you will be — here's the uncomfortable truth: understanding model behavior is now a core engineering skill.

Not prompting. Not "AI literacy." Behavioral prediction. Knowing that Opus will scope-creep on small tasks. Knowing that Codex will freeze on ambiguous ones. Knowing that both will agree with your bad ideas. Knowing when to reset a session because context bloat is making the model dumber by the minute.

The era of vibe coding is dead. Agentic engineering demands you understand the agent. Not just what it can do, but what it will do when you're not looking.

Treat your AI coding agent like a brilliant but unpredictable junior engineer. Give it clear scope. Review its work. Don't trust green CI from a model that rewrites assertions to pass. And for the love of your production database — never give it `sudo` and walk away.

Your AI has a personality disorder. The question is whether you're going to manage it, or let it manage your codebase.

---

# We Killed Our Next.js Server at 3am — And Honestly, It Was the Best Decision We Ever Made

- **URL**: https://www.rafay99.com/blog/we-counted-use-client-directives-and-cried/
- **Published**: 2026-03-02
- **Author**: Abdul Rafay
- **Tags**: ThoughsProcess, WebDevelopment
- **Description**: 487 use client directives. 1,076 files deleted. We migrated TudoNum from Next.js 16 to React 19 + Vite and stopped pretending our SPA needed a full-stack framework

> _This is a five-part engineering story. Grab a coffee. Grab two if you've ever received an AWS bill that made you question your life choices and your framework choices simultaneously._

## Prologue: The Moment We Knew Something Had to Change

There were actually two moments.

The first was a regular sprint planning. The product manager drops a new feature request on the board. The senior engineer picks it up, opens the file, and types `"use client"` at the top — _for the 488th time_.

He stops. Stares at it. Then turns to the team and says, very calmly:

**"Why are we using Next.js again?"**

Nobody had a good answer.

The second moment was quieter. It was the monthly AWS bill review. Someone opened the EC2 cost breakdown, scrolled to the line item for the Next.js server instances, and said nothing for about five seconds.

Then: **"We're paying this much to run a Node.js server whose entire job is to serve HTML that's immediately hydrated into a client-side React app?"**

Still nobody had a good answer.

That combination — the code smell and the money smell — kicked off weeks of architectural debate, one very large migration, several white screens, at least one CORS meltdown, and ultimately a codebase that the whole team is genuinely happier working in.

This is that story. We're telling it because we searched the internet for exactly this kind of post when we were about to make the jump — and mostly found either "Next.js is amazing, trust the framework!" or theoretical migration guides that clearly hadn't migrated anything real, or paid for anything real, or deployed anything real on AWS without Vercel holding their hand.

This is the real one.

## A Quick Introduction (Who Is This For?)

**If you're new to web dev elopment:** Don't worry. We'll explain the jargon as we go. Think of this as a story about a team that realized they were using a Swiss Army knife to butter their toast — it works, but there's a better tool, and the Swiss Army knife charges by the hour.

**If you're an intermediate developer:** You've probably used Next.js. You've probably also typed `"use client"` and wondered why you even have Next.js at that point. This post is directly for you.

**If you're a senior engineer or DevOps person:** You already know the punchline. But stay for the cost section and the RAM story. They're gratifying in a way that only resonates once you've held the pager during an OOM kill.

# Part 1: Why We Broke Up With Next.js

## (It's Not You, It's Us — Actually, It Mostly Is You)

### What Is TudoNum?

TudoNum is a marketplace platform. Think of it as the connective tissue between people who need things done and people who do those things professionally — home repairs, cleaning services, tutoring, on-demand skilled labor. It also has food delivery, ride-hailing, and e-commerce verticals either in production or in development.

The app is not small. At migration time:

* **1,076 TypeScript files**
* **40+ feature directories** of React components
* **11 Redux slices** managing user session, auth, bookings, cart, wallet, vendor orders, and more
* **Multiple user roles**: customers, vendors, and admins — each with different views, permissions, and entirely different workflows
* **45 backend API service files** talking to a Django REST backend

We were running all of this on **Next.js 16 with the App Router**.

And we were deploying it ourselves. On AWS. Without Vercel.

### The Deployment Setup That Started to Hurt

Here's something the Next.js documentation doesn't put on the homepage: **Next.js, in production, runs a Node.js server.** Always. Even if your app is 90% client-side React. Even if your "server" does almost nothing except hold the process open and serve pre-rendered HTML. The Node.js runtime is running, consuming memory, and costing money 24 hours a day.

On Vercel — the company that builds and maintains Next.js — this is mostly invisible. Vercel handles the infrastructure. You push code, Vercel figures out the rest. The bill arrives, you pay it, the lights stay on.

We are not on Vercel. We never were. We're a team building a custom solution on AWS, deploying on our own infrastructure, managing our own EC2 instances, and making cost-aware engineering decisions. That means the Node.js server is our problem. Its RAM is our RAM. Its uptime is our bill.

And that bill had a conversation with us that we couldn't ignore.

### The RAM Problem Nobody Talks About

Let's talk about what a production Next.js deployment actually looks like on self-managed infrastructure.

Next.js needs a Node.js process to run. That Node.js process loads your entire application — all the compiled routes, the server component renderer, the middleware, the build output — into memory when it starts. A medium-sized Next.js app in production typically sits at **300–600MB of RAM** at idle. Under load, it climbs.

For context: the application we're talking about here is not medium-sized. It has 93 routes, 11 Redux slices, dozens of data-fetching patterns, multiple user roles, and complex layouts. Our Next.js instance was comfortably using **400–500MB of RAM just sitting there**, before a single request came in.

Now multiply that by the number of instances you need for availability. You run at least two — one primary, one for failover. Preferably more in an auto-scaling group. Now you're at 1–2GB of RAM reserved just to keep Next.js alive and ready.

**For newcomers:** RAM is the working memory your server uses. More RAM = more money. AWS charges for RAM by the hour. A process that uses 500MB at idle is a process that requires a larger, more expensive server.

**For everyone:** Here's the thing that finally broke us. After all that RAM usage, all that Node.js process overhead, all that infrastructure complexity — what was the server actually _doing_? It was:

1. Receiving an HTTP request for a URL
2. Rendering some HTML
3. Sending that HTML to the browser
4. The browser immediately downloading the JavaScript bundle
5. React hydrating the HTML, replacing the server rendering with client-side rendering
6. Every subsequent navigation being handled entirely client-side anyway

In other words: the server was running expensive Node.js infrastructure to produce an initial HTML document that was **immediately overwritten by the client-side React app**. For a marketplace with user-specific dashboards, dynamic data, and complex auth requirements — almost none of that initial HTML was even useful. Users were staring at loading states until the client-side data fetched anyway.

We were running a Node.js server to produce HTML that we immediately discarded. Paying for the privilege of doing that at scale.

### The AWS Cost Reality Check

We're going to be specific here because vague "it was expensive" stories help nobody.

Running a Next.js application on AWS without Vercel means you're paying for:

**EC2 instances** to run the Node.js processes. For the memory requirements above, you're looking at `t3.medium` instances at minimum ($33/month each), more likely `t3.large` ($67/month each) with buffer for traffic spikes. With two instances for availability, that's $66–$134/month just for the base compute — before your database, your Django backend, your S3 buckets, your CDN, your load balancer, or anything else.

**Elastic Load Balancer** to distribute traffic across your Next.js instances: \~\$18/month base.

**Operational overhead**: deployment pipelines, rolling updates that account for the long Next.js startup time, health checks, memory monitoring, instance restarts when memory climbs too high under load. All of this is engineering time, which is not free.

Now compare that to what we run now:

A React SPA built with Vite produces **pure static files** — HTML, CSS, JavaScript. No server process required. You put the files in an S3 bucket and point CloudFront at it.

**S3**: essentially free for static file storage at our scale. We're talking cents per month.

**CloudFront**: pay per request and per data transfer. For a typical month, this is **\$10–20/month** total — including global CDN distribution, HTTPS, and automatic compression.

**No EC2 instances to keep running.** No Node.js processes eating RAM. No rolling deployments with startup delays. No memory monitoring. No OOM kills at 3am.

The infrastructure bill dropped significantly. That money went back into product development.

**For newcomers:** S3 is Amazon's file storage service. CloudFront is Amazon's global content delivery network (CDN) — it copies your files to servers around the world so users everywhere get fast load times. Together, they serve a React SPA for almost nothing compared to running actual servers.

### The Deployment Experience Was Also Just... Not Great

Here's something we don't see discussed enough: deploying a self-hosted Next.js app on AWS is _annoying_ in ways that compound over time.

**Cold starts are slow.** The Next.js production server takes time to start — not the 10 seconds of the dev server, but still several seconds before it starts serving traffic. This matters for rolling deployments: you need to keep the old instance alive, start the new one, wait for it to be healthy, shift traffic, shut down the old one. The window where you're running double instances (and double the cost) is longer than it needs to be.

**Memory leaks are a real threat.** Node.js processes in long-running production environments can develop memory leaks over time — especially with complex server-side rendering, request handling, and caching. We'd had incidents where a Next.js instance would slowly climb from 450MB to 800MB over 48 hours and eventually need to be restarted. Monitoring this, alerting on it, automating the recovery — all of that is infrastructure work that adds no user-visible value.

**There's no "just deploy the files."** When you deploy a Next.js app, you're not just copying files. You're restarting a server process. That process has state. It needs to load your application into memory before it can serve traffic. A deployment is a production event, every time.

With a static React SPA: deploying is copying files to S3. It's instantaneous. The previous version serves traffic until CloudFront picks up the new files. Zero downtime, zero drama, zero 3am pager alerts.

### The Audit That Confirmed It

With the deployment problems and cost problems already on the table, we ran the code audit to answer: "But do we actually _need_ Next.js for the server-rendering capabilities?"

We searched the codebase for `"use client"`. We wanted to know how many files were opting out of the server component model.

The answer was **487 files**.

_Four hundred and eighty-seven._

Out of roughly 1,076 total TypeScript files. Almost every single component in the app was explicitly a client component. The App Router's server component infrastructure was delivering value to approximately... 10 async page wrapper files that fetched data server-side.

We were paying for:

* A Node.js server running 24/7
* 400–500MB of idle RAM minimum
* Complex rolling deployments on AWS
* The cognitive overhead of the server/client boundary
* All of the App Router mental model

In exchange for: server-side rendering on 10 pages that immediately showed loading states anyway because they depended on user-specific dynamic data.

We were paying full rent for a mansion but only living in the kitchen. And the kitchen had a gas leak.

### So What Was Next.js Actually Doing For Us?

We made a list. Be honest with yourself, we told each other. What does Next.js actually provide that we couldn't get elsewhere?

**1. Server Actions** — We had 45 files under `src/actions/`. Their entire job was making HTTP calls to our external Django backend using authentication cookies. Next.js was a middleman between the browser and our real API. An expensive, RAM-hungry middleman.

**2. `next/image`** — Automatic image optimization. Genuinely useful! Except our Django backend already serves optimized images at the correct sizes. We were paying for a feature solving a problem we didn't have.

**3. `next/navigation`** — The `useRouter()`, `usePathname()`, `useParams()` hooks. These are nice. But TanStack Router has all of these, they're _fully type-safe_ in ways Next.js still isn't, and it doesn't require a Node.js process.

**4. The build system and dev server** — Vite does everything Next.js does for a client-side app, faster, with a smaller footprint and more configuration control. Dev server starts in under a second. No Node.js runtime in production.

That was the full list. Four things. Three replaceable with better alternatives. One (Server Actions for auth) that we needed to redesign properly — and actually _should have_ redesigned properly regardless of the framework switch.

### The Real Reason Teams Don't Migrate

Let's be honest about something: the real reason teams stay on frameworks they've outgrown isn't always technical. Sometimes it's psychological. Sometimes it's the sunk cost fallacy wearing a technical justification costume.

**The "it works right now" trap.** The app is running in production. Users are using it. Why introduce risk? This is a rational fear. But there are two kinds of risk: the acute risk of migration, and the chronic risk of staying. The chronic one is sneaky — it shows up as a slightly higher AWS bill every month, a slightly harder deployment every sprint, a slightly longer `"use client"` discussion every code review. It doesn't hurt all at once. It just never stops hurting.

**The "we'll deal with it later" trap.** Yes. And "later" is now. It's always now, eventually.

**The "what if we need SSR someday" trap.** If you need SSR someday, you can add it someday. Architectural decisions should match current needs, not hypothetical future requirements. We did not need SSR. We needed a fast, cheap, maintainable client-side React application deployed on AWS with predictable costs and zero-drama deployments.

**The "Vercel makes it easy" trap — when you're not on Vercel.** This one is particularly important. A lot of Next.js best-practice content is written by people deploying on Vercel, for people deploying on Vercel. If you're on Vercel, Vercel handles the Node.js runtime, the scaling, the cold starts, the memory. You pay Vercel for that convenience. But if you've decided to go custom on AWS — as we did, for cost and control reasons — you inherit all of that complexity yourself. The "Next.js is easy to deploy" assumption breaks down completely the moment you're not on the platform it was designed for.

We weren't on that platform. We made the choice to own our infrastructure. And owning it meant being honest about what it actually cost to run.

We decided to migrate. Here's what we built instead.

# Part 2: The Stack We Built (And Why Every Piece Earns Its Place)

## React's Greatest Hits, No Filler, No Server

```
React 19  +  Vite 7  +  TanStack Router  +  TanStack Query  +  Redux Toolkit
```

### React 19 — The Star of the Show

We went straight to React 19. Not because it was shiny, but because we were starting fresh and there was no reason to anchor to an older version.

The React Compiler (`babel-plugin-react-compiler`) is already sitting in our devDependencies, waiting for when it hits stable. When it does, a significant chunk of our `useMemo` and `useCallback` calls become unnecessary — React will handle memoization automatically. That's free performance, waiting for us to unlock it.

**For newcomers:** React is the library that builds the UI. Think of it as the engine. Version 19 is the latest engine. We're using it because it's the best.

### Vite 7 — The Build Tool That Made Everyone Smile

Vite replaced Next.js's build pipeline. The improvement was immediate.

| ​                       | Next.js 16                 | Vite 7                 |
| ----------------------- | -------------------------- | ---------------------- |
| Dev server cold start   | \~10 seconds               | \~0.8 seconds          |
| Hot module replacement  | Noticeable lag             | Effectively instant    |
| Production build        | \~90 seconds               | \~45 seconds           |
| Production RAM usage    | 400–500MB (Node.js server) | **0MB** (static files) |
| Server process required | Yes, always                | No, never              |

That last row is the one that matters most. Vite builds files. Files sit on S3. CloudFront serves them. No server. No RAM. No bill for keeping a process alive.

We also wrote a custom chunk-splitting strategy to control the production bundle:

```typescript
manualChunks(id) {
  if (id.includes('/react/'))          return 'vendor-react'    // cached forever
  if (id.includes('@tanstack/'))       return 'vendor-router'   // cached until router update
  if (id.includes('@reduxjs/'))        return 'vendor-redux'    // separate cache key
  if (id.includes('framer-motion'))    return 'vendor-motion'   // big library, own chunk
  if (id.includes('@stripe/'))         return 'vendor-stripe'   // payment pages only
  if (id.includes('leaflet'))          return 'vendor-maps'     // map pages only
  // ... etc
}
```

**For newcomers:** This means when we update our app code, users don't re-download React. Their browser already has React cached. Only the parts that changed get downloaded fresh. Users on slow connections especially benefit from this.

### TanStack Router — Type-Safe Routing That Next.js Still Can't Match

In Next.js App Router, `useParams()` returns `{ [key: string]: string | string[] }`. Always. You always cast it, check it, or suppress the TypeScript warning. The router has no idea what parameters your route actually expects.

In TanStack Router with file-based routing, `useParams()` for a route at `/services/$id` returns exactly `{ id: string }`. TypeScript knows every route. TypeScript knows every parameter. If you navigate to a route without the required parameter, it tells you before you run the code.

```typescript
// TanStack Router — TypeScript catches mistakes at compile time ✅
View Service

// Next.js — TypeScript has no idea if this route exists ❌
View Service
```

Route guards are clean and co-located with the route:

```typescript

  beforeLoad: () => requireAuth(),
  component: OrdersPageClient,
})
```

No middleware file to track down. No regex matching. The intent is right there, next to the route it protects.

### The AWS Deployment That Actually Makes Sense Now

Here's what our deployment looks like post-migration:

**Build:** `bun run build` produces a `dist/` folder with HTML, CSS, and JavaScript files. These are static files. They have no runtime dependencies. They do not need a server.

**Deploy:** Copy `dist/` to an S3 bucket. Invalidate the CloudFront distribution cache. Done.

**The CloudFront distribution** sits in front of S3, handles HTTPS, compresses assets, and distributes them from edge locations globally. This is standard AWS static hosting.

**API routing:** Nginx (or an Application Load Balancer rule) proxies `/api/*` requests to the Django backend. The React app never makes cross-origin requests — to the browser, it's all the same origin.

The result:

* **Zero Node.js processes** running in production
* **Zero RAM** reserved for the frontend server
* **Zero rolling deployments** — new files are just files
* **Zero pager alerts** for frontend memory issues
* **Deployment time:** 60–90 seconds (build + S3 upload + CloudFront invalidation)
* **Rollback:** point CloudFront at the previous S3 deployment. Instant.

**For newcomers:** Think of it like the difference between a restaurant that cooks every meal when you order it (Next.js server) vs. a grocery store that puts pre-made meals on the shelf (static files on S3). The grocery store can serve more people, at lower cost, with no chef standing by. The restaurant model only makes sense if you need fresh, customized food — which our app didn't.

### The Platform vs. Modules Architecture

The most important architectural decision beyond the stack itself was formalizing the separation between what's shared and what's vertical-specific.

TudoNum is not one app. It's multiple business verticals on one platform:

* Professional Services (live)
* Food Delivery (in progress)
* Taxi / Ride-Hailing (in development)
* E-commerce (coming)

Each vertical has its own domain logic, its own API endpoints, its own UI flows. But they all share authentication, wallet, user profile, reviews, affiliate referrals, and geographic services.

```
src/services/
├── platform/         ← shared by every vertical
│   ├── auth/         ← login, logout, OTP, session
│   ├── wallet/       ← balance, transactions
│   ├── payments/     ← Stripe, Amwal
│   ├── profile/      ← user profile, password, timezone
│   ├── reviews/      ← ratings system
│   ├── affiliate/    ← referral codes
│   └── admin/        ← analytics dashboards
│
└── modules/          ← vertical-specific
    └── professional-services/
        ├── catalog/          ← browse, search, service profiles
        ├── booking/          ← availability, quotes
        ├── orders/           ← buyer & vendor order management
        ├── quotes/           ← quote request and approval
        ├── vendor-profile/   ← portfolio, packages, settings
        ├── vendor-onboarding/ ← provider registration
        └── feedback/         ← post-service reviews
```

The rule: if every vertical needs it, it goes in `platform/`. If only one vertical needs it, it goes in `modules/`. When food delivery is fully built, it sits alongside `professional-services/` as a sibling, plugging into all platform services without modifying them.

### The Auth Redesign — The Scary Part That Turned Out Fine

The auth redesign was the hardest part of the migration and the most important to get right.

**Before:** Server Actions read/write HttpOnly cookies via `cookies()` from `next/headers`. Auth lived entirely server-side. Removing Next.js meant removing auth.

**After:** In-memory access token + HttpOnly refresh cookie managed by the backend.

In plain English:

1. User logs in → backend returns `access_token` in the response body + sets `refresh_token` as an HttpOnly cookie via `Set-Cookie`
2. `access_token` goes into a JavaScript module-level variable — never `localStorage`, never a cookie we control
3. Every API request automatically gets `Authorization: Bearer <token>`
4. On 401: call the refresh endpoint; browser auto-sends the HttpOnly cookie; get new token; retry
5. On page reload: try refresh immediately; if cookie is valid, session is silently recovered; user never sees a login screen

**For newcomers:** It's a hotel key card system. The access token is your key card — it opens doors but expires quickly. The refresh cookie is the booking record the hotel keeps in their system. You can always get a new key card without checking in again.

The implementation handles a subtle concurrency problem: if three API calls all get 401 at the same time, only one refresh request goes to the backend. The other two wait and retry once the refresh completes. No thundering herd of simultaneous refresh calls.

# Part 3: The Migration — Phase by Phase, Wart by Wart

## Eight Phases. Real Work. No Hand-Waving.

Here's the full scale:

| What We Migrated                   | Count       |
| ---------------------------------- | ----------- |
| Total TypeScript files             | 1,076       |
| `"use client"` directives removed  | 487         |
| Server Actions → API services      | 45          |
| Pages → TanStack Router routes     | 93          |
| Layout files converted             | 11          |
| `next/navigation` imports replaced | \~100 files |
| `next/image` imports replaced      | \~104 files |
| `next/link` imports replaced       | \~27 files  |

### Phase 1: Build the Skeleton (Don't Touch the App Yet)

First rule of large migrations: **get the new infrastructure working before touching a single line of business logic.**

Created `vite.config.ts`, got a "Hello World" rendering, configured the dev proxy:

```typescript
server: {
  proxy: {
    '/api': {
      target: 'https://api.tudonum.co',
      changeOrigin: true,
    }
  }
}
```

The proxy is critical. In Next.js, API calls were server-to-server — no CORS enforcement. In the browser, direct calls to `api.tudonum.app` from `localhost:5173` are blocked. The Vite proxy routes `/api/*` through the dev server. In production, the same proxy configuration lives in Nginx, sitting in front of both the static files on S3 and the Django backend.

### Phase 2: Auth First

Before touching any component: write `tokenStore.ts`, rewrite `axiosInstance.ts`, write the route guards. Test login → API call → 401 → refresh → retry → logout end-to-end. Only then, move forward.

### Phase 3: 45 Server Actions, One Pattern

Strip `"use server"`, remove `cookies()`, replace `makeAuthenticatedRequest()` with `axiosInstance.get/post/put/delete()`, keep function signatures identical. With identical signatures, the query hooks that called these functions didn't change at all — only the import paths.

### Phase 4: 93 Pages, File-Based Routes

TanStack Router's file naming conventions:

* `(auth)` route group → `_auth`
* `[id]` dynamic segment → `$id`
* `layout.tsx` → `route.tsx` with ``

Each route file is 5–15 lines of routing config. The page component it imports is untouched.

### Phase 5: Batch Replace Everything `next/*`

Four compat shims. One find-replace per category. 250+ import statements updated in under an hour without touching component logic. The shims ensured component code didn't change — only where the import came from.

### Phase 6: Kill What Shouldn't Exist

Three Next.js API proxy routes eliminated. `middleware.ts` deleted. Route guards in `beforeLoad` replace it. `sharp` (server-side image processing) removed — replaced with `browser-image-compression`, already in the project. Geocoding proxy removed — Nominatim supports CORS directly.

### Phases 7 & 8: Cleanup and Celebrate

Deleted `next.config.ts`, `middleware.ts`, `next-env.d.ts`. Removed `next`, `eslint-config-next`, `sharp`, `@vercel/analytics` from `package.json`. Removed SSR guards from Redux store. Removed the server-side branch from QueryClient. Ran the build. Green.

Removing code is one of the best feelings in software. We removed a lot of it.

# Part 4: The Bugs — Our Hall of Shame

## Everyone Has These. We're Just Honest About Them.

### Bug #1: The Circular Import That Made TypeScript Lie (It Wasn't Lying)

We had `src/services/auth.ts` (a file) and we created `src/services/auth/` (a directory with the same name). The module resolver didn't know which to use and created a silent circular dependency.

**Symptom:** `SendSignupOtpResult is not exported from module` — even though it clearly was.

**Fix:** Delete `auth.ts`. Move its contents to `auth/session.ts`. No ambiguity, no circular import, no lies.

**Lesson:** When creating a directory with the same stem as an existing file, delete the file first.

### Bug #2: The Generic That Was Too Clever

Our `dynamic()` compat shim had a generic with `extends Record<string, unknown>`. TypeScript got strict about it in a way that was technically correct but practically useless. Components with specific prop types couldn't be passed to `dynamic()`.

**Fix:** Changed to `P = any`. The generic threads the type through. The constraint was removed. Problem solved.

### Bug #3: The White Screen That Questioned Everything

_This is the important one._

App loads. White screen. No UI. No error. No console messages.

We added an `ErrorBoundary` to `__root.tsx`. Refreshed.

Red text appeared:

```
Uncaught ReferenceError: process is not defined
    at logger.ts:48
```

**What happened:** In Next.js (webpack), `process.env.NODE_ENV` is replaced at build time with a literal string. By the time the code runs, `process` is gone — it never reaches the browser.

In Vite, `process` simply does not exist in the browser. Vite only replaces `import.meta.env.*`. Our `logger.ts` ran at module initialization time using `process.env`. The error killed the entire React tree before a single component mounted.

```typescript
// Before — works in webpack/Next.js, explodes in Vite
const isDevelopment = process.env.NODE_ENV === 'development'

// After — works in Vite and every browser
const isDevelopment = import.meta.env.DEV
```

This pattern was hiding in 5 files: `logger.ts`, `dev-config.ts`, `featureFlags.ts`, a signup page component, and `StripePaymentForm.tsx`.

**Lesson:** Search your entire codebase for `process.env` before running the Vite dev server for the first time. Every occurrence needs attention. Also, add an `ErrorBoundary` to your root component. A silent white screen is a debugging nightmare. An error boundary turns it into a stack trace.

### Bug #4: The CORS Error That Seemed Catastrophic but Wasn't

Login attempt. Network error. CORS policy violation. The word "CORS" in big red letters in the browser console.

Initial instinct: "The backend team needs to reconfigure CORS. This is going to take days."

Actual cause: `VITE_API_BASE_URL` was set to the full absolute URL, bypassing the Vite proxy entirely. The browser made a direct cross-origin request. CORS enforcement kicked in correctly.

**Fix:** Change the env var to a relative path:

```
VITE_API_BASE_URL=/api/v1
```

Now the browser calls `localhost:5173/api/v1/...`, Vite proxies it, the backend sees a server-to-server request. No CORS. No backend ticket needed.

**Time from panic to fix:** 25 minutes. 20 of those were disbelief.

### Bug #5–7: Quick Hits

**`redirect()` takes an object, not a string.** TanStack Router's `redirect()` is for throwing in `beforeLoad`, not calling in components. For component-level redirects: use ``.

**`vite.config.ts` not in the TypeScript project.** `tsconfig.json` included `src/**/*` but not the config file at the project root. Added it to `include`. Red squiggles went away.

**`useParams` type mismatch in compat shim.** Used `{ strict: false } as any` inside the shim to satisfy TanStack Router's type requirements while preserving the generic return type for components. The `as any` is contained to one line inside one shim file.

# Part 5: What's Next — The Ongoing Work and Honest Lessons

## The Code Quality System

After the migration stabilized, we tightened code quality.

**Prettier** — consistent formatting across 1,076 files, `.prettierignore` excludes the auto-generated `routeTree.gen.ts`, `bun run format` keeps everything in sync.

**ESLint 9 flat config** — `argsIgnorePattern: "^_"` for underscore-prefixed unused parameters (common in event handlers), `eslint-config-prettier` to prevent formatting conflicts, zero-warnings enforced in CI.

**GitHub Actions CI:** type-check → lint (`--max-warnings 0`) → build. Every PR. No exceptions.

**Husky pre-commit hook:** warns on `console.log` before it reaches CI.

## What's Still on the Roadmap

**Remove the compat shims gradually.** The `src/lib/compat/` shims for `next/navigation`, `next/link`, `next/image`, `next/dynamic` were migration tools, not permanent architecture. Replacing each one with direct TanStack Router equivalents is a healthy ongoing refactor, one component at a time.

**Enable the React Compiler.** It's already in devDependencies. When it hits stable, we enable it and remove most manual `useMemo`/`useCallback` calls.

**Virtualize heavy lists.** Several pages render large lists — service catalogs, order history, vendor portfolios. `react-window` is already installed. Applying it to the heaviest pages cuts DOM node count significantly.

**Eliminate barrel exports in query hooks.** A few `index.ts` re-

## The Lessons. The Real Ones.

**"Run the cost math before the technical audit."**

We got lucky that both the code smell and the cost smell appeared at the same time. But the cost math is actually faster to run. Open your AWS bill, find the EC2 line item for your Next.js servers, multiply by 12. Ask whether you're getting that much value from server-side rendering. If the answer is "we're mostly `'use client'` anyway" — you have your answer before writing a single line of migration code.

**"If you're on AWS managing your own infrastructure, Next.js is not a free choice."**

Vercel makes Next.js feel free because they absorb the operational cost in your subscription fee. When you're self-hosting, you absorb it in EC2 bills, on-call rotations, and deployment complexity. That's a legitimate tradeoff if SSR is delivering real value. It's not a legitimate tradeoff if 90% of your components are already `"use client"`.

**"Static files on S3 + CloudFront are radically simpler to operate than a Node.js server."**

Deployments become file copies. Rollbacks become pointing at old files. RAM monitoring disappears. OOM kill alerts disappear. Middle-of-the-night "the Next.js process is eating 800MB and needs to be restarted" pages disappear. The operational simplicity alone is worth the migration, independent of any performance or cost argument.

**"Design auth first. Touch nothing else until auth works."**

Auth touches every page. If auth is broken, you cannot verify anything. We spent the first phase entirely on auth infrastructure and test it exhaustively before moving on. Every subsequent phase was faster because we could trust the foundation.

**"Add an `ErrorBoundary` to your root component. Today."**

Before the migration, before anything. A white screen with no error message is not debugging — it's staring at a wall. An error boundary turns every failure into a readable stack trace. This should be standard practice, not a migration hack.

**"Search for `process.env` before running Vite for the first time."**

Twenty minutes of find-replace saves two hours of white-screen debugging and career questioning.

**"Use a relative URL for the API. Configure the proxy on day one."**

`VITE_API_BASE_URL=/api/v1`. That's it. Requests go through the proxy. No CORS. No backend tickets. No panic.

**"The migration pays off faster than you expect."**

Within one sprint: dev server under a second. HMR instant. Deployments boring (that's a compliment). AWS bill smaller. New developers onboarding faster because the architecture matches what the app actually is.

The compounding cost of the wrong tool is real. So is the compounding benefit of the right one.

## The Final Numbers

| ​                            | Before (Next.js on EC2)                | After (Vite + React on S3 + CloudFront) |
| ---------------------------- | -------------------------------------- | --------------------------------------- |
| Dev server cold start        | \~10 seconds                           | \~0.8 seconds                           |
| Production build time        | \~90 seconds                           | \~45 seconds                            |
| Production RAM (frontend)    | 400–500MB (Node.js)                    | 0MB — no server process                 |
| Deployment type              | Rolling server restart                 | File copy to S3                         |
| Deployment drama             | Medium (startup delays, health checks) | None                                    |
| Rollback                     | Redeploy previous build                | Point CloudFront at old files           |
| Infrastructure cost          | EC2 + ELB + monitoring                 | S3 + CloudFront only                    |
| Route type safety            | None                                   | Full TypeScript inference               |
| `"use client"` in codebase   | 487                                    | 0                                       |
| `next/*` imports in codebase | \~250                                  | 0                                       |

## So, Should You Do This?

Here's the honest answer: **it depends on whether you're on Vercel.**

If you're on Vercel — Next.js is an excellent product. They've built the ideal infrastructure for it. The operational complexity we described doesn't affect you. Server components and the App Router are genuinely powerful for the right use case. Stay.

If you're self-hosting on AWS (or GCP, or DigitalOcean, or anywhere) and you've decided to build a custom infrastructure solution — be honest with yourself about what you're actually getting from the framework. Count your `"use client"` directives. Look at the RAM your Node.js process consumes. Look at your deployment pipeline. Ask whether that complexity is paying rent.

If your app is:

* Mostly client-side React already
* Backed by an external API that's not a Next.js advantage
* Deployed on infrastructure you manage yourself
* Not receiving meaningful SEO benefit from SSR (marketplace dashboards, authenticated pages, user-specific data)

...then you might be wearing the same costume we were.

The migration was not small. 1,076 files, 8 phases, 4 major bugs, and real engineering hours. But the result is an app that costs less to run, deploys without drama, starts in under a second in development, and is architecturally honest about what it actually is.

Sometimes the right move is knowing when the tool you're using is solving a problem you don't have — and billing you for the privilege.

_TudoNum is building the infrastructure for on-demand professional services, food delivery, and transportation across multiple markets. The frontend runs on React 19, Vite 7, TanStack Router, TanStack Query, and Redux Toolkit. The backend is Django REST. The whole thing runs on AWS infrastructure we manage ourselves, which is exactly why this migration happened._

_If you're on the same journey — self-hosted, AWS, building a custom solution and watching the bill — we hope this helped. The grass is actually greener on the static files side._

---

# Cloudflare Just Rebuilt Next.js in a Week — And the Internet Lost Its Mind

- **URL**: https://www.rafay99.com/blog/cloudflare-rebuilt-nextjs-in-a-week/
- **Published**: 2026-03-01
- **Author**: Abdul Rafay
- **Tags**: AI, Development, Next.js, Cloudflare, Vite, Thoughts
- **Description**: One engineer, $1,100 in AI tokens, and seven days. Cloudflare's vinext is a full reimplementation of the Next.js API built on Vite — and it's already running a government website in production. Here's why this matters way more than the hype suggests.

I was doing my usual thing — scrolling through tech Twitter, half-reading blog posts, avoiding my actual work — when I saw a headline that made me stop mid-scroll.

_"How we rebuilt Next.js with AI in one week."_

That's from Cloudflare. Not some random indie dev. Not a weekend hackathon project. Cloudflare — the company that sits in front of like half the internet.

One engineering manager. Claude as the AI model. 800+ coding sessions. \$1,100 in API tokens. Seven days. And the result? A drop-in replacement for Next.js called **vinext** (pronounced "vee-next") that builds up to 4.4x faster and produces bundles 57% smaller than the real thing. Already running in production on a government website.

I read the whole blog post. Then I read it again. Then I went down the rabbit hole — GitHub issues, Hacker News threads, security disclosures, hot takes, cold takes. And I have thoughts. A lot of them.

## What Even Is vinext?

Let me break this down before we get into the spicy stuff.

If you've ever tried deploying a Next.js app anywhere that isn't Vercel, you know the pain. Next.js is incredible for developer experience — routing, server rendering, React Server Components, the whole package. But the moment you try to run it on Cloudflare Workers, Netlify, or AWS Lambda, you enter adapter hell.

The existing solution was called **OpenNext** — a project that reverse-engineers Next.js's build output and reshapes it so other platforms can run it. Multiple companies, including Cloudflare, have poured engineering effort into OpenNext. It works... but it's fragile. Every time Vercel pushes a new Next.js version, the internals can change, and OpenNext breaks. It's a constant game of whack-a-mole.

vinext takes a fundamentally different approach. Instead of wrapping Next.js output, it **reimplements the entire Next.js API surface on top of Vite**. Same `app/` directory. Same `pages/` directory. Same `next.config.js`. You literally swap `next` with `vinext` in your `package.json` scripts, and everything else stays the same.

```bash
npm install vinext

vinext dev          # Development server with HMR
vinext build        # Production build
vinext deploy       # Build and deploy to Cloudflare Workers
```

That's it. No reshaping build output. No reverse-engineering internals. A clean reimplementation of the public API.

## The Numbers That Made Me Do a Double Take

Cloudflare published benchmarks against Next.js 16 using a 33-route App Router application. They disabled TypeScript checking and ESLint in Next.js's build to keep the comparison fair — just measuring raw bundler and compilation speed.

**Build times:**

* Next.js 16 with Turbopack: 7.38 seconds
* vinext with Vite 7 (Rollup): 4.64 seconds — 1.6x faster
* vinext with Vite 8 (Rolldown): 1.67 seconds — **4.4x faster**

**Client bundle size (gzipped):**

* Next.js 16: 168.9 KB
* vinext with Rolldown: 72.9 KB — **57% smaller**

Now, look — benchmarks are benchmarks. This is one test app, early days, take it with a grain of salt. Cloudflare themselves say these are "directional, not definitive." But a 57% reduction in bundle size? That directly impacts your Core Web Vitals. Smaller bundles mean faster First Contentful Paint, lower Largest Contentful Paint, better SEO. For a content-heavy site, that's not a nice-to-have — that's the difference between ranking and not ranking.

## The Part Everyone Is Talking About — AI Built This

Here's where it gets really interesting. And honestly, a bit unsettling.

Almost every line of code in vinext was written by AI. One person — Steve Faulkner, who is technically an engineering manager, not even a full-time developer on this — directed Claude through 800+ sessions in OpenCode. The total cost was about \$1,100 in API tokens.

The workflow was surprisingly straightforward:

1. Spend a couple of hours defining the architecture with Claude
2. Define a task ("implement the `next/navigation` shim")
3. Let the AI write the implementation and tests
4. Run the test suite
5. If tests pass, merge. If not, feed the error back to the AI
6. Repeat

They even had AI agents doing code reviews. When a PR was opened, an agent reviewed it. When review comments came back, another agent addressed them. The feedback loop was mostly automated.

But here's the thing Faulkner was honest about — it didn't work perfectly every time. The AI would confidently implement something that seemed right but didn't match actual Next.js behavior. Architecture decisions, prioritization, knowing when the AI was heading down a dead end — that was all human. The AI was the engine, but the human was steering.

## Why This Specific Problem Was Perfect for AI

I've written before about AI coding tools and their quirks — the eager overreach, the confident wrongness, the tendency to rewrite things that don't need rewriting. So why did it work so well here?

Faulkner identified four things that all had to be true at the same time:

**Next.js is extremely well-documented.** Years of Stack Overflow answers, tutorials, official docs. The API surface is all over the training data. When you ask Claude how `getServerSideProps` works, it doesn't hallucinate. It knows.

**Next.js has a massive public test suite.** Thousands of E2E tests covering every feature and edge case. These tests functioned as a machine-readable specification. The AI didn't need to understand intent — it implemented against a contract. Cloudflare ported tests directly from the Next.js repo and used them as verification.

**Vite is an excellent foundation.** Vite handles the hard parts — fast HMR, native ESM, a clean plugin API, production bundling. They didn't have to build a bundler. They just had to teach Vite to speak Next.js.

**The models got good enough.** Faulkner said he doesn't think this would have been possible even a few months ago. Earlier models couldn't sustain coherence across a codebase this size. Current models can hold the full architecture in context, reason about module interactions, and produce correct code often enough to maintain momentum.

Take any one of those away — unclear documentation, no test suite, a worse build tool, or a weaker model — and this project doesn't happen. That's an important nuance that a lot of the hot takes are missing.

## Then Vercel Showed Up — And Things Got Spicy

The vinext blog post dropped on February 24th. Within days, Guillermo Rauch — the CEO of Vercel, the company that created and maintains Next.js — announced that his team had found seven security vulnerabilities in vinext. Two critical, two high, two medium, one low.

He called it a "vibe-coded framework."

That term — _vibe-coded_ — is doing a lot of heavy lifting here. It's basically calling vinext an AI toy project that shouldn't be trusted with real production traffic. And honestly? The security findings are real. They're not FUD.

A security research firm called Hacktron also ran automated scans against vinext and found some nasty stuff. The worst one? vinext's fetch caching built cache keys from the URL, HTTP method, and request body — but **not from request headers**. So a request with `Authorization: Bearer alice` and one with `Authorization: Bearer bob` to the same URL would produce the same cache key. The first user's response gets served to everyone.

In Next.js, there's an undocumented heuristic — if a request contains `Authorization` or `Cookie` headers, it automatically opts out of shared caching. That behavior evolved from years of production incidents. It's not in any API docs. It's an invisible invariant. When you reimplement from the spec, that rule doesn't exist.

Another bug: vinext silently excludes `/api` routes from middleware by default. In Next.js, if you don't define a matcher, middleware runs on all routes, including API routes. That's how global auth works. Migrating from Next.js to vinext? Your API endpoints are suddenly wide open.

This is the catch with AI-generated code at this scale. The tests encode known scenarios. Production reveals unknown ones. As one Hacker News commenter put it — "passing all the tests means you duplicated something. That's a naive understanding of the reality of tests."

## The Bigger Picture — Test Suites as Blueprints

But here's what I can't stop thinking about — and this is bigger than vinext or Cloudflare or Vercel.

A brilliant analysis on paddo.dev framed it perfectly: if your competitive advantage depends on implementation complexity, and your test suite is public, you've published the blueprint for your own replacement.

Vercel's implicit defense against alternatives was that Next.js's internals are complex and change unpredictably. OpenNext had to reverse-engineer build output every release. That moat worked against human engineers. It doesn't work against an AI that can reimplement the public API from scratch in a week.

Think about that for a second. Next.js has 2,000+ unit tests and 400+ E2E tests. Those tests describe, in machine-executable detail, what the framework should do in thousands of scenarios. Route resolution, middleware chaining, RSC streaming, cache invalidation — all encoded as assertions. They're not just tests. They're a spec.

People on Hacker News predicted that frameworks will start treating their test suites as proprietary. SQLite already does this — the database itself is public domain, but the test suite is closed source. Whether Next.js follows that path depends on how seriously Vercel takes vinext as a threat.

And here's the kicker — if Cloudflare's vinext gets popular, its test suite becomes a spec too. Any platform could reimplement vinext's API surface using the same method. The pattern commoditizes whatever it touches.

## Traffic-Aware Pre-Rendering — The Actually Innovative Part

Everyone is talking about the AI story and the Vercel drama, but I think the most interesting technical innovation is getting buried under the noise.

vinext introduced something called **Traffic-Aware Pre-Rendering (TPR)**.

Here's the problem with Next.js pre-rendering: if you have 10,000 product pages, Next.js renders all 10,000 at build time, even though 99% of them might never get a request. Your build time scales linearly with page count. That's why large Next.js sites end up with 30-minute builds.

TPR flips this. Cloudflare is already the reverse proxy for your site. They have your traffic data. They know which pages actually get visited. So instead of pre-rendering everything, vinext queries Cloudflare's zone analytics at deploy time and pre-renders only the pages that matter.

For a site with 100,000 product pages, the power law means 90% of traffic usually goes to 50–200 pages. Those get pre-rendered in seconds. Everything else falls back to on-demand SSR and gets cached via ISR after the first request. Pages that go viral get picked up automatically on the next deploy.

No `generateStaticParams()`. No coupling your build to your production database. Just... let the traffic data tell you what matters.

That's genuinely clever. And it's the kind of thing that could only come from a CDN provider that already sits in the request path.

## What This Means for Us Developers

Okay, so — developer-to-developer — what do we actually do with all this information?

**If you're deploying Next.js on Cloudflare Workers today:** Don't switch to vinext in production yet. It's a week old. Security vulnerabilities have already been found and patched. The team at NxCode recommends sticking with OpenNext for production workloads but starting to experiment with vinext. I agree.

**If you're evaluating frameworks for a new project:** This is worth watching. The 94% API compatibility and automated migration tools mean trying vinext is low-risk. The performance gains are real if they hold up at scale. But "experimental" means experimental.

**If you're thinking about the bigger picture:** The era of framework moats built on implementation complexity is ending. When reimplementation becomes cheap, the competitive advantage shifts from "we built it first" to "we maintain it best" and "our ecosystem is stickiest." If you're building a product on top of a single vendor's framework, think hard about your exit strategy.

## The Wrapper Story Continues

I wrote a post a while back about how everything in software is a wrapper. Vinext is a fascinating new chapter in that story — because it's essentially saying that the wrapper itself can be reimplemented. The abstraction layer isn't sacred. If the API surface is well-documented and the test suite is comprehensive, the implementation underneath is just... replaceable.

Faulkner put it in a way that genuinely made me pause:

> "Most abstractions in software exist because humans need help. We couldn't hold the whole system in our heads, so we built layers to manage the complexity for us. AI doesn't have the same limitation. It can hold the whole system in context and just write the code."

That's a profound statement about where software is heading. Which of our beloved abstractions are truly foundational, and which were just crutches for human cognition? That line is about to shift massively.

## My Honest Take

Here's where I land on all of this.

**vinext as a product?** Too early to judge. It might thrive, it might die in three months if Cloudflare loses interest. There's already a GitHub issue literally titled "How serious is this project?" — which, fair question.

**vinext as a proof of concept?** Absolutely extraordinary. A single person used AI to reimplement the most popular frontend framework in under a week, for the cost of a nice dinner. Even with the security issues, even with the missing features, even with the caveats — the pattern is what matters.

**The Vercel drama?** Both sides have points. The security findings are legitimate and important. But calling it "vibe-coded" to dismiss the entire approach is a defensive move from a company that just watched its competitive moat get breached in seven days. First human-written code is just as fragile as first AI-written code. The difference is the speed at which it was produced.

**And the implications for AI-assisted development?** This is the data point I've been waiting for. Not a todo app. Not a demo. A production-grade framework reimplementation with 1,700+ tests, running on a government website. Flawed, yes. Incomplete, yes. But real.

We're living through a moment where the cost of building software is collapsing in real time. Whether that excites you or terrifies you probably depends on where you sit in the stack.

Me? I'm excited. And a little terrified. Which, honestly, is exactly how engineering should feel.

## References & Further Reading

* [Cloudflare Blog: How we rebuilt Next.js with AI in one week](https://blog.cloudflare.com/how-we-rebuilt-next-js-with-ai-in-one-week)
* [vinext GitHub Repository](https://github.com/nicolo-ribaudo/vinext)
* [vinext Official Site](https://vinext.dev)
* [Hacktron: Vibe-Hacking Cloudflare's Vibe-Coded Next.js Replacement](https://hacktron.io/blog/vibe-hacking-vinext)
* [paddo.dev: Vinext and the \$1,100 Rewrite](https://paddo.dev/vinext-and-the-1100-rewrite)
* [The Register: Cloudflare vibe codes 94% of Next.js API](https://theregister.com/2026/02/28/cloudflare-vinext)
* [OfficeChai: Vercel Discloses 7 Bugs in vinext](https://officechai.com/vercel-vinext-bugs)
* [NxCode: Complete Guide to vinext](https://nxcode.dev/guide-to-vinext)
* [DEV Community: Inside Cloudflare Vinext](https://dev.to/inside-cloudflare-vinext)
* [GitHub Issue #21: How serious is this project?](https://github.com/nicolo-ribaudo/vinext/issues/21)

---

# Claude Opus 4.6 vs. Codex 5.3: The Benchmarks Lie, But Your 8.9GB Memory Leak Doesn't

- **URL**: https://www.rafay99.com/blog/claude-opus-46-vs-codex-53-real-world-battle/
- **Published**: 2026-02-12
- **Author**: Abdul Rafay
- **Tags**: AI, ThoughtsProcess
- **Description**: I tested Claude Opus 4.6 vs Codex 5.3 for 6 days on a real production app. One leaked 9GB of RAM and rewrote my auth layer unasked. The other won't fix CSS without a screenshot. Here's why the benchmarks lie about agentic coding.

**They can pass the bar exam, solve quantum physics problems, and write recursive algorithms in Brainfuck. But can they migrate your ESLint config to Biome without nuking your `node_modules` and your sanity?**

That’s the question nobody’s answering.

For the last six days, I’ve been running a cage match between Anthropic’s Claude Opus 4.6 and OpenAI’s Codex 5.3 on a real production codebase—_Luma_, my freelance project. Not toy problems. Not LeetCode hards. Real, messy, "why-is-there-a-console-log-from-2022-in-here" code. I’ve merged pull requests, broken staging, watched RAM usage spike to 9GB, and learned that **agentic coding isn’t about intelligence—it’s about behavioral predictability.**

Here’s what the benchmarks won’t tell you.

![Hero image: Split screen showing Claude Code terminal interface vs Codex native macOS app](https://utfs.io/f/TViMykBJnLIJO27VGi8kbVhcyQEigAvaB3fqpPwWD0CRnm81)

### Details

| Dimension        | Claude Opus 4.6                                | Codex 5.3                             |
| ---------------- | ---------------------------------------------- | ------------------------------------- |
| Interface        | Terminal (TUI) Claude Code                     | Native macOS App GUI                  |
| Memory Footprint | 8-9GB Leaks Terminal bloat                     | Stable Process isolated               |
| File Strategy    | Carpet Bombing Touches everything              | Surgical Strikes Targeted grep        |
| Planning         | Unpredictable Sometimes plans, sometimes YOLOs | Methodical Always plans first         |
| Speed            | Fast & Chaotic One-shot architect              | Slow & Precise Refactoring specialist |
| Best For         | Greenfield Features New architectures          | Maintenance & Debt Legacy refactoring |
| UI Awareness     | Blind Needs screenshots                        | Blind Needs detailed prompts          |
| Prompt Friction  | Low Accepts vague requests                     | High Needs explicit specs             |

## The Benchmark Trap

We’ve seen the charts. Opus 4.6 crushes SWE-bench. Codex 5.3 dominates multi-file refactoring tasks. Great. But those are sanitized environments with clear success criteria. In the real world, success isn’t just "did it compile?" It’s:

* Did it remember to update the TypeScript interfaces in `types/auth.ts` when it changed the API route?
* Did it notice that the new component broke the mobile layout that wasn’t in the prompt?
* Did it spawn 47 parallel processes and turn your MacBook Pro into a space heater?

Spoiler: One of them did all three.

## Meet the Contenders: 6 Days in the Trenches

### Claude Opus 4.6: The Unpredictable Architect (Terminal-Based)

Opus 4.6 is fascinating—and frustrating. When you kick off a task in **Claude Code** (their terminal-based TUI), it creates an `INIT` file, generates a `claude.md` plan, and then... _decides_ whether your task deserves a plan or not. The logic is inscrutable:

* **Small prompt, big feature?** It YOLOs the changes across 12 files simultaneously.
* **Big prompt, small feature?** It writes a 500-word architectural dissertation before changing one line.

![Diagram showing Opus 4.6 chaotic file access patterns in terminal](https://utfs.io/f/TViMykBJnLIJV1sVjlhLpNfDlGtag3IM2qo1QCHSWJuVyn47)

**The Good:** When it locks in, it’s terrifyingly fast. It "one-shotted" a complex admin panel for Luma, generating the routes, database schemas, and UI components in a single pass. Raw power is undeniable.

**The Bad:** It suffers from **rampant parallelism**. Opus sees your codebase like a buffet—it wants to touch everything at once. It modified my authentication middleware while "fixing" a CSS bug, introduced a race condition in the Convex hooks, and forgot to update the corresponding Zod schemas.

The model is architecturally ambitious but consistency-blind. It’ll rebuild your API layer while ignoring that you’re still importing the old types in three unrelated dashboard components.

**The Ugly:** Claude Code has a memory leak that would make a Chrome tab blush. I watched my terminal balloon from 200MB to **8.9GB** during a long session. For a tool meant to run alongside Docker, VS Code, and Spotify, that’s a non-starter.

### OpenAI Codex 5.3: The Surgical Technician (Native macOS App)

Codex 5.3 behaves differently—and **crucially, it lives in a native macOS app, not your terminal**. It’s slower, methodical, and almost _suspicious_ of your codebase. Where Opus carpet-bombs, Codex snipes.

**The Interface Advantage:** Unlike Claude Code’s terminal-based TUI, the **Codex App** is a proper native macOS application. This changes everything:

* **Worktrees are visual.** You can see your experimental branches, spin up side-channels for dangerous refactors, and nuke them if they fail—all without touching your main working directory. I didn’t understand worktrees before this. Now I cannot live without them.
* **Battery life.** It’s not battery-hungry like I feared. It runs cloud-based agents without turning your laptop into a jet engine.
* **Process isolation.** Because it’s not running inside your terminal emulator, it doesn’t hijack your shell history or spike your terminal’s memory usage.

**The Behavioral Shift:** The upgrade from 5.2 to 5.3 introduced **contextual file targeting**. I could ask it to "find all files using the deprecated `useAuth` hook and migrate them to the new `useSession` hook," and it would:

1. Grep the codebase intelligently
2. Identify only the relevant files
3. Edit them without touching adjacent logic

This is huge. I migrated from ESLint to Biome.js (faster linting, native type-checking), removed dead dependencies, and upgraded Next.js across the entire Luma project without a single `any` type creeping in.

![Screenshot of Codex macOS app showing worktree sidebar and targeted file edits](https://utfs.io/f/TViMykBJnLIJOj6kwr8kbVhcyQEigAvaB3fqpPwWD0CRnm81)

**The Good:** It respects boundaries. The native app experience means you can CMD+Tab between VS Code and Codex without losing context. It feels like a peer to your IDE, not a parasite inside your terminal.

**The Bad:** Codex is **UI-blind**. It struggles with visual consistency. I had to take screenshots of broken layouts, paste them into the chat, and write detailed prompts like "the padding-left on the mobile menu is 4px too wide compared to the design system" to get fixes. It’s not great at "small things"—micro-interactions, responsive edge cases, or pixel-perfect alignment.

**The Ugly:** It’s prompt-greedy. You can’t vague-post your way to good code. "Fix the login page" gets you nowhere. You need to specify: "Update the `LoginForm` component to use the new `auth` service, ensure error handling matches the pattern in `RegisterForm`, and update the unit tests in `__tests__/auth/`." It’s powerful but high-friction.

## The Interface Factor: GUI vs. Terminal

Here’s the dirty secret: **The model is only 40% of the experience. The other 60% is the container.**

I tried Codex 5.3 inside Cursor a few months ago. Hated it. But running it in the **native Codex App** is a revelation. It’s lightweight, respects your git state, and the worktree integration makes experimental coding feel _safe_.

Claude Code? It’s terminal-based (TUI), which feels fast and hacker-y, but until Anthropic fixes the memory hemorrhaging, I can’t recommend it for long sessions. I experimented with **Conductor** (a third-party Claude client), but it’s not there yet.

**The paradigm difference:**

* **Claude Code:** Lives in your terminal. Fast input, immediate feedback, but eats RAM for breakfast and lacks visual hierarchy.
* **Codex App:** Lives in your Dock. Better for long-running tasks, visual file management, and keeping your terminal free for actual Docker/Node processes.

**Bottom line:** Codex 5.3 in its native macOS app is currently the smoothest agentic experience for sustained work. Opus 4.6 is trapped in a leaky terminal app that sabotages its brilliance.

![Comparison table: Terminal vs Native App features](https://utfs.io/f/TViMykBJnLIJsfW1Q6VuaXy980xWDv1YnVfghNKtcoeEkFsd)

## The Real Crisis: Code Review in the Age of One-Shotting

Both models are getting so fast, so capable, that **coding is no longer the bottleneck. Verification is.**

When Opus 4.6 or Codex 5.3 "one-shots" a feature, there’s a temptation to just... merge it. Don’t. I’ve caught both models:

* Introducing subtle auth bypasses by forgetting to check `isAdmin` in new API routes
* Duplicating logic that already existed in utility functions they didn’t read
* Using `console.log` instead of the structured logging utility (because the prompt didn’t explicitly say "use the logger")

**The New Skill:** You’re not a coder anymore; you’re a code reviewer with a compiler. If you don’t have processes—automated tests, strict TypeScript configs, and a human eye for architectural consistency—these models will write you into technical debt faster than you can say "refactor."

## The Verdict: Pick Your Interface

**Choose Claude Opus 4.6 if:** You need explosive architectural changes, you’re building greenfield features, you love living in the terminal, and you have the RAM to spare (and the patience to clean up after its tornado of changes). It’s the better _thinker_ but the worse _citizen_.

**Choose OpenAI Codex 5.3 if:** You’re maintaining legacy code, need surgical precision, prefer a native macOS GUI over terminal hacking, and value a UI that doesn’t crash your machine. It’s the better _worker_ but requires more hand-holding for creative tasks.

**The Honest Truth:** Neither is ready to fully autopilot your production codebase. Opus 4.6 will architect you into a beautiful mess. Codex 5.3 will maintain your mess beautifully but won’t notice the house is on fire unless you point at the smoke.

The gap between 5.2→5.3 and 4.5→4.6 is incremental in intelligence but massive in **behavioral reliability**. We’re not waiting for smarter models; we’re waiting for models that understand _when_ not to touch a file.

**My current workflow?**

* **Codex 5.3 (macOS App)** for daily drivers—refactors, dependency updates, targeted features. I keep it open in the background like Slack.
* **Opus 4.6 (Claude Code)** for weekend experiments where I have time to fix the collateral damage—and only when I can afford to restart my terminal every hour to clear that memory leak.

As I write this, Codex 5.3 is still chugging away on that admin panel analysis in a worktree. It’s been running for 20 minutes. Slow? Yes. But when I come back, I know it won’t have accidentally rewritten my payment processing logic just because the prompt mentioned "admin."

And in 2026, that’s the feature that actually ships products.

**P.S.** If you’re still counting tokens and comparing benchmark scores, you’re doing it wrong. The only metric that matters is "how many times did I have to revert `main` today?" By that standard, Codex 5.3 wins—but barely. Keep your diffs small, your tests running, and your screenshots ready.

_What’s your experience with agentic coding? Drop a comment before Claude Code eats all your RAM._

---

# I Gave OpenAI Codex the Keys to My Codebase for a Week. I’m Not Giving Them Back.

- **URL**: https://www.rafay99.com/blog/openai-codex-sandbox-autonomous-execution/
- **Published**: 2026-02-06
- **Author**: Abdul Rafay
- **Tags**: ThoughsProcess
- **Description**: OpenAI Codex shifts AI from suggestion-based pair programming to autonomous execution environments, forcing a fundamental restructuring of how we validate, sandbox, and trust machine-generated code.

When OpenAI dropped the Codex app for macOS, I didn't just install it—I stress-tested it against the exact workflows that make me want to throw my laptop: scaffolding Convex schemas from Figma designs, refactoring legacy navigation stacks in my Astro portfolio, and hunting hydration mismatches in React islands. I ran it for a week across four intensity tiers—Low, Medium, High, and Extra High—and shipped four production pull requests to my live site.

My verdict? **This isn't a better Copilot. This is a senior engineering team that doesn't sleep, doesn't context-switch, and—at the right intensity setting—doesn't touch code that isn't part of the mission.**

## The Paradigm Shift: From Suggestion to Delegation

Here's what the press releases won't tell you: Codex isn't "AI pair programming." It's **agentic execution with verifiable outputs.**

The old workflow: You write a prompt, AI suggests code, you copy-paste, you debug, you hate yourself.

The Codex workflow: You define the task ("Migrate the blog's color system from hardcoded CSS to Tailwind config"), spin up an isolated git worktree, and let the agent loop run. It reads your codebase, executes shell commands, runs your actual test suite, fails, debugs from `stderr`, retries, and returns a diff with full execution logs.

**The kicker:** It runs in parallel. I had three agents working simultaneously last Tuesday—one migrating TypeScript types in my Astro portfolio, one generating a Flutter widget from a Figma URL, and one hunting memory leaks in a React Native bridge. All isolated. All auditable.

## Skills: When Code Agents Learn to Actually _Do_ Things

The "Skills" feature is where this stops being a toy. Codex can invoke Figma to pull design tokens, deploy to Vercel via CLI, or generate GPT-4o images for UI mockups. I built a "Convex Schema Generator" skill in 20 minutes. Now I paste a Figma link, and Codex extracts the component structure, generates the `convex/schema.ts` definitions, writes the mutation functions, and opens a PR. It took me longer to write the commit message than to generate the entire backend.

## The Intensity Spectrum: Why "Extra High" Isn't Just "More Smart"

Here is where my week got interesting. OpenAI gives you four **intensity levels**: Low, Medium, High, and Extra High. Most assume this is token budget or model size. It isn't.

**This is about scope aggression.**

I ran identical prompts across all four tiers on my production Astro portfolio. The results were so divergent that I shipped them as separate pull requests to document the behavioral differences:

**Low: The Paranoid Intern (\[Not shipped—too useless to PR])**\
_Task:_ Update the color system to match a Figma palette and apply it to the Tailwind config.
_Behavior:_ It read `tailwind.config.ts`, updated three hex codes, and stopped. It ignored the Figma integration entirely and didn't touch the Convex schema for theme storage. Safe. Boring. Useless for real work.

**Medium: The "Helpful" Destroyer ([PR #128](https://github.com/rafay99-epic/Astro-Portfolio-Blog/pull/128))**Same task. Codex decided my utility functions "needed consistency," refactored my Astro content collections schema, and renamed variables across 12 files. It touched what wasn't broken. I rejected the PR. **Medium tier is more dangerous than High because it confuses helpfulness with scope creep.**

**High: The Surgeon ([PR #126](https://github.com/rafay99-epic/Astro-Portfolio-Blog/pull/126)** **&** **[PR #130](https://github.com/rafay99-epic/Astro-Portfolio-Blog/pull/130))**This is the sweet spot. When I asked it to redesign the blog layout with new typography, it touched exactly three files: `BaseHead.astro` for meta tags, created `ReadingProgress.svelte` (island architecture), and updated the route transition logic. It ignored my Markdown parsing, didn't refactor my React islands, and resisted the urge to "improve" my working code. **High tier identifies the minimal viable file set and does not exceed it.**

**Extra High: The Exhaustive Auditor ([PR #127](https://github.com/rafay99-epic/Astro-Portfolio-Blog/pull/127))**\
_Task:_ Complex UI surgery—redesign blog layout with responsive images and theme persistence.
_Behavior:_ It mapped the entire dependency chain. It read the `src/` directory to understand component-level color usage, checked `package.json` for conflicting CSS-in-JS libraries, scanned the Convex schema for type safety, and caught a hardcoded hex value hiding in a `dangerouslySetInnerHTML` block that High tier missed. 200k+ tokens, 4x the cost, but it caught the edge case that would have broken mobile hydration.

### The Critical Insight

**Codex has intensity-calibrated file greediness.** Lower tiers are defensive (useless); Medium is optimistic (dangerous); High is surgical (production-ready); Extra High is exhaustive (for architecture changes).

If you tell High-tier Codex to "go read the colors of the app," it finds the three files that define your design tokens and ignores the 400 components consuming them. This restraint is the superpower. As a Full Stack Engineer who finds reading textbooks boring but lives for solving novel problems, this behavior is nirvana—I delegate the boilerplate archaeology while keeping the architecture decisions.

**My recommendation:** Skip Low and Medium. Use **High** for 90% of tasks. Use **Extra High** only when touching auth, payments, or schema migrations—where "I didn't know that file existed" equals a security breach.

## The Honest Truth: Where It Frays

You asked me not to sugarcoat it.

**1. Token economics are brutal.**That agent loop is expensive. Every tool call—every `ls`, every `npm test`, every `git status`—round-trips through the API. A 30-minute Extra High session can burn 200k+ tokens. Those "doubled rate limits" on Plus evaporate fast.

**2. Verification is the new bottleneck.**When AI writes code, you review it. When AI _executes_ code autonomously, you must **audit the execution trail**. I caught Codex "fixing" a Convex query by removing a pagination limit—technically passing the test, functionally wrong for production. The logs are comprehensive, but you still have to read them.

**3. The "personality" toggle is gimmicky.**Terse vs. conversational modes change verbosity, not output quality. I leave it on terse because time is money.

## Final Conclusion: The Verification Shift

After shipping four PRs in one week while maintaining my role at Tudo Tech Lab, I've stopped thinking about "AI coding assistants." That category is dead. **We are now in the era of scoped agentic execution.**

The discovery isn't that Codex writes good React (it does) or that it sandboxes safely (it mostly does). The discovery is that **intensity calibration changes the fundamental contract between human and machine.** At High tier, Codex exhibits restraint—it resists refactoring working code, resists "improving" abstractions, and solves the specific problem in the specific files, then stops.

This is the behavior that makes it production-ready. Not the parallelism. Not the skills. The restraint.

**The workflow that actually works:**

1. **High tier** for 90% of tasks—surgical, fast, minimal diff
2. **Extra High** only for auth, payments, or schema migrations—expensive but exhaustive
3. **Never Medium**—the "helpful refactorer" is your enemy
4. **Never Low**—the "too scared to touch anything" agent wastes your time

The token economics sting, but compared to engineering hours spent context-switching between Convex schema design and Astro island hydration debugging? The math is brutal in Codex's favor.

## Final Thought: The Editor vs. The Executor

We spent years treating AI as an _editor_—something that suggests, hints, nudges. That made sense when hallucinations were high and context windows were small. But Codex with High/Extra High intensity isn't an editor. It's an _executor_ with configurable scope aggression.

**The mental shift:** You're no longer curating suggestions. You're writing specs for autonomous agents and auditing execution trails. The skill that matters now isn't syntax knowledge—it's **task decomposition and verification discipline.** Can you write a prompt tight enough that High-tier Codex knows exactly which 3 files matter? Can you read a git diff fast enough to spot when Extra High overreached?

If you can, you just gained a parallelized engineering team that doesn't context-switch, doesn't get tired, and—at High intensity—doesn't mess with code that isn't part of the mission.

**Stop vibe coding. Start delegating with precision.**

## TL;DR

**Codex isn't "smarter" at higher intensities—it becomes more surgically greedy with file access.** Low tier touches nothing; Medium "helpfully" destroys your architecture ([PR #128 rejected](https://github.com/rafay99-epic/Astro-Portfolio-Blog/pull/128)); High tier identifies the exact 3 files needed without touching 400 components ([PR #126](https://github.com/rafay99-epic/Astro-Portfolio-Blog/pull/126), [#130](https://github.com/rafay99-epic/Astro-Portfolio-Blog/pull/130)); Extra High maps the entire dependency chain to catch edge cases like hydration mismatches ([PR #127](https://github.com/rafay99-epic/Astro-Portfolio-Blog/pull/127)).

**The verdict:** One developer can run parallelized agents with scope-calibrated precision. Token costs are real (4x jump from Low to Extra High), verification is mandatory, but shipping 4 production PRs in a week while holding down a full-time job? That's the leverage. Skip Low and Medium. Start with High.

**Get on the waitlist. Calibrate your intensity. Audit the diffs.**

---

# The Junior Developer Trap: How AI Assistance Creates Permanent Beginners

- **URL**: https://www.rafay99.com/blog/ai-coding-assistance-skill-atrophy-anthropic-research/
- **Published**: 2026-02-02
- **Author**: Abdul Rafay
- **Tags**: AI, ThoughtsProcess
- **Description**: New Anthropic research reveals AI coding assistants might be stunting developer growth. Here's why your Copilot addiction is creating a skills crisis—and what to do about it.

Your AI coding assistant is making you a worse programmer. No, seriously—Anthropic just confirmed that the tool you're using to ship features 50% faster is also the reason you can't whiteboard a binary search tree anymore. But sure, keep letting Copilot write your `useEffect` hooks. What could go wrong?

Anthropic dropped a research paper recently that confirms what your imposter syndrome has been whispering: **AI coding assistants are creating a generation of developers who can ship fast but think slow.**

The study found that developers using AI assistance complete coding tasks significantly faster (shocker), but here's the kicker—they demonstrate markedly lower skill retention and problem-solving ability when the AI is removed. It's the cognitive equivalent of using a GPS for every drive: sure, you get there, but try navigating your own neighborhood without Siri and suddenly you're lost in a cul-de-sac of your own making.

### **The Research in Plain English**

Anthropic's team had developers tackle coding problems with and without AI assistance. The AI-assisted group crushed it on speed. But when tested on conceptual understanding and asked to solve similar problems solo later, they performed worse than the control group who struggled through manually.

The effect was **asymmetric**: senior developers maintained their skills (the AI just made them faster), while junior developers showed significant skill degradation. The AI wasn't augmenting their cognition—it was _replacing_ it.

### **The Uncomfortable Truth Nobody's Talking About**

Here's where I stop sugarcoating: **Current AI tools are designed by experts, for experts, but marketed to beginners.**

When you're a senior dev with 10 years of pattern recognition, AI acts like a really smart autocomplete. You know when it's hallucinating. You understand the trade-offs of that regex it just suggested. But when you're a junior? You're not pair programming with a senior—you're copy-pasting from a confident idiot that writes elegant-looking garbage.

The research exposes what I call the **"Skill Convexity Problem"**: AI flattens the learning curve so aggressively that you never build the mental muscle to handle complexity. You're not learning to code; you're learning to prompt. And when the AI inevitably hits a wall (complex debugging, architectural decisions, performance optimization), you're standing there with atrophied debugging skills and a blank stare.

### **The Flaws in the Current Approach**

Let's critique the research too, because nothing's perfect. The study measured _short-term_ task completion, not long-term software maintenance. It didn't account for the "scaffolding effect"—maybe juniors struggle initially but catch up later? (Spoiler: probably not, but we don't know.)

More importantly, the research treats all AI assistance as monolithic. There's a difference between using AI to generate boilerplate TypeScript interfaces and using it to architect your Convex schema. The former saves time; the latter steals thinking.

### **Outside-the-Box Solutions (Because "Use AI Less" Isn't Helpful)**

Since "just code without AI" is about as realistic as "just use vanilla JavaScript," here are some actually useful alternatives:

**1. The Socratic Rubber Duck Mode**\
Build (or demand) an AI assistant that refuses to give you code until you've explained your approach. Force it into a "question-only" mode: _"Why do you think you need a useEffect there? What dependencies are you tracking?"_ If AI is going to be your pair programmer, make it an annoying, pedantic senior dev who cares about your growth.

**2. Skill-Debt Tracking**\
We track technical debt. Why not track _skill debt_? Every time you accept an AI suggestion without understanding it, log it. Weekly review: "I let AI write 15 regex patterns this week and I understand 3 of them." That's your learning queue for next week.

**3. The "Ghost Protocol"**\
Set a timer. After 30 minutes of AI assistance, the AI "ghosts" you for the next task. Force yourself to implement the next feature using only what you learned (or think you learned). It's interval training for your brain.

**4. Pedagogical Constraints**\
Use AI, but constrain it intentionally:

- Ask it to solve the problem using only concepts you already know
- Have it generate three solutions: elegant (but complex), readable (but verbose), and "junior dev" (what you'd write). Study the gaps.
- Force AI to write intentionally broken code for you to debug. Active learning > passive consumption.

**5. The Convex Recovery Method**\
Since you use Convex (shoutout to your stack), leverage it for skill tracking. Build a personal knowledge graph that tracks which AI-assisted code you actually understand. If you can't explain the reactive query you just wrote, it doesn't get committed until you can.

### **My Thoughts & Analysis**

The scariest part of this research isn't that AI makes us slower thinkers—it's that **it makes us _unaware_ that we're slower thinkers.** The Dunning-Kruger effect on steroids.

As someone who ditched research because "books are boring," you should be particularly worried. AI is the ultimate boredom-killer, but learning _requires_ productive struggle. The "aha!" moment comes from wrestling with the problem, not from reading the solution. Anthropic's data suggests we're outsourcing the struggle, which means we're outsourcing the expertise.

But here's the contrarian take: **This isn't AI's fault; it's our implementation.** We built AI to be a crutch because our industry prioritizes shipping features over developing humans. The solution isn't less AI—it's _smarter_ AI. We need AI that intentionally creates friction for learning, not just velocity.

The research also misses the meta-skill: prompt engineering _is_ a skill, just a shallow one. It's like learning to use a calculator when you don't know math. Useful, but brittle.

### **The Bottom Line**

Your AI assistant isn't evil, but it is a terrible teacher. It's a performance enhancer, not a protein shake. Use it to lift heavier weights, not to avoid going to the gym.

If you're a junior dev reading this: set boundaries. Use AI for syntax, not logic. For boilerplate, not architecture. If you can't whiteboard what the AI just wrote, you don't own that code—you're just leasing it from an LLM that might hallucinate away tomorrow.

**Ship fast, but learn faster.** Otherwise, you'll be a "Senior Developer" who can't code without an internet connection, and that's not a senior developer—that's a prompt engineer with imposter syndrome.

---

# Flutter Didn’t Fail Me — But React Native Woke Me Up

- **URL**: https://www.rafay99.com/blog/flutter-did-not-failed-me-react-native-is-fun/
- **Published**: 2025-12-14
- **Author**: Abdul Rafay
- **Tags**: Bun, MobileDevelopment, WebDevelopment
- **Description**: I avoided React Native for years because Flutter felt safe. But one evening with Expo Router and Bun changed my mind. This isn't a framework war—it's a look at how thinking in "URLs" instead of "Widgets" can simplify your mobile architecture. Here is what a Flutter dev learned from the other side.

If you’ve been shipping mobile apps for more than five minutes, you know the feeling.

Your tech stack works. Your apps ship. Nothing is arguably _broken_… yet something keeps tapping you on the shoulder.

Flutter was that safe house for me. For years, it was my default answer for Android and iOS. It was fast, strongly typed, and honestly hard to argue against. I shipped apps, billed clients, and never felt like Flutter was the bottleneck. So when the Twitter (X) tech influencers kept shouting _“You have to try React Native now, it’s different!”_, my reaction was a standard developer eye-roll.

**Why?**

Rebuilding an app in a new framework just to “see the vibes” is a terrible way to burn a weekend. Refactoring for curiosity doesn’t pay the bills. And React Native? It always felt like that chaotic JavaScript thing I’d get to _eventually_.

Until one Tuesday evening, bored and over-caffeinated, I finally bit the bullet.

What started as a "quick experiment" with Expo turned into a complete existential crisis regarding how I handle navigation, styling, and my mental model of mobile development. No hype. No "Flutter is dead" clickbait. Just a genuine _“Oh… I’ve been making this harder than it needs to be”_ moment.

In this post, we’re cutting through the fanboy noise to look at:

- **The "Context Hell"** taking a vacation: How Expo Router fixed my brain.
- **The Styling Shock:** Why CSS-ish styling felt oddly refreshing after years of Widget trees.
- **The Verdict:** What Flutter devs can steal from React Native without actually switching.

This isn’t a breakup letter to Flutter. It’s more like admitting I cheated on my main stack and learned some new tricks.

## Flutter Was My "Comfort Hoodie"

Flutter didn’t just work—it _fit_.

One codebase. Google-backed stability. Strong opinions baked into the framework. Once you swallow the pill of "Everything is a Widget," life is predictable.

Navigation? Sure, it’s verbose, but it’s explicit. You know the drill:

```dart
Navigator.push(
  context,
  MaterialPageRoute(
    builder: (context) => const SecondPage(
      message: 'Please don\\'t lose context',
    ),
  ),
);

```

There’s no mystery here. You are grabbing the `context` by the throat, building a route, and shoving it onto the stack. It’s disciplined. It’s safe.

And styling? You don’t "style" a button; you _construct_ it. Padding inside a Container inside a Row inside a Column. It’s a deep tree, but at least you know exactly where the padding is coming from (spoiler: it’s always the parent widget you forgot about).

So when people talk about Flutter "falling behind," I laugh. Flutter is fine. It’s great, actually.

Which is exactly why React Native never felt urgent. I didn’t need "faster hot reload" (Flutter’s is fine). I didn’t need JavaScript (I actually like types, thanks).

From the outside, React Native looked like the Wild West. `npm install` roulette? dealing with Bridge issues? No thanks. I stayed in my typed, compiled, widget-safe lane.

Until curiosity—and boredom—won.

## Why React Native Never Clicked… Until It Did

I’d heard the pitch:

- "Expo makes it easy."
- "Over-the-air (OTA) updates are a cheat code."
- "It's just React."

Cool. Still didn't care.

The blocker wasn't the tech; it was the **setup tax**. I didn't want to wrestle with Xcode versions or Gradle daemons just to render "Hello World."

But then I tried **Bun**.

If you haven't used Bun, it's what Node.js wishes it was. Fast. absurdly fast. I initialized an Expo project using Bun, fully expecting to spend 30 minutes debugging environment variables.

Instead, the app was running on my phone in seconds.

I opened the project file structure and immediately felt that specific developer panic: **"Where is the `main` file?"**

There was a `tabs` folder. A `layout.tsx`. Files that looked like URL routes. Nothing resembled the `main.dart` entry point I worshipped. In Flutter, I build the screens, I define the routes, I control the universe. Here, it felt like the file system was controlling _me_.

So I did the standard procedure:

1. Panic.
2. Google "Expo Router wtf".
3. Ask ChatGPT to explain it to me like I'm 5.

And then it clicked.

**Stop thinking about it as a Mobile App.Start thinking about it as a Website.**

The moment I realized Expo’s folder structure is basically the **Next.js App Router**, the headache vanished. Files aren't just code; they are **URLs**. Layouts aren't wrappers; they are persistent UI shells.

That was the first crack in my Flutter armor.

## The Expo Router Epiphany: Files _Are_ The Roadmap

Once I stopped fighting the folder structure, I realized how much boilerplate I had been writing in Flutter.

In an Expo Router project, your file system **is** your navigation map.

```
app/
 ├─ _layout.tsx      <-- The Wrapper (think Scaffold)
 ├─ index.tsx        → route: /
 ├─ login.tsx        → route: /login
 └─ (tabs)/
    ├─ _layout.tsx   <-- Tab Bar Logic
    ├─ profile.tsx   → route: /profile
    └─ settings.tsx  → route: /settings

```

If you’ve touched Next.js, you’re nodding your head. If you’re a Flutter dev, you’re probably squinting. _“Where is the Route definition map?”_

There isn’t one. You just make a file.

### Navigation Without the Ceremony

In Flutter, moving between screens is a grand event. You need the `context`, you need the class name, you need the params.

In Expo Router, you just… change the URL.

```tsx
// Look ma, no context!
router.push("/home");
router.replace("/login");
router.back();
```

No `BuildContext`. No generic type arguments. No importing the screen widget file.

You aren't pushing a screen. **You are changing location.**

This sounds like semantics, but it changes everything. Authentication redirects? Just check the user state and replace the URL to `/login`. Deep linking? It works out of the box because _every screen is already a URL_.

In Flutter, Deep Links are a configured nightmare in `AndroidManifest.xml` and `Info.plist`. In Expo, they just... work.

---

## Styling: The "Utility First" Shock

Flutter developers take pride in the Widget Tree. We love our `Padding(child: Center(child: ...))`.

React Native (specifically with **NativeWind**, which is just Tailwind for mobile) feels like cheating.

**Flutter:**

```dart
Container(
  padding: const EdgeInsets.all(16.0),
  decoration: BoxDecoration(
    color: Colors.blue,
    borderRadius: BorderRadius.circular(8),
  ),
  child: const Text('Click Me'),
)

```

**React Native + NativeWind:**

```tsx

  Click Me

```

Is it "cleaner"? Debatable. The HTML/CSS purists hate it.
Is it faster to write? **Absolutely.**

Separating style from logic (even if it's just utility classes) felt weirdly liberating. I wasn't fighting the nesting indentation hell that complex Flutter layouts sometimes turn into.

## The Side-by-Side: Logic & State

This is where the "Web DNA" of React Native shines.

In Flutter, state management is a religion. Are you Team Provider? Team Riverpod? Team Bloc? Team "GetX is the devil"?

React Native just uses **Hooks**.

```jsx

  // It's just React.
  const [count, setCount] = useState(0);

  return  setCount(count + 1)} />;
}
```

Local state is trivial. Global state? Wrap the root layout in a Context Provider. Async stuff? `useEffect` (just don't forget the dependency array, or you'll infinite loop your API quota).

For backend, I threw in **Convex** and **Firebase**.

- **Flutter:** Requires platform channels, specific packages, and sometimes native configuration.
- **React Native:** It’s basically just JavaScript. If it works on the web, it probably works here.

## What Flutter Devs Can Learn (Without Switching)

Look, I’m not saying "Delete your Flutter repo." Flutter is still king for performance-heavy, animation-rich, custom UI apps.

But React Native taught me:

1. **URL-Based Thinking is Superior:** Even in Flutter, try to model your navigation state as a "path" rather than a stack of cards. It makes deep linking and web support much less painful later.
2. **Less Boilerplate is Okay:** We sometimes over-engineer Flutter apps with "Clean Architecture" for a simple To-Do list. React Native’s "just write the component" attitude is a good reminder to ship faster.
3. **The Web ecosystem is massive:** React Native lets you piggyback on the entire JavaScript npm ecosystem. Flutter is catching up, but JS libraries are infinite.

## Conclusion: Use Whatever Ships the App

Flutter isn’t going anywhere. It’s solid. It’s compiled. It’s Google.

React Native isn’t perfect. `node_modules` is still the heaviest object in the universe, and sometimes the bridge between JS and Native code acts up.

But **Expo has closed the gap.**

If you are a Flutter developer, this isn't a "switch or die" warning. It’s a suggestion to peek over the fence.

Go create a folder. Run `npx create-expo-app@latest`. Get confused by the folder routing. Scream at a missing dependency.

But then, watch the lightbulb turn on when you realize you just built a cross-platform app with fully working deep links in 20 minutes.

Because at the end of the day, users don't care about your `StatelessWidget` or your `useEffect`. They care about the app on their home screen.

Now, go build something.

---

# Weaving DNA Into a Living Form Builder

- **URL**: https://www.rafay99.com/blog/dynamic-form-generation-dna/
- **Published**: 2025-11-21
- **Author**: Abdul Rafay
- **Tags**: AI, WebDevelopment
- **Description**: Every once in a while you inherit a greenfield problem that feels equal parts thrilling and terrifying. Ours was simple to describe and brutal to execute: build a vendor onboarding experience where no field is hardcoded, every service type defines its own rules, and UI + validation + submission logic are all generated from server-delivered JSON that we lovingly called DNA. This is the story of how that system came to life inside `webapp_frontend`, what it looks like today, and the lessons learned while making it production-ready.

Every once in a while, you inherit a greenfield problem that feels equal parts thrilling and mildly panic-inducing. And before we even get into it… yes, I know. I haven’t written a blog post in almost two months. Turns out once you get an actual job and start shipping real features (and occasionally breaking production 🤫), time disappears faster than your console logs during a refactor.

But I’m a “real dev” now — pushing code, fixing bugs, summoning TypeScript errors like Pokémon — so naturally, my first post after this drought had to be about something dramatic.

And ours _was_ dramatic: build a vendor onboarding experience where **nothing is hardcoded**, every service type invents its own rules, and the UI, validation, and submission logic all magically assemble themselves from server-delivered JSON we lovingly called **DNA**.

This is the story of how that system came to life inside `webapp_frontend`, what it looks like today, and what I learned while making it production-ready (and not crying… most days).

## The Blank Canvas (But Make It Relatable)

When we kicked things off, there was no schema, no wizard, and definitely no guardrails. It was the kind of blank canvas that sounds empowering until you realize you’re the one expected to paint the Mona Lisa with a broken brush and a deadline.

Product came to us with requirements that basically said:

- “We have dozens of service categories, each with their own weird personality quirks — custom fields, custom pricing knobs, custom documents, custom everything.”
- “Also, the APIs will evolve weekly because business is still figuring out what they want.”
- “Oh, and the UX needs to look premium. Not like one of those sad online form builders from 2010.”

In other words:
**Do not hardcode anything**
**Do not assume anything**
**Do not break anything** (haha)

Hard-coding forms or turning the app into a graveyard of feature flags would’ve collapsed instantly. We needed a lightweight contract that could describe every tiny variation without turning us into part-time archaeologists digging through JSX conditionals.

So we created our hero: **DNA**.

## What DNA Actually Encodes (aka JSON With Superpowers)

DNA is fetched per service type through `useDNALoader`, and it arrives wrapped as a `DNAConfig` object (`src/types/dna.ts`). Think of it as a tiny JSON-powered design system that politely tells the UI what to do, how to behave, and when to panic.

It defines things like:

- **`base_fields`** — all the random inputs: strings, numbers, booleans, selects, regex validations, placeholders, existential crises, etc.
- **`pricing_rules`** — which pricing fields matter and under what mode (hourly, fixed, hybrid, pick-your-own-nightmare).
- **`location_rules`** — whether the service is on-site, remote, or "it depends," and what fields (lat, lng, radius, address) become required.
- **`required_documents`** and **availability** — because sometimes you need an ID card, sometimes you need a portfolio, and sometimes you need _both sides_ of something for reasons nobody remembers.

Since React doesn’t know (or care) what service type is being registered, the entire personality of the form comes from interpreting this DNA.

It’s basically configuration-driven UI on steroids — but without becoming unmaintainable spaghetti, because all the logic lives in well-defined hooks rather than scattered `if` conditions.

## Lifecycle at a Glance

```mermaid
graph TD
    Wizard[ServiceRegistrationWizard] -->|serviceTypeId| Loader[useDNALoader]
    Loader -->|DNAConfig| Config[useDnaFormConfig]
    Config -->|builders + validators| State[DynamicServiceFormStep state]
    State -->|per-step data| UI[DynamicField & specialized sections]
    UI -->|updates| State
    State -->|validated payload| FormData[buildServiceFormData]
FormData --> API[Vendor API]
```

This loop means new DNA drops from the backend without a single code change on the frontend.

## Spoiler: Geek-Out Ahead (Developer Mode Activated)

Okay, buckle up — this is the part where we stop pretending this is a “simple” form system and admit it’s basically a miniature runtime. If you came here for architecture candy, reactive state wizardry, and “how the hell is this form alive?” moments… yeah, this is that section.

The snippet below is the whole contract in motion. DNA drops in → hooks assemble defaults → steps self-build → validation slams the brakes if something’s off. It’s the closest thing to watching the UI read its own source code.

```tsx
// src/app/vendors/.../DynamicServiceFormStep.tsx (simplified)
const { dnaConfig, loading, error, reload } = useDNALoader(serviceTypeId);
const {
  filteredBaseFields,
  buildInitialBaseFields,
  buildInitialPricingFields,
  buildInitialDocuments,
  buildInitialAvailability,
  shouldRenderPricing,
  shouldRenderLocation,
  getIgnoredLocationFields,
  validateAll,
} = useDnaFormConfig(dnaConfig);

useEffect(() => {
  if (!dnaConfig) return;
  setBaseFields((prev) => prev ?? buildInitialBaseFields());
  setPricingFields((prev) => prev ?? buildInitialPricingFields());
  setDocuments((prev) => prev ?? buildInitialDocuments());
  setAvailability((prev) => prev ?? buildInitialAvailability());
}, [
  dnaConfig,
  buildInitialBaseFields,
  buildInitialPricingFields,
  buildInitialDocuments,
  buildInitialAvailability,
]);

const steps = useMemo(() => {
  const base = ["details"];
  if (shouldRenderPricing) base.push("pricing");
  if (shouldRenderLocation) base.push("location");
  if (dnaConfig?.required_documents?.length) base.push("documents");
  if (dnaConfig?.availability_required) base.push("availability");
  return [...base, "review"];
}, [dnaConfig, shouldRenderPricing, shouldRenderLocation]);

const canProceed = validateAll({
  baseFields,
  pricingFields,
  locationFields,
  documents,
});
```

Those lines?
That’s the blood circulation system of the entire form engine.

## Inside the Engine Room (Where the Magic Lives)

### 1. Loading + Normalizing (a.k.a. “Nobody Enters Without DNA”)

`useDNALoader` is the bouncer.
No `serviceTypeId`? → no entry.
Backend hiccups? → take a seat, here’s the error.

It guarantees **zero partial renders** — the UI never stumbles into some half-loaded Frankenstein state.

```ts
// src/hooks/useDNALoader.ts

  const [dnaConfig, setDnaConfig] = useState(null);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState<string | null>(null);

  const load = useCallback(async () => {
    if (!serviceTypeId) return setDnaConfig(null);
    setLoading(true);
    try {
      const raw = await getDNALoader(serviceTypeId);
      setDnaConfig(raw.data);
    } catch (err) {
      setError(
        err instanceof Error ? err.message : "Failed to load DNA configuration",
      );
    } finally {
      setLoading(false);
    }
  }, [serviceTypeId]);

  useEffect(() => void load(), [load]);
  return { dnaConfig, loading, error, reload: load };
}
```

Once DNA arrives, **`useDnaFormConfig` puts on the lab coat** and starts preparing everything the UI will need — initial values, field filters, rules, cross-field validation policies, you name it.

```ts
const filteredBaseFields = useMemo(
  () =>
    dnaConfig?.base_fields.filter((f) => !LOCATION_FIELD_NAMES.has(f.name)) ??
    [],
  [dnaConfig],
);
```

We keep all builders inside this hook so when the backend introduces some new exotic field type (yes, it’ll happen), we update _one_ place — the entire app becomes fluent instantly.

### 2. State Scaffolding & Wizard Navigation (The Self-Assembling UI)

`DynamicServiceFormStep` is the conductor.
Every step of the wizard is dynamically generated _from DNA_, meaning the UI literally builds itself.

- No pricing in DNA? Pricing step disappears.
- No documents? No documents step.
- Remote-only? Location logic calms down.
- Availability required? Boom — availability step appears.

It feels handcrafted for every service type… but it’s all data-driven.

### 3. Leaf Field Rendering (Where Chaos Becomes UI)

`DynamicField` is the universal renderer.
It’s the place where every weird option, placeholder, boolean, regex, integer, and multi-select transforms into a polished Shadcn component.

Highlights:

- Strings-with-options silently become full dropdowns.
- Number fields allow temporary empty strings (a must-have for UX sanity).
- Boolean fields fall back to chatty radio groups.
- Checkbox fields with options become multi-select arrays.
- File fields gracefully handle single/multi uploads.

And yes — the renderer solves headless UI quirks like a champ.

### 4. Specialized Components for Specialized Pain

Some domains break all the rules, so we isolate them:

- **PricingFields** (hourly, fixed, hybrid — all DNA-driven)
- **LocationFields** (pins, geocoding, radius, toggles)
- **DocumentUploadField** (file sides: front/back/both)
- **AvailabilityCollection** (time slots that don’t break)

Each one keeps UX high-level while offloading the rules into `useDnaFormConfig`. One source of truth, zero surprises.

## Validation & Serialization: The Guardrails That Never Sleep

Before the “Next” button does anything:

### `validateAll` checks everything:

- Required base fields
- Number ranges
- Regex patterns
- Pricing invariants (based on pricing mode)
- Location requirements (lat/lng + address)
- Document requirements (front/back/both)

No step moves unless the data is clean.

### Then, when the user submits:

`buildServiceFormData` serializes the entire payload using the **same DNA definitions**, so backend and frontend never drift.

```ts
form.append(field.name, value ? "true" : "false");
```

Arrays? Indexed keys.
Files? Correct multipart names.
Booleans? `"true"/"false"`.
Complex structures? Flattened but not mangled.

It’s deterministic, predictable, and very hard to break accidentally.

## Guardrails, Battle Scars & Lessons Learned

- Don’t render forms before DNA loads — UI gets cranky.
- Type coercion will betray you, so we centralized every helper.
- Location flows are strict on purpose (broken pins = broken orders).
- Redux persistence saves vendors from rage-quitting on refresh.
- New field types are a 5-step checklist, not a rewrite.

## What This Architecture Actually Proves

This system demonstrates:

- Clean separation of configuration (DNA) and rendering logic.
- A scalable, zero-hardcoding dynamic form engine.
- An onboarding flow that self-adapts as business rules evolve.
- A validation + serialization pipeline that guarantees backend compatibility.
- Hooks that encapsulate async, derived state, and rule logic so components stay readable.

And honestly?
It shows we can take a chaotic requirement like:

> “Make this form build itself from JSON… and make it look premium.”

…and deliver something robust enough to become **the backbone of the vendor onboarding flow**.

## Conclusion: Why This Architecture Was Worth Every Late Night

At the end of the day, this whole DNA-driven system isn’t just a clever trick — it’s a survival strategy. When the business keeps evolving, when service types multiply like Pokémon, and when backend rules shift faster than product can finalize documentation, this architecture becomes the difference between scaling gracefully… and drowning in hard-coded forms.

By pushing all variability into DNA and letting the UI self-assemble, we built something that is:

- **Flexible enough** to support dozens of service categories without rewriting components.
- **Strict enough** to guarantee clean validation and correct API payloads every single time.
- **Extensible enough** that adding new field types or pricing models feels like adding a new Lego piece — not rebuilding the entire castle.
- **Reliable enough** that vendors feel like each flow was handcrafted for them, even though the renderer did all the heavy lifting.

And the best part?

Every time the backend ships a new configuration and the entire UI rearranges itself with zero code changes…
you get that quiet moment of satisfaction that says:

**Yep.
This is why we engineered it properly.
This is why the architecture matters.**

The DNA engine isn’t just a form builder — it’s a foundation.
One that will keep absorbing complexity so the product team can keep dreaming, the backend can keep iterating, and the UI will always stay in sync without ever falling apart.

---

# Everything Is a Wrapper: Seeing Software (and Life) Differently

- **URL**: https://www.rafay99.com/blog/everything-is-a-wrapper-seeing-software-and-life-differently/
- **Published**: 2025-10-09
- **Author**: Abdul Rafay
- **Tags**: DevelopmentTools, ThoughtsProcess
- **Description**: Everything Is a Wrapper: Seeing Software (and Life) Differently

I was scrolling the web looking for blog ideas — the usual loop. A new tech drops, a new AI model comes out, and within hours, everyone’s already writing about it. The excitement fades fast when you realize there’s nothing new left to say.

But then, while I was searching, I stumbled upon a simple phrase online: “Everything in life is a wrapper.”

That line hit me hard. The amount of thought packed into those few words was wild. I’m a software developer, so naturally, I started wondering — how true is that in software? Is everything really just a wrapper?

I searched around, but there weren’t many articles about it. Weirdly enough, no one seemed to be talking about it. Then I found a video by Theo where he breaks it down — explaining how in software, almost everything we use is built on top of something else.

After watching that, I couldn’t unsee it. It changed the way I looked at code — and honestly, a bit of how I looked at everything.

## Seeing Wrappers Everywhere

Once I started thinking about it, I couldn’t stop seeing wrappers everywhere.

Think about it — when we use **React**, we’re just wrapping the DOM with components. When we use **Next.js**, that’s a wrapper around React. **Vite** wraps the dev server. **TypeScript** wraps JavaScript. Even **JavaScript** itself is just a higher-level wrapper over machine instructions.

Every tool we use, every line of code we write, is one layer hiding the raw complexity underneath.

And it’s not just the code — even in our workflows, we’re surrounded by wrappers. Git wraps our file history. Docker wraps our environment. Firebase wraps the backend. The more we abstract, the easier life gets — but also, the further we drift from the core.

I realized we don’t build from scratch anymore. We build on top of layers that others built — wrapping, extending, improving. It’s not laziness; it’s evolution. Wrappers are what make progress possible. They let us focus on meaning instead of mechanics.

## Why Wrappers Exist

The more I thought about it, the more I realized — wrappers exist for a reason.

We don’t build them just to be fancy. We build them because they make life easier. Imagine if every time you wrote a web app, you had to manually handle memory, render HTML, and manage state changes from scratch. You wouldn’t ship anything. Wrappers give us freedom. They let us move faster, focus on solving problems, not rewriting the same low-level code again and again.

It’s abstraction — and abstraction is efficiency. React abstracts the DOM so we can think in components. Next.js abstracts routing and deployment so we can focus on product. Firebase abstracts the backend so we can launch faster. It’s all layers of time-saving brilliance stacked on top of each other.

## The Hidden Cost of Wrappers

But then again… every wrapper hides something. And that’s where the problem starts.

Because once you get too comfortable living inside wrappers, you start forgetting what’s underneath. When something breaks deep down, you freeze — you can’t fix what you don’t understand. Suddenly that nice layer of abstraction becomes a wall.

I’ve seen it happen a lot. A simple error bubbles up from a library, and the whole team panics because no one knows what it’s really doing under the hood. We’ve all been there — googling for a fix instead of understanding the why.

So I started to think maybe learning the core isn’t about rejecting wrappers. It’s about balance. Knowing what the wrapper is hiding, what trade-offs it makes, and where it ends. Because once you understand that, wrappers stop being crutches — they become tools.

## Why Wrappers Matter

So that got me thinking — if everything is a wrapper, **why do wrappers matter so much?**

They matter because they define how we think. Every abstraction changes the way we approach a problem. The tools we use shape our logic. When you build with React, you start thinking in components. When you switch to Flutter, you think in widgets. When you work with machine learning frameworks, you think in tensors. The wrapper becomes the lens.

That’s powerful — but also dangerous. Because if your only tool is a hammer, everything looks like a nail. Wrappers influence what we believe is “possible” or “normal” in development. They set mental boundaries that don’t actually exist underneath. That’s why wrappers matter — they’re not just code; they’re perspective.

## Should You Learn the Wrapper or What’s Underneath?

Then comes the real question: **should you learn the wrapper or what’s underneath?**

Honestly? Both — but not at the same time.

If you’re just starting out, learning through wrappers is fine. It’s how most of us get hooked. You build something that works and it keeps you motivated. You don’t need to read the entire C spec to write your first JavaScript app.

But as you grow, you start hitting walls — bugs that make no sense, tools that fail silently, systems that don’t scale the way they should. That’s when going deeper actually pays off. Understanding what the wrapper is hiding gives you confidence. You stop being scared of errors and start breaking things on purpose — because you _know_ how to fix them.

## The Mark of a Great Engineer

And that’s what makes the difference between a good engineer and a great one.
A good engineer knows how to use the wrapper.
A great engineer knows what it’s hiding — how the web flows, how data moves, how systems behave when you push them to their limits.

Knowing your tools isn’t optional. It’s the main thing that separates building something that works from building something that lasts.

Because in the end, everything _is_ a wrapper — from your favorite framework to the operating system it runs on.
But what truly matters is how you see beyond it.
The best engineers don’t just use wrappers; they understand the story beneath them.

> **Everything is a wrapper. But the real magic is knowing what’s inside.**

---

# Building a Custom Dynamic Link Solution for a Flutter App

- **URL**: https://www.rafay99.com/blog/dynamic-link-solution-for-flutter-app/
- **Published**: 2025-10-04
- **Author**: Abdul Rafay
- **Tags**: DevelopmentTools, MobileDevelopment, WebDevelopment
- **Description**: Firebase Dynamic Links is deprecated. Follow my journey of building a custom, cost-effective dynamic link and URL shortening solution for a Flutter app using a Next.js API and Firestore.

Not too long ago, I was reading a book called "Second Brain" that really resonated with me. The author talked about creating a personal, digital space where all your notes and information are stored. Inspired, I set out to find the perfect application. I tried everything from Notion to Obsidian, Google Keep, and a dozen others in between, but nothing felt quite right.

So, I built my own: MS Bridge. I had two main goals for this app. First, I needed easy access to all my master notes. Second, I wanted to take detailed notes for both personal and class use.

I wrote an entire blog post and created a video explaining how I built the application, which you can check out here:

The app served me well, and soon I wanted to share some of my personal notes and experiences with my team members. I integrated Firebase Dynamic Links, which worked perfectly. But not too long ago, after a major Flutter upgrade, I noticed a lot of the codebase was relying on deprecated features.

That's not great for security, performance, or even maintainability. I decided it was time to move away from all the outdated code, but in that process, I hit a major roadblock: Firebase Dynamic Links was being deprecated. This feature was critical for me.

Like any other developer, my first instinct was to find a simple solution. My plan was to migrate from Firebase Dynamic Links to a custom solution. It might look complex, but I promise it's straightforward—though I'll admit the debugging and migration process was painful.

Now, you might be thinking, "Why not just use another service?" Shut up, you haven't done the research. All the solutions on the market were either expensive or overly complex; there was no simple drop-in-and-go option.

And like I said, I'm broke. So, I went on the journey of making my own solution. It wasn't easy, but I did it, and I'm very proud of how it turned out. Now, I want to share my experience with you.

## The Solution

The core idea is simple: the Flutter app hits an API endpoint, a server grabs some information, generates a unique link, and redirects the user to the right page.

But you might be wondering where the URL is actually being rendered. The magic happens with a combination of Firebase for the database and a Next.js backend handling the server-side logic, with some back-and-forth communication between the app and the server.

## The Flow

Here’s the gist of it:

1.  **App prepares share info** → The Flutter app identifies what’s being shared (`note` or `voice`) and grabs its unique ID and original URL.
2.  **Request short link** → Flutter calls our Next.js backend (`POST /api/shorten`) with the `{ shareId, type, originalUrl }`.
3.  **Server allocates code** → Next.js checks Firestore to see if a short code already exists for this item. If not, it creates a new one.
4.  **Server responds** → It returns a clean short link, like `https://site/r/abc123`.
5.  **App displays link** → The Flutter app shows the new link, making it easy to copy and share.
6.  **User clicks link** → Their browser hits the `/r/[code]` URL. The server then redirects them to the final destination, either `/s/[shareId]` for notes or `/voice/[shareId]` for voice memos.
7.  **Page loads data** → The web page fetches the shared content using another API call and displays it in a read-only format.

## Sequence Diagram

This diagram shows how all the pieces interact:

```mermaid
sequenceDiagram
    participant F as Flutter App
    participant N as Next.js API
    participant DB as Firestore
    participant U as User Browser
    participant P as Public Page

    F->>N: POST /api/shorten {shareId, type, originalUrl} + x-api-key
    N->>DB: Check short_links_index for type+shareId
    alt code exists
        N-->>F: { shortUrl, shortCode }
    else new code
        N->>DB: Create short_links/{code}
        N->>DB: Set short_links_index
        N-->>F: { shortUrl, shortCode }
    end
    F-->>U: Show shortUrl

    U->>N: GET /r/{code}
    N->>DB: Lookup short_links/{code}
    N->>DB: Increment clickCount (async)
    N-->>U: 302 Redirect → /s/{shareId} or /voice/{shareId}

    U->>P: Load /s/{shareId} or /voice/{shareId}
    P->>N: GET /api/shared-notes/{shareId} | /api/voice-notes/{shareId}
    N->>DB: Fetch shared doc
    N-->>P: JSON {title, content/audioUrl, ...}
    P-->>U: Render read-only page
```

## The Code

Now that you understand the flow, let's get into the code. There are two different codebases: the Next.js server and the Flutter application. Before you ask why I used a Next.js server instead of a standard Node.js server or something else, there are three main reasons:

1.  **Next.js is free to host.** Vercel is a beautiful thing.
2.  **MS Bridge needed a website anyway** for hosting the APK, release notes, blog posts, and legal pages like the privacy policy. This keeps everything in one codebase.
3.  I didn't want to pay for a VPS or another server. **Like I said, I'm broke.**

### Flutter Application Code

To avoid repeating code, I created a single service that takes a few parameters and makes the request to the Next.js server.

```dart
class ShortLinkService {
  static const Duration _timeout = Duration(seconds: 8);
  static const int _maxAttempts = 2;

  static String get _baseUrl => config.LinkShortenerConfig.prodBaseUrl;

  static String get _endpoint => config.LinkShortenerConfig.shortenEndpoint;

  static Future generateShortLink({
    required String type, // 'note' | 'voice'
    required String shareId,
    required String originalUrl,
  }) async {
    final Uri url = Uri.parse('$_baseUrl$_endpoint');
    final Map headers = {
      'Content-Type': 'application/json',
      'x-api-key': config.UpdateConfig.msBridgeApiKey,
    };
    final Map payload = {
      'shareId': shareId,
      'type': type,
      'originalUrl': originalUrl,
    };

    int attempt = 0;
    while (attempt < _maxAttempts) {
      attempt += 1;
      try {
        final http.Response res = await http
            .post(url, headers: headers, body: jsonEncode(payload))
            .timeout(_timeout);
        if (res.statusCode == 200) {
          final Object? decoded = jsonDecode(res.body);
          if (decoded is Map && decoded['shortUrl'] is String) {
            return decoded['shortUrl'] as String;
          }
          FlutterBugfender.error('Shorten API: unexpected body ${res.body}');
          return originalUrl;
        }
        FlutterBugfender.error(
            'Shorten API failed: ${res.statusCode} ${res.body}');
      } catch (e) {
        FlutterBugfender.error('Shorten API attempt $attempt failed: $e');
        if (attempt >= _maxAttempts) break;
      }
    }
    return originalUrl;
  }
}
```

#### Code Explanation

This code is pretty simple. It imports the base URL and endpoint from a config file, sets a timeout, and defines a maximum of two retry attempts. It then makes a `POST` request using the `http` package, encoding the payload as JSON.

If the status code is `200`, it decodes the JSON response, grabs the `shortUrl`, and returns it. If there's any error, Bugfender logs it, and the function returns the original URL as a fallback. If the request fails too many times, it breaks the loop and returns the original URL.

Simple and straightforward.

### Note Taking Repo

So, where is this service being called from? I have two repositories in my app: `NoteTakingRepo` and `VoiceTakingRepo`. They handle all the business logic for notes and voice memos, while the UI just renders the output.

```dart
  static String _buildDefaultShareUrl(String shareId) {
    final String base = config.LinkShortenerConfig.prodBaseUrl;
    return '$base/s/$shareId';
  }

  static Future _buildShortLink(String shareId) async {
    return ShortLinkService.generateShortLink(
      type: 'note',
      shareId: shareId,
      originalUrl: _buildDefaultShareUrl(shareId),
    );
  }
```

The code above is from the `NoteTakingRepo`. It just passes the `shareId` (which is the note's ID) to our `ShortLinkService` and returns the short link to the UI so the user can share it.

### Voice Taking Repo

Sharing voice notes is a bit more complex. To be shared, the audio file needs to be stored somewhere accessible via a public URL. Since Firebase Storage is no longer in the free tier, I had to find an alternative.

For that, I integrated a service called **Uploadthing**. It's a great solution for hosting files in the cloud and getting a URL back. When a user wants to share a voice note, the app first uploads the audio file to Uploadthing. The returned URL is then saved in a public document in Firestore. From there, the process is the same: hit the server, generate the short URL, and give it to the user.

```dart
  static const String _shareCollection = 'shared_voice_notes';
  static const String _shareMetaBoxName = 'voice_note_share_meta';
  static bool _isOperationInProgress = false;

  static Future _getShareMetaBox() async {
    return await Hive.openBox(_shareMetaBoxName);
  }

  static String _buildDefaultShareUrl(String shareId) {
    final String base = config.LinkShortenerConfig.prodBaseUrl;
    return '$base/voice/$shareId';
  }

  static Future _buildShortLink(String shareId) async {
    return ShortLinkService.generateShortLink(
      type: 'voice',
      shareId: shareId,
      originalUrl: _buildDefaultShareUrl(shareId),
    );
  }

  static Future enableShare(VoiceNoteModel voiceNote) async {
    if (_isOperationInProgress) {
      FlutterBugfender.error(
          'Voice note share operation already in progress. Please wait.');
      throw Exception(
          'Voice note share operation already in progress. Please wait.');
    }

    if (voiceNote.voiceNoteId == null || voiceNote.voiceNoteId!.isEmpty) {
      throw Exception('Voice note must be saved before sharing.');
    }

    final User? user = FirebaseAuth.instance.currentUser;
    if (user == null) {
      throw Exception('You must be logged in to enable sharing.');
    }

    _isOperationInProgress = true;

    try {
      final FirebaseFirestore firestore = FirebaseFirestore.instance;
      final Box meta = await _getShareMetaBox();
      final UploadThingService uploadService =
          UploadThingService(apiKey: UploadThingConfig.apiKey);

      // Reuse existing shareId if present
      final Map? existing = meta.get(voiceNote.voiceNoteId) as Map?;
      final String shareId = existing != null &&
              existing['shareId'] is String &&
              (existing['shareId'] as String).isNotEmpty
          ? existing['shareId'] as String
          : generateUuid();

      final audioFile = File(voiceNote.audioFilePath);
      if (!await audioFile.exists()) {
        throw Exception('Audio file not found: ${voiceNote.audioFilePath}');
      }

      final String audioUrl = await uploadService.uploadAudioFile(audioFile);

      final String shareUrl = await _buildShortLink(shareId);

      // Create payload for Firebase
      final Map payloadWithoutCreatedAt = {
        'shareId': shareId,
        'voiceNoteId': voiceNote.voiceNoteId,
        'title': voiceNote.voiceNoteTitle,
        'description': voiceNote.description ?? '',
        'audioUrl': audioUrl,
        'duration': voiceNote.durationInSeconds,
        'fileSize': voiceNote.fileSizeInBytes,
        'ownerUid': user.uid,
        'ownerEmail': user.email ?? '',
        'updatedAt': FieldValue.serverTimestamp(),
        'viewOnly': true,
        'shareUrl': shareUrl,
      };

      final Map payloadWithCreatedAt = {
        ...payloadWithoutCreatedAt,
        'createdAt': FieldValue.serverTimestamp(),
      };
      final docRef = firestore.collection(_shareCollection).doc(shareId);
      try {
        await docRef.update(payloadWithoutCreatedAt);
      } on FirebaseException catch (e, s) {
        if (e.code == 'not-found') {
          await docRef.set(payloadWithCreatedAt, SetOptions(merge: true));
        } else {
          FlutterBugfender.error(
              'Failed to update voice note share: ${e.code} ${e.message}');
          FlutterBugfender.sendCrash('enableShare update failed', s.toString());
          rethrow;
        }
      }

      await meta.put(voiceNote.voiceNoteId, {
        'shareId': shareId,
        'enabled': true,
        'shareUrl': shareUrl,
        'title': voiceNote.voiceNoteTitle,
        'audioUrl': audioUrl,
        'updatedAt': DateTime.now().toIso8601String(),
      });

      return shareUrl;
    } finally {
      _isOperationInProgress = false;
    }
  }
```

Here's a diagram to make that flow easier to understand:

```mermaid
sequenceDiagram
    participant User as User
    participant App as App (enableShare)
    participant Hive as Hive MetaBox
    participant Upload as UploadThingService
    participant Firebase as Firestore
    participant Shortener as ShortLinkService

    User->>App: Request to share voice note
    App->>App: Check if operation already in progress
    App->>App: Validate voiceNoteId and user login
    App->>Hive: Get share metadata (getShareMetaBox)
    Hive-->>App: Return existing metadata (if any)

    App->>App: Determine shareId (reuse or generate)
    App->>App: Check audio file existence
    App->>Upload: Upload audio file
    Upload-->>App: Return audioUrl

    App->>Shortener: Build short link
    Shortener-->>App: Return shareUrl

    App->>Firebase: Try update doc with payloadWithoutCreatedAt
    Firebase-->>App: Error (not-found)?
    App->>Firebase: If not-found → set doc with payloadWithCreatedAt

    App->>Hive: Save share metadata locally
    Hive-->>App: Confirm metadata saved

    App-->>User: Return shareUrl
```

Hopefully, this gives you a clear picture of how the app works from a code perspective.

### Next.js Server Code

Now for the server where all the magic happens. Spoiler: it's also pretty simple. There are two main endpoints: one to **generate** a link and another to **redirect** it.

1.  `/api/shorten`
2.  `/r/[code]`

You want to know why I named them like this? I have no idea. I was probably sleep-deprived and just trying to get it done. But hey, it works, and I'm not changing it now. So buzz off.

Here is the code for `/api/shorten`:

```typescript
let app: App;
if (!getApps().length) {
  app = initializeApp({
    credential: cert({
      projectId: process.env.FIREBASE_PROJECT_ID,
      clientEmail: process.env.FIREBASE_CLIENT_EMAIL,
      privateKey: (process.env.FIREBASE_PRIVATE_KEY || "").replace(
        /\\n/g,
        "\n",
      ),
    }),
  });
} else {
  app = getApps()[0]!;
}
const db = getFirestore(app);

type ShortenRequest = {
  shareId: string;
  type: "note" | "voice";
  originalUrl: string;
};

function validateApiKey(apiKey: string | null): boolean {
  const requiredKey = process.env.MS_BRIDGE_API_KEY;
  return !!requiredKey && apiKey === requiredKey;
}

function isValidPayload(body: unknown): body is ShortenRequest {
  if (!body || typeof body !== "object") return false;
  const { shareId, type, originalUrl } = body as Record<string, unknown>;
  return (
    typeof shareId === "string" &&
    !!shareId.trim() &&
    (type === "note" || type === "voice") &&
    typeof originalUrl === "string" &&
    originalUrl.startsWith("http")
  );
}

function generateShortCode(length = 7): string {
  const alphabet = "abcdefghijklmnopqrstuvwxyz0123456789";
  let result = "";
  for (let i = 0; i < length; i++)
    result += alphabet[Math.floor(Math.random() * alphabet.length)];
  return result;
}

  try {
    const apiKey = request.headers.get("x-api-key");
    if (!validateApiKey(apiKey)) {
      return NextResponse.json(
        { error: "Invalid or missing API key" },
        { status: 401 },
      );
    }

    const body = await request.json();
    if (!isValidPayload(body)) {
      return NextResponse.json(
        { error: "Missing or invalid fields" },
        { status: 400 },
      );
    }

    const { shareId, type, originalUrl } = body as ShortenRequest;
    const indexId = `${type}_${shareId}`;
    const indexRef = db.collection("short_links_index").doc(indexId);
    const indexSnap = await indexRef.get();

    let code: string | null = indexSnap.exists
      ? (indexSnap.data()?.code as string | undefined) || null
      : null;

    if (!code) {
      for (let attempts = 0; attempts < 5; attempts++) {
        const candidate = generateShortCode();
        const codeRef = db.collection("short_links").doc(candidate);
        try {
          await codeRef.create({
            shareId,
            type,
            originalUrl,
            clickCount: 0,
            createdAt: new Date(),
          });
          await indexRef.set(
            { code: candidate, shareId, type },
            { merge: true },
          );
          code = candidate;
          break;
        } catch (error) {
          console.error("Error in shorten:", error);
          // Collision or transient error; retry
          if (attempts === 4) {
            return NextResponse.json(
              { error: "Failed to allocate code" },
              { status: 500 },
            );
          }
        }
      }
    }

    const siteUrl = process.env.NEXT_PUBLIC_SITE_URL || "http://localhost:3000";
    return NextResponse.json(
      { shortUrl: `${siteUrl}/r/${code}`, shortCode: code },
      { status: 200 },
    );
  } catch (error) {
    console.error("Error in shorten:", error);
    return NextResponse.json(
      { error: "Internal server error" },
      { status: 500 },
    );
  }
}
```

And here is the code for `/r/[code]`:

```typescript
const firebaseConfig = {
  apiKey: process.env.FIREBASE_API_KEY,
  authDomain: process.env.FIREBASE_AUTH_DOMAIN,
  projectId: process.env.FIREBASE_PROJECT_ID,
  storageBucket: process.env.FIREBASE_STORAGE_BUCKET,
  messagingSenderId: process.env.FIREBASE_MESSAGING_SENDER_ID,
  appId: process.env.FIREBASE_APP_ID,
  measurementId: process.env.FIREBASE_MEASUREMENT_ID,
};

let app;
if (!getApps().length) {
  app = initializeApp(firebaseConfig);
} else {
  app = getApps()[0];
}

const db = getFirestore(app);

  req: NextRequest,
  { params }: { params: Promise<{ code: string }> },
) {
  try {
    const { code } = await params;
    if (!code) {
      return NextResponse.redirect(new URL("/404", req.url), 302);
    }

    const docRef = doc(db, "short_links", code);
    const docSnap = await getDoc(docRef);

    if (!docSnap.exists()) {
      return NextResponse.redirect(new URL("/404", req.url), 302);
    }

    const data = docSnap.data() as {
      shareId: string;
      type: "note" | "voice";
      originalUrl?: string;
    };

    updateDoc(docRef, {
      clickCount: increment(1),
      lastClicked: new Date(),
    }).catch((e) => console.error("Failed to update analytics", e));

    const siteUrl = process.env.NEXT_PUBLIC_SITE_URL || "http://localhost:3000";
    const destination =
      data.type === "voice"
        ? `${siteUrl}/voice/${data.shareId}`
        : `${siteUrl}/s/${data.shareId}`;

    return NextResponse.redirect(destination, 302);
  } catch (error) {
    console.error("Redirect error:", error);
    return NextResponse.redirect("/", 302);
  }
}
```

I split the short-link flow into two simple endpoints.

The **POST** endpoint (protected by an `x-api-key`) validates `{ shareId, type, originalUrl }`, reuses an existing mapping or atomically creates a new 7-char code in `short_links` (with a `short_links_index` entry for idempotency), and returns ``{ shortUrl: `${siteUrl}/r/${code}`, shortCode: code }``.

The **GET /r/[code]** endpoint looks up that code, fires a non-blocking analytics update (`clickCount`, `lastClicked`), and redirects the visitor to either `/voice/{shareId}` or `/s/{shareId}` depending on `type`.

Example short link:

```
https://your-site.com/r/abc1234
```

Simple, secure creation — fast, tracked redirects.

Simple, secure creation—fast, tracked redirects.

## Conclusion

So, there you have it. That's the story of how a deprecated Firebase feature forced me to roll up my sleeves and build my own dynamic link solution from scratch. Was it a pain to debug and migrate everything? Absolutely. But was it worth it? Definitely.

What started as a problem turned into an opportunity. I now have a cost-effective, tailor-made system that I fully own and understand. I don't have to worry about a third-party service changing its pricing or deprecating a feature I depend on. The entire solution runs on a free-tier-friendly stack, which is a huge win for a broke developer like me.

If you're a developer facing a similar situation, I hope this breakdown helps. Sometimes, the best solution isn't one you find, but one you build. It gives you complete control and a much deeper understanding of your own application. And hopefully, by sharing my code and my struggles, I've saved you some of that inevitable debugging headache.

## Thanks for reading!

The code is available on Github:

- 👉 [MSBridge GitHub Repository](https://github.com/rafay99-epic/MSBridge)
- 👉 [MSBridge Website](https://msbridge.rafay99.com)
- 👉 [MS Bridge Website Repo](https://github.com/rafay99-epic/MSBridge-Website)

I'd love to hear your thoughts!

Tell me how I coded, what you liked (or didn't), and how badly I might have messed things up 😄.

---

# Conquering the Update Nightmare: My Flutter Journey to a Robust In-App System

- **URL**: https://www.rafay99.com/blog/flutter-in-app-update-system-ms-bridge-journey/
- **Published**: 2025-09-12
- **Author**: Abdul Rafay
- **Tags**: MobileDevelopment, WebDevelopment
- **Description**: Ever felt the dread of mobile updates? Join me as I recount my personal developer journey building a robust, server-based in-app update system for my Flutter app, MS Bridge. We'll explore the 'why' behind bypassing app store reviews for critical fixes, dive into architectural decisions, wrestle with network gremlins and versioning, and ultimately, conquer the update nightmare for a truly seamless user experience. This is the story of turning a deployment headache into a triumph.

If you're a software engineer, you know about updates. It's the never-ending story. You write one line of _questionable_ code, then you "improve" it, and in doing so, probably introduce two new, more interesting problems. And just like that, you've summed up the entire exhilarating (and often exhausting) process of building and maintaining software. It's a rollercoaster, right?

But let's be real, there's a huge divide here, especially between web and mobile development. If you're entrenched in the web world – building on Vercel, Netlify, Cloudflare Pages, or even just good ol' traditional hosting – updating is, dare I say, **easy**. Merge to main, and poof! Your changes are live, often with sophisticated traffic control. It’s like magic, and frankly, I'm a little jealous.

Then there's the other side of the app fence. The mobile side. The **nightmare**. This is where many Android (and iOS) developers dread the 'update' button. We build an app, release it, and then... well, sometimes we just pretend it doesn't need updates. I've been there. I've built Flutter apps that are probably still rocking version 1.0 because the thought of wrestling with Google and Apple's app store review process feels less like deployment and more like an epic quest only a brave knight (or a very patient QA team) could undertake.

You might be thinking, "But wait, isn't that security-conscious? Why would you want to bypass that channel?" And to that, I'd respond: _you're missing the crucial bit_. Imagine this, and tell me if you've had a similar cold sweat moment: You run an e-commerce app. A critical bug surfaces – let's say, users can somehow apply a **90% discount** to their entire cart. Your heart rate spikes. You fix it in minutes. But then, to deploy that fix, you have to go through the app store review process, which could take a week. A _week_. In that week, your entire business could be hemorrhaging money, your inventory could be wiped out, and you, my friend, could be significantly poorer. This is the massive, capital-F, **F**\*king Problem that Google and Apple, with all their might, haven't quite solved yet.

This gaping chasm is precisely why products like [Shorebird](https://shorebird.dev/) and [React Native's Expo](https://expo.dev/) exist. They're here to save us from this particular flavor of existential dread, allowing us to push critical Dart or JavaScript code changes _while the app is live_, bypassing those lengthy store review queues. While I haven't personally deployed with them, I've watched Shorebird evolve from a young, promising package to an absolutely gorgeous, feature-rich service. The market is screaming for this, and Shorebird is listening!

So, why embark on this wild journey myself? Why not just use Shorebird or Expo? Well, sometimes you need granular control. Sometimes the specific backend requirements don't quite align. And sometimes, just sometimes, you want the sheer, unadulterated thrill (and masochistic pleasure) of building a complex system from scratch. Because let me tell you, it's not easy. There are so many edge cases, so many network gremlins, that trying to fit them all into a single blog post (or even a single app!) feels like trying to herd cats. This wasn't just building a feature; it was a deep dive into mobile deployment philosophy, a battle with unforeseen complexities, and ultimately, a hugely rewarding learning experience.

This isn't for deploying a massive, planet-scale app (for that, you should absolutely consider a dedicated service). This is about the journey of crafting a robust, server-based in-app update _system_ for my Flutter app, MS Bridge. It's a story of battling those gremlins, learning from every stumble, and emerging victorious.

So, grab your favorite energy drink (or calming tea, depending on your update anxiety levels), because we're about to recount how we took that "nightmare" and wrangled it into a custom, reliable solution. Let's begin!

## The Genesis: Why We Needed Our Own Update Knight

For MS Bridge, I needed more than just a standard app store update. I needed control, immediacy for critical fixes, and a system tailored to our specific backend. The idea of users running outdated versions, or worse, encountering a critical bug that couldn't be fixed without a week-long waiting game, just didn't sit right. My goal was ambitious: to forge a **production-ready update system** that could actually _work_ in the messy real world. We needed:

- **Stealthy server checks:** Knowing if our backend was alive without annoying users.
- **Automatic updates:** No user intervention, just a gentle nudge when needed.
- **Background downloads:** Freeing users from staring at progress bars.
- **Graceful handling:** Anticipating and dealing with _all_ the things that could go wrong.
- **A seamless experience:** Updates should feel natural, almost invisible.

This wasn't just a feature; it was a mission to bring web-like agility to a mobile app, albeit with a _lot_ more effort on our end.

## Charting the Course: The Architectural Decisions That Defined Our Journey

Every journey needs a map, and ours was no different. The decisions we made upfront shaped everything, often driven by past frustrations or clear requirements.

### Phase 1: The Invisible Sentinel – Silent Health Checks

```dart
// The silent sentinel: checking if our server is breathing, without anyone knowing.
static Future<bool> isSystemLive() async {
  try {
    final response = await http.get(
      Uri.parse('$_baseUrl/health'),
      headers: {
        'Content-Type': 'application/json',
        'x-api-key': UpdateConfig.msBridgeApiKey, // Our secret handshake
      },
    ).timeout(UpdateConfig.healthCheckTimeout); // We're patient, but not *that* patient.

    return response.statusCode == 200;
  } catch (e) {
    // If it throws, the server's probably asleep.
    return false;
  }
}
```

**The Discovery:** Early on, I realized the first thing we needed was to know if our update server was even _awake_. What's the point of checking for updates if the server is down? But the thought of a "Checking server status..." spinner on every app launch made me shudder. Users hate waiting. So, the decision was made: this check had to be **silent, utterly undetectable**. It became our app's invisible sentinel, a quick `GET /health` on startup. If it responds `200`, great! If not, we gracefully pivot, showing a polite "server unavailable" message instead of crashing the update flow later. This little piece of code became the foundation for a much smoother user experience.

### Phase 2: The Version Philosopher – Client-Side Comparison

```dart
static int _compareVersions(String version1, String version2) {
  try {
    final v1Parts = version1.split('.').map(int.parse).toList();
    final v2Parts = version2.split('.').map(int.parse).toList();

    // This part was crucial: handling versions like 1.0 vs 1.0.0
    while (v1Parts.length < v2Parts.length) {
      v1Parts.add(0);
    }
    while (v2Parts.length < v1Parts.length) {
      v2Parts.add(0);
    }

    for (int i = 0; i < v1Parts.length; i++) {
      if (v1Parts[i] > v2Parts[i]) return 1;
      if (v1Parts[i] < v2Parts[i]) return -1;
    }
    return 0; // The versions are identical
  } catch (e) {
    // Fallback if someone gives us "alpha-beta-gamma"
    return version1.compareTo(version2);
  }
}
```

**The Revelation:** I originally thought, "Just ask the server if there's a new version!" Simple, right? _Wrong._ What if a user had a pre-release internal build that was technically _newer_ than the latest public release the server knew about? Or what if someone used `1.0` and `1.0.0` interchangeably? Suddenly, relying solely on the server felt naive. The revelation was clear: **client-side semantic version comparison** was the way to go. This function became our version philosopher, meticulously comparing each segment. It prevents those awkward moments where the app confidently tells a user, "You need to update!" when they're already on a more advanced build. A true hero in disguise.

### Phase 3: The Freedom Fighter – Background Downloads

```dart
class BackgroundDownloadService {
  static Future<bool> downloadApk(
    BuildContext context,
    AppVersion version, {
    Function(double)? onProgress,
    Function(String)? onStatus,
  }) async {
    // Show an initial notification to signal progress
    await _showDownloadNotification();

    // Dio became our trusted companion for this task
    final response = await _dio!.download(
      downloadUrl,
      filePath,
      onReceiveProgress: (received, total) {
        final progress = received / total;
        _downloadProgress = progress;
        _updateDownloadNotification(progress); // Keeping the user informed
      },
    );

    // Ta-da! Download complete, now go install it.
    await _showCompleteNotification();
  }
}
```

**The Motivation:** We've all been trapped. Stuck staring at an "Updating..." screen, powerless, unable to use the app until it's done. It's user experience hell. My motivation was to free our users from this digital purgatory. I looked at various background downloader packages, but I needed fine-grained control over progress, error states, and, most importantly, notifications. `Dio` emerged as the champion. The decision was to close the update dialog _immediately_ upon user consent and push the download to the background, updating progress _only_ via system notifications. This keeps the app feeling responsive and puts the user firmly back in control. Updates should empower, not imprison!

## The Blueprint: Our System's Inner Workings

After these crucial architectural decisions, the system began to take shape. It wasn't just a jumble of features; it was a cohesive unit, designed to work in concert.

### The A-Team: Core Components

1. **`UpdateService`**: The quiet, diligent worker handling all the backend chatter.
2. **`UpdateManager`**: The brains of the operation, orchestrating the entire update dance.
3. **`BackgroundDownloadService`**: The brawn, handling the heavy lifting of APK downloads.
4. **`EnhancedUpdateDialog`**: Our app's friendly face for update prompts, sleek and on-brand.

### The Flow: Following the Breadcrumbs

To ensure everyone (including my future self) understood the process, I mapped out the data flow. It's simple, elegant, and avoids unnecessary detours.

```mermaid
graph TD
    A[App Launch] --> B[Silent Health Check]
    B --> C{Server Live?}
    C -->|No| D[Show Server Down Dialog]
    C -->|Yes| E[Check for Updates]
    E --> F{Update Available?}
    F -->|No| G[Continue App Launch]
    F -->|Yes| H[Show Update Dialog]
    H --> I[User Clicks Update]
    I --> J[Start Background Download]
    J --> K[Show Progress Notifications]
    K --> L[Download Complete]
    L --> M[Show Install Notification]
```

## In the Trenches: Implementation Details and Hard-Won Lessons

With the blueprint in hand, it was time to get coding. This is where the rubber meets the road, and where I learned that even the most elegant architecture can hide a few surprises.

### Lesson 1: Configuration is King (and sanity-saver)

```dart
class UpdateConfig {
  static const String apiUrl = 'http://192.168.100.146:3000/api'; // My local dev IP – crucial for testing!
  static const String msBridgeApiKey = 'your-api-key-here'; // Please, don't use "your-api-key-here" in prod. Ever.
  static const Duration checkInterval = Duration(hours: 6); // A polite frequency, not nagging
  static const Duration healthCheckTimeout = Duration(seconds: 10);
  static const Duration updateCheckTimeout = Duration(seconds: 15);
}
```

**The Insight:** Centralizing all configuration in one `UpdateConfig` class might seem trivial, but it was a lifesaver. API URLs, keys, and especially those critical network timeouts lived here. It made switching between dev and prod a breeze and ensured consistent behavior across the app. A single source of truth for all update-related settings saved me from chasing down stray values in different files.

### Lesson 2: API Keys - Our Digital Passports

```dart
final headers = {
  'Content-Type': 'application/json',
  'x-api-key': UpdateConfig.msBridgeApiKey, // Gotta show the bouncer the right credentials
};
```

**The Realization:** Security isn't an afterthought; it's baked in. Every request to our update server had to be authenticated. Using `x-api-key` in the headers was a simple, effective way to ensure only our authorized app could talk to our server. It's like giving our app a digital passport – no passport, no entry. This centralized approach made future key rotation much simpler too.

### Lesson 3: Error Handling - Embracing the Chaos

```dart
if (response.statusCode == 200) {
  return UpdateCheckResult.fromJson(data);
} else {
  // Bugfender became my best friend here. Log EVERYTHING.
  FlutterBugfender.error('Update check failed with status: ${response.statusCode}');
  FlutterBugfender.error('Response body: ${response.body}');
  throw Exception('Update check failed with status: ${response.statusCode}'); // Still useful for immediate debug
}
```

**The Acceptance:** Things _will_ go wrong. Network hiccups, server errors, cosmic rays – you name it. Accepting this was the first step. My strategy was multi-pronged: comprehensive logging with tools like Bugfender (seriously, it's invaluable for production debugging), graceful fallbacks (don't crash the app, just inform the user), and user-friendly messages. Instead of exposing raw HTTP status codes, we translated them into something understandable. It’s about managing expectations and being empathetic to the user's plight.

## The War Stories: Tackling Those Pesky Edge Cases

This is where the true "journey" emerges – the frustrating, memorable moments when the update system decided to throw a curveball. Each one was a puzzle to solve, a lesson learned.

### The Overachiever Client: "I'm already updated!"

**The Challenge:** My own client test builds would sometimes be newer than what the server thought was the "latest." This led to confusing update prompts.
**The Fix:** That client-side semantic version comparison (`_compareVersions`) became crucial.

```dart
if (versionComparison > 0) { // If client's version is greater than server's latest
  updateAvailable = false;
  message = 'You have a newer version (${currentVersion.version}) than what\'s available on the server (${latestVersion.version}). You\'re up to date!';
}
```

It meant we could politely inform the user, "Hey, you're actually ahead of the curve!" instead of nagging them to "update" to an older version. Phew.

### The Mute Server: "Is anyone home?"

**The Challenge:** What if the server was just... gone? The health check was a start, but if the update check failed, we needed a clear path.
**The Fix:** Promptly inform the user and give them an out.

```dart
if (!isLive) { // Our silent sentinel reported back: no signs of life.
  _showServerDownDialog(context, () {
    SystemNavigator.pop(); // Sometimes, you just gotta gracefully exit.
  });
  return;
}
```

This avoids indefinite loading and frustration. A clear message, a graceful exit.

### The Phantom Connection: Network Timeouts

**The Challenge:** Network requests could hang indefinitely on a flaky connection.
**The Fix:** Explicit timeouts on _all_ network calls.

```dart
.timeout(UpdateConfig.healthCheckTimeout) // No staring contest with the router
```

No user wants to wait forever. Sensible timeouts prevent the app from freezing up, giving us control over the user experience even when the network is having a bad day.

### The Broken Download: When Bits Go Bad

**The Challenge:** Downloads aren't foolproof. They can fail mid-way.
**The Fix:** Robust error handling around the `Dio` download.

```dart
try {
  final success = await BackgroundDownloadService.downloadApk(context, version);
  if (!success) {
    CustomSnackBar.show(context, 'Download failed. Please try again.', isSuccess: false);
  }
} catch (e) {
  FlutterBugfender.error('Download error: $e'); // Log and inform!
}
```

When bits go bad, we log the details and provide a user-friendly message, giving them the option to retry. No one likes a mystery error.

### The Localhost Identity Crisis: "Who am I, really?"

**The Challenge:** Testing on a physical device connected to my dev machine. The app would try to download from `localhost:3000`, but `localhost` on the device isn't _my_ `localhost`. Facepalm moment.
**The Fix:** A quick client-side rewrite for dev.

```dart
// This little hack saved countless testing headaches.
String downloadUrl = version.downloadUrl;
if (downloadUrl.contains('localhost') || downloadUrl.contains('127.0.0.1')) {
  downloadUrl = downloadUrl.replaceAll('localhost', '192.168.100.146'); // My dev machine's actual IP
  downloadUrl = downloadUrl.replaceAll('127.0.0.1', '192.168.100.146');
}
```

This tiny bit of code bridged the gap between emulator/device and my development server, making testing immensely smoother. It’s the kind of specific problem only a dev in the trenches would truly appreciate.

## User Experience: The Invisible Touch

My guiding principle was simple: users shouldn't have to _think_ about updates. They should flow.

- **App Launch (Silent):** Ninja mode activated. Health check in the background. No spinners. Smooth as silk.
- **Update Available:** A polite, themed dialog. Clear version info, a simple changelog. One-click update. No confusing options.
- **Background Download:** Dialog gone. App usable. Progress in the notification shade. Done? Install prompt appears. Freedom!
- **Error Scenarios:** Clear, empathetic messages. No tech jargon. Just helpful guidance.

## Notifications: Our Friendly Digital Messengers

Notifications were critical for the background download – keeping users informed, not interrupted.

### The Progress Whisperer

```dart
final androidDetails = AndroidNotificationDetails(
  'download_channel',
  'Downloading Update',
  channelDescription: 'Shows download progress',
  importance: Importance.high,
  priority: Priority.high,
  autoCancel: false, // Keep it active until done
  icon: '@mipmap/launcher_icon', // Our actual app icon, not a default!
  showProgress: true,
  maxProgress: 100,
  progress: (progress * 100).round(),
);
```

This kept the user gently updated in the notification shade, without demanding their full attention. The branded icon? A small detail, but a huge win for professionalism.

### The Completion Signal

```dart
final androidDetails = AndroidNotificationDetails(
  'download_channel',
  'Download Complete',
  channelDescription: 'Shows when download is complete',
  importance: Importance.high,
  priority: Priority.high,
  autoCancel: true,
  icon: '@mipmap/launcher_icon',
  playSound: true,
  enableVibration: true,
  actions: [
    const AndroidNotificationAction(
      'install',
      'Install',
      showsUserInterface: true, // Crucial for launching the installer
    ),
  ],
);
```

Once complete, a clear notification with an immediate "Install" action. Simple, direct, effective.

## What This Journey Taught Me: The Hard-Won Wisdom

This whole endeavor wasn't just about building an update system; it was a masterclass in mobile development, problem-solving, and user empathy.

1. **User Experience is the Ultimate Metric:** If users hate your update process, they won't update. Make it invisible, make it seamless, make it _easy_.
2. **Edge Cases are the Real Bosses:** The happy path is easy. The true robustness comes from anticipating every weird scenario and having a plan for it. Each edge case felt like finding a secret boss battle.
3. **Log, Log, Log (but Wisely):** When things break in production, good logs are your only friends. Bugfender became invaluable.
4. **Security is Non-Negotiable:** From API keys to HTTPS, assume malicious intent and build defenses.
5. **Testing is Not a Phase, It's a Lifestyle:** You can't just deploy and pray. Manual testing, network testing, error injection – it's all part of the rigorous dance.

Looking back, the satisfaction of building this from the ground up for MS Bridge is immense. It took about **2-3 days** of focused effort, resulted in around **1,500+ lines of code** across **8 key files**, and tackled **over 10 significant edge cases**. It was a wild ride, but one that left me with a deeper understanding of what it takes to truly own the mobile update experience.

This wasn't just a project; it was a journey through the "update nightmare," and we emerged with a robust, custom solution. And for any of you out there contemplating your own update journey, remember: it's challenging, it's enlightening, and ultimately, it's incredibly rewarding. Now, go build something awesome!

---

# From YOLO to 'I Know!': Master Production Error Logging as a Solo Dev (BugFender & Axiom)

- **URL**: https://www.rafay99.com/blog/solo-dev-production-error-logging-bugfender-axiom/
- **Published**: 2025-09-01
- **Author**: Abdul Rafay
- **Tags**: MobileDevelopment, ThoughtsProcess, WebDevelopment
- **Description**: My ways of error logging

Ah, not so long ago, I was a fresh-faced dev, happily crafting simple applications for a grand total of one or two users. Sound familiar? Because honestly, we all kick off our journeys right there.

From late-night university projects to personal passion projects, devouring cool new tech – that's often our classroom. And if that's not how you're learning, then I've got to ask: how are you doing it?

My own learning curve? It's been a winding road, complete with a plot twist that, frankly, stung a bit. But that 'sad part' delivered such a profound lesson that now, every time I write a line of code, I make a silent vow: never again will I make that same mistake.

In just a few short years, the difference is night and day. I've grown by leaps and bounds, even if I'm still occasionally shipping code that makes me chuckle with a touch of self-deprecating irony. But hey, that's the beautiful, messy reality of a developer's life, isn't it?

Enough reflection, though! You didn't come here for a stroll down memory lane. You're here for the good stuff, the vital stuff: the art and science of error logging and error handling.

## The Development Process: From Local Logs to Production Headaches

When you're knee-deep in building an application or website, your trusty `console.log()` statements or print functions are your best friends. You're diving into `try-catch` blocks, meticulously handling errors, and ensuring everything looks just right. Then, development wraps up, you hit that `build` button, and deploy your code, crossing your fingers and hoping for the best in the **production environment**.

But here’s the harsh reality: even after all your rigorous testing, production is a different beast. There are always **edge cases** you simply couldn't foresee, especially as a solo developer juggling everything from writing clean code and robust tests to perfecting UI and ensuring core functionality. You validate your app, then unleash it into the wild, only to find users are… well, _users_. They'll click, swipe, and interact in ways so outlandish you'll often scratch your head, wondering, "Why on earth would they do that?!"

And yet, that's precisely what users do. The real challenge emerges: how do you identify those unpredictable flows and track these novel **application errors** when your app is running live? You can't just open a console and watch the logs stream by. So, what's a developer to do?

It's a solid question. Most solo devs, myself included once upon a time, would often go full **YOLO** mode. And honestly? I'm almost proud to admit I've been there.

But going `no logger`... that’s where the real trouble begins.
Okay, Abdul Rafay, let's dive into the solution space with that signature "been there, done that" vibe! You've navigated the often-treacherous waters of finding the right tools, and that's a story worth telling.

## Unlocking Robust Error Logging: Beyond the "Painful" Enterprise Tools

After wrestling with these **production challenges**, a thought gnawed at me: "What _can_ I do?" A deep dive into Google's rabbit hole quickly surfaced a plethora of **error logging solutions**. Many of these tools, while offering a tempting **free tier**, often felt like a labyrinth to set up in my codebase. They came with frustrating limits, seemed to break at the most inconvenient times, and integrating them genuinely felt like a massive pain.

Seriously, try Googling for logging tools. You'll be swamped with sponsored content for what are essentially **enterprise-grade monitoring platforms**. Don't get me wrong, these behemoths are fantastic for large teams and complex systems, but as a solo developer? I don't need that much firepower, nor do I want the hefty price tag that usually comes with it. My focus is on efficient **application performance monitoring** and reliable **crash reporting**, not an entire suite of features I'll never touch. When that level of power _is_ needed, I'll happily upgrade, but for now, it's overkill.

So, after all that sifting, I stumbled upon two tools that truly clicked. And before you jump to conclusions – _no, this isn't a sponsored ad!_ I genuinely wish it were, because these tools have been absolute game-changers in my projects. They've made my **developer workflow** so much smoother.

Why the praise? They're incredibly easy to configure and provide remarkably detailed insights – not just during **development**, but critically, in **production** as well. They've transformed how I approach **debugging** and **identifying application errors** live.

I'm talking about:

- **Axiom Logging**
- **BugFender**

Both offer generous free tiers that, while having their limits, provide an amazing amount of information for **real-time logs**, **crash analytics**, and just about everything in between. Trust me, integrating them for comprehensive **error tracking** is a breeze, and I'm excited to show you exactly how to code them into your projects and where they shine brightest!

## BugFender: My Go-To for Robust Mobile Error Tracking (Android & iOS)

When it comes to **mobile app development** for both Android and iOS, especially for **production monitoring**, BugFender has become my secret weapon. It’s funny how I found this tool by accident, created an account, but initially, I wasn't fully committed. At the time, I was deeply entrenched with **Firebase Crashlytics** for all my **error recording** and **crash reporting** needs.

Now, don’t get me wrong, Firebase tools are mature and provide a lot of information. The rub, however, was that the data often felt disorganized. I struggled to quickly pinpoint crucial device details, specific Android versions, or other vital context for **debugging production issues**. Maybe the information _was_ there, but in my experience, it wasn't presented in a way that made my life easier as a busy solo dev.

But then came the turning point: I had created an account and, honestly, promptly forgot about it for a week. To my surprise, BugFender's support team actually reached out, genuinely asking why I hadn't started using their service. That personal touch was a game-changer!

At that exact moment, I was deep into developing MS Bridge, my personal, feature-rich note-taking and note-reading application. It's grown into a massive codebase, evolving from a simple reader to a truly complex application, and I'm constantly layering on new features.

Given the scale, manually ripping out all of Firebase's crash reporting would have been a rough undertaking. So, with a bit of trepidation, I opted to install BugFender’s SDK. And you know what? It was surprisingly easy, even with my Flutter-based mobile application.

The instructions for **Flutter logging** were incredibly straightforward:

First, add the package:

```bash
flutter pub add flutter_bugfender
```

Then, in your `main.dart` file, just drop in this concise initialization code:

```dart
import 'package:flutter_bugfender/flutter_bugfender.dart';
import 'package:flutter/material.dart'; // Assuming MyApp needs this

void main() {
  FlutterBugfender.handleUncaughtErrors(() async {
    await FlutterBugfender.init("YOUR_APP_KEY",
        enableCrashReporting: true, // these are optional, but recommended
        enableUIEventLogging: true,
        enableAndroidLogcatLogging: true);
    FlutterBugfender.log("hello world!");
    runApp(new MyApp());
  });
}
```

_Just remember to import the package, and you’re essentially set!_ This simple setup means your application is now using robust **real-time logging** and **crash analytics**.

The tool offers a comprehensive suite of logging options, allowing for highly granular **error tracking** (as per their documentation):

```dart
// Comprehensive logging capabilities
FlutterBugfender.log("Working fine!");
FlutterBugfender.fatal("Fatal sent!");
FlutterBugfender.error("Error sent!");
FlutterBugfender.warn("Warning sent!");
FlutterBugfender.info("Info sent!");
FlutterBugfender.debug("Debug sent!");
FlutterBugfender.trace("Trace sent!");
FlutterBugfender.sendLog(
 line: 42,
 method: "someMethod()",
 file:"someFile",
 level: LogLevel.info,
 tag: "Custom tag",
 text: "This is a custom log"
);
// Device-specific context
FlutterBugfender.setDeviceString("user.email", "example@example.com");
FlutterBugfender.setDeviceInt("user.id", 32);
FlutterBugfender.setDeviceFloat("user.pi", 3.14);
FlutterBugfender.setDeviceBool("user.enabled", true);
FlutterBugfender.removeDeviceKey("user.pi");
// Advanced reporting
FlutterBugfender.sendCrash("Test Crash", "Stacktrace here!");
FlutterBugfender.sendIssue("Test Issue", "Issue value goes here!");
FlutterBugfender.sendUserFeedback("Test user feedback", "User feedback details here!");
// Control and utility
FlutterBugfender.setForceEnabled(true);
FlutterBugfender.forceSendOnce();
FlutterBugfender.getDeviceUri());
FlutterBugfender.getSessionUri());
FlutterBugfender.getUserFeedback()); // Show a screen which asks for feedback
```

For me, the most crucial functions that I constantly rely on are:

- `FlutterBugfender.error()`: For recording specific error conditions.
- `FlutterBugfender.log()`: My standard for general event logging and understanding **user behavior**.
- `FlutterBugfender.sendCrash()`: To push instant **crash reports** directly to the dashboard.

These functions are invaluable for quickly printing logs, sending detailed crash data to the dashboard, and comprehensively recording all errors occurring within the application. And the dashboard? It's simply _good_. Clean, intuitive, and it provides all the contextual information a developer needs to make informed decisions. It gives you the precise stats and **actionable insights** so you can jump straight into fixing bugs, instead of wasting precious time trying to decipher what a user _might_ have been doing.

While there are many other features to explore, I haven't delved into them all just yet. But give me time! For now, I highly recommend exploring this incredibly useful, and yes, **free**, tool for your **mobile app debugging** needs.

## Axiom: Taming the Web Development Wild West (Especially Next.js!)

Now, let's pivot to the **web technology** side of things. Yes, I know Flutter for Web exists, and sure, you _could_ technically deploy BugFender there. But while Flutter is a powerhouse for mobile, I find its web output, while improving, still sometimes lacks the nuanced polish and native feel I demand for a truly stellar website.

For my **web application development**, I'm firmly in the React camp. For those quick, snappy demos and prototypes, **Vite** is my go-to for its blazing-fast development experience. But when things get serious – think complex blog posts with dynamic content, cool animations, intricate UI changes, or just about anything else that pushes the boundaries – that's when **Next.js** truly shines. Its **serverless** capabilities give me the power to pull off some genuinely crazy, innovative stuff.

A quick heads-up, though: with great power comes great complexity. Next.js can get _very_ intricate _very_ fast, and if not architected correctly, it can become a nightmare. Trust me, I've got the scars to prove it! If you're curious about the 'trouble' I got myself into with a **scaling cache nightmare**, you can dive into that saga in my previous blog post: [how I get into a truble](https://www.rafay99.com/blog/convex-scaling-cache-nightmare).

### Enter Axiom: Your Full-Stack Web Logging Champion

So, after all those lessons, when it came to **logging and sending data** from my **Next.js application**, I landed on **Axiom**. For **real-time logs** and **full-stack error tracking**, it's an absolute game-changer. Seriously, it's incredibly easy to set up and immediately starts giving you valuable insights. The beauty of it is that once imported, it effectively blankets your entire site, capturing all the activity you need.

Setting it up is surprisingly straightforward. First, install the necessary packages:

```bash
npm install --save @axiomhq/js @axiomhq/logging @axiomhq/nextjs @axiomhq/react
```

Next, create a simple `axiom.ts` file anywhere in your codebase (I usually put it in a `lib` or `config` folder) with your client initialization:

```typescript
// lib/axiom/axiom.ts (or wherever you prefer)
const axiomClient = new Axiom({
  token: process.env.NEXT_PUBLIC_AXIOM_TOKEN!,
});

```

Then, for robust **server-side logging** in Next.js – which is crucial because Next.js handles both client and server code – create another file, say `server.ts`, and paste this configuration:

```typescript
// lib/axiom/server.ts
// Adjust path if needed

  transports: [
    new AxiomJSTransport({
      axiom: axiomClient,
      dataset: process.env.NEXT_PUBLIC_AXIOM_DATASET!,
    }),
  ],
  formatters: nextJsFormatters,
});

```

Now, you can simply call these logger instances for your **frontend logging** and **backend logging**, and you’re good to go! Remember, Next.js isn't just a simple client-side application like a basic Vite React app; it cleverly blends server-side rendering (SSR), static site generation (SSG), and client-side execution. This dual nature means you need distinct, yet integrated, ways to log activity from both parts of your application.

> **A Quick Heads-Up:** My code snippets here are based on my current setup, but the world of **web development best practices** and SDKs evolves rapidly. Always consult the official [Axiom Next.js documentation](https://axiom.co/docs/send-data/nextjs) for the most up-to-date and accurate setup instructions for your project.

Once everything's wired up in your code, configuring the Axiom dashboard is surprisingly intuitive. You select your data source, deploy your app, and it often auto-detects, streaming all your activity and **error analytics** directly to a centralized place.

For context, this is what my Axiom dashboard looks like, monitoring my Next.js backend with Convex:

![Axiom Dashboard for Next.js Backend Convex](https://utfs.io/f/TViMykBJnLIJa2yzoEYBp5JiSOCKTuNXvRtgsPFjD1ZrWY2Q "Axiom Dashboard")

This is where Axiom truly shines! You can use it across your entire **full-stack application**, with independent logging for both your frontend and backend. Everything gets logged, from general activity to critical crashes. It’s **simple, clean, and makes setup a breeze**.

What I particularly love is the flexibility: if your cloud provider supports Axiom integration, you can often consolidate all your default logs directly into Axiom. The ability to see _everything_ – **distributed tracing**, **API logging**, user-triggered events – in a single, unified place is just awesome for **production debugging** and improving my overall **developer workflow**. I genuinely love this tool!

### Why Axiom Over BugFender for Next.js?

It's important to clarify one point: while BugFender is fantastic for **client-side application logging** (and works great for React apps built with Vite, which are typically single-page applications), it doesn't have robust support for Next.js's server-side aspects. I've tried this before while drafting this very post; BugFender's focus on the client-side would lead to significant gaps in a Next.js environment, where so much critical logic often runs on the server. Next.js is fundamentally different from a purely client-side SPA, and Axiom fills that server-side logging void perfectly.

## Your Debugging Superpower: From "YOLO" to "I Know!"

So, there you have it. My journey from the wild, wild west of "YOLO" deployments, praying nothing broke in **production**, to a far more serene and _informed_ state. We've all been there, pushing code and then bracing ourselves for those inexplicable **user-generated errors**. But with robust **error logging** and **crash reporting** in place, those days are largely behind me.

Whether it's the intuitive insights of BugFender for my **Flutter mobile applications** or the comprehensive **full-stack logging** Axiom provides for my **Next.js web projects**, these tools have truly transformed my **developer workflow**. They aren't just about catching bugs; they're about understanding the nuanced dance between your code and your users, pinpointing those elusive **edge cases**, and ultimately, building more resilient and user-friendly applications.

Remember that vow I made at the start? "I never make the same mistake today." With these tools, that mantra isn't just a hopeful whisper; it's a tangible reality. They empower you to stop playing detective in the dark and start making data-driven decisions. You gain a clearer picture of **application performance**, faster **debugging** cycles, and more time focusing on what we love most: building awesome features.

So, if you're a solo dev tired of guesswork, take my advice. Dive into BugFender for your mobile apps and explore Axiom for your web projects. They offer generous free tiers and, more importantly, they offer sanity. Your future self, your codebase, and most importantly, your users, will absolutely thank you. Go forth, log wisely, and build something incredible!

---

# Beyond the Hype: My Honest Review of GPT-5 in Real-World Flutter Development

- **URL**: https://www.rafay99.com/blog/beyond-the-hype-my-honest-review-of-gpt-5-in-real-world-flutter-development/
- **Published**: 2025-08-18
- **Author**: Abdul Rafay
- **Tags**: AI, ThoughtsProcess
- **Description**: "Weeks of buzz, big promises, but did GPT-5 truly revolutionize my coding workflow? I spent 50 intensive hours leveraging GPT-5 and Cursor to resurrect an old Flutter project (MS Bridge), fix stubborn bugs, and integrate a host of new features. Dive into my candid experience to see if OpenAI's latest model lives up to the 'game-changer' claims for software engineers."

Remember the fever pitch, the whispers, the sheer _anticipation_ leading up to the GPT-5 launch? For what felt like ages, OpenAI seemed to be playing catch-up, then suddenly, the internet exploded with news of GPT-5, promising a monumental leap forward. Like many, my ears were glued, my developer senses tingling. This _had_ to be the one, right? The massive, paradigm-shifting change we’d all been waiting for.

Well, after spending nearly 50 intense hours putting GPT-5 through its paces on a real-world project, I'm here to spill the beans. And let's just say, the reality check was…interesting.

### The Buzz vs. The Reality: Is GPT-5 _Really_ Different?

Initial thoughts? It looked amazing, just as we all hoped. But then, the honeymoon phase ended. After extensively using GPT-5 with various tools and workflows, I have to be honest: it doesn't _feel_ like the massive change OpenAI proclaimed. It feels, dare I say it, a lot like GPT-4.

Sure, it brings some undeniable improvements to the table:

1. **More Context Window:** Definitely a plus for those longer coding sessions or complex problem-solving.
2. **Better Tool Calling:** Smoother integrations and more reliable execution of external functions.
3. **Smarter Decisions:** In some scenarios, it seems to grasp nuances better, leading to slightly more intelligent code suggestions.

But are these incremental upgrades enough to warrant the "massive change" rhetoric? For me, as a developer working to ship features, the answer leaned towards a resounding "not quite."

### The Unfinished Business: Resurrecting MS Bridge with GPT-5

Feeling a bit underwhelmed by the "next big thing," I decided to put GPT-5 to the ultimate test: breathing new life into an old Flutter project of mine, **MS Bridge**. This app had been sidelined due to a nasty combination of Flutter version woes, stubborn build issues, and general machine-related gremlins. It was the perfect guinea pig for GPT-5's supposed prowess in debugging and feature implementation.

My goal? Vibe code most of the application's features, making sure things worked better, and seeing if GPT-5 could truly accelerate the prototyping phase.

I started with the new **Cursor Agent CLI**, which, by default, runs the GPT-5 model. My first hurdle, a familiar nemesis: getting the project to _run_. I knew it was Flutter 3.22.2, but Java versions, build paths, and a host of other cryptic errors were causing endless headaches. Off the bat, GPT-5's CLI agent struggled. It kept running into the same issues, again and again, until I had to step in, manually install Java 17, and configure the project path. **Lesson one:** Even with GPT-5, fundamental environment setup still needs a human touch.

### Bug Squashing & Feature Frenzy: A Mixed Bag

With the project finally running, I dove into fixing some long-standing bugs in the MS Bridge Note-Taking Editor (if you’re curious about MS Bridge, check out my previous blog post!). The main culprits were:

1. **AI Summary Not Working:** A crucial feature for quick insights into notes.
2. **Auto-Save Triplicate:** New notes would mysteriously create three identical copies.
3. **Blog Search Breakdown:** The search functionality for blog entries was stubbornly broken.

I set about fixing these with GPT-5's assistance. Initially, I found its understanding of my small, well-divided file structure a bit...fragmented. It would often fail to identify dependencies between files and make assumptions that led to frustrating dead ends. Let's just say, my patience was tested!

Switching from the Cursor CLI to **Cursor with the GPT-5 Model** (the desktop application interface) definitely improved things. The context window felt much larger, losing its "memory" less frequently. However, even with the expanded context, it still had a peculiar habit: any feature it attempted to implement often defaulted to a overly complex solution, requiring extensive back-and-forth and detailed explanations from my end to simplify the approach.

Despite these quirks, I pushed ahead, adding a torrent of new features to MS Bridge:

- **A Pin-based Lock Screen:** Replacing a finicky fingerprint lock.
- **New MS Notes Reading Screen:** A cleaner, more intuitive interface.
- **Better HTML Render Options:** Enhanced display of rich content.
- **A New Search Screen:** Overhauling the broken search.
- **A New AI Chatbot:** With access to both personal and MS Notes – a truly cool, context-aware AI.
- **New Layout Options in Note-Taking:** More flexibility for users.
- **Tags and Folder View:** Essential organization features.
- **A Brand New Settings UI:** With a lot of bug fixes and UI polish.
- **Streak Notifications:** Gamifying daily usage.
- **Push and Pull Sync Level:** Robust data synchronization.
- **User Option to Disable/Enable Cloud Sync:** Firebase or other cloud options for privacy and control.

### The Pain Points: Where AI Still Needs a Hand

While many of these features were surprisingly straightforward to implement with AI assistance, some were, frankly, a massive pain. The **Auto-Pin and Lock System** was a nightmare to get working reliably – it ate up so much time. Migrating the entire **Settings Panel** from one design paradigm to another was similarly taxing. If a screen had too many elements, GPT-5 would often add some but miss others, or break the existing UI in the process (e.g., moving the "Appearance" section from a full screen to a bottom sheet caused chaos).

The **Folder and Tag features** were smoothly divided in terms of logic, but the UI for them required extensive manual tweaking, proving that aesthetic design and user experience nuances are still firmly in the human domain.

### The Verdict: 50 Hours In, Is GPT-5 a Game Changer?

After investing approximately 48 to 50 hours of intensive development using GPT-5-powered tools, my honest take is this: **it’s an average model for practical feature development.**

Don't get me wrong, it _is_ better than GPT-4 in some aspects, and its performance might be on par with or slightly better than models like Claude in certain benchmarks. But for my specific use case – rapidly adding new features to an existing application – I found myself asking: "Could I have achieved the same results, in roughly the same timeframe, with GPT-4 or even Claude?" The answer is often, "Yes." These models (including GPT-5) are fantastic for quick prototyping and validating ideas, but they haven't eliminated the need for a deep understanding of code, architecture, and, crucially, relentless debugging.

Nothing I built felt "fancy" or exclusively possible because of GPT-5. The features, while enhancing user experience, were standard additions. My benchmark isn't abstract metrics; it's tangible feature delivery. And on that front, GPT-5 delivers incrementally, not exponentially.

The hype machine for "GPT-5" was colossal, and perhaps my expectations were unfairly high. While others focus on benchmarks and formatting, my real-world test focused on how effectively it integrates into my day-to-day as a full-stack engineer, student, and researcher.

So, where do we go from here? AI models are undeniably powerful tools, making us more efficient. But as a developer, I still find myself leading the charge, defining the intricate logic, and ultimately, being the one to connect the dots and wrestle with those truly stubborn bugs. GPT-5 is a powerful co-pilot, but for now, the human pilot is still firmly in control.

I'm curious to hear your thoughts! Have you had a similar experience with GPT-5 or other advanced AI models in your projects? Share your insights in the comments below!

---

# When the Terminal Becomes Your Pair Programmer — My Experience with Cursor CLI and GPT‑5

- **URL**: https://www.rafay99.com/blog/cursor-cli-gpt5-python-local-first-app/
- **Published**: 2025-08-09
- **Author**: Abdul Rafay
- **Tags**: AI, ThoughtsProcess
- **Description**: In this hands-on review, I put Cursor CLI and GPT‑5 to the test on a real Convex-based Python project. See how AI-powered terminal coding helped me refactor the UI, add charts, enable PDF exports, and build a multi-window local-first app — all without touching the cloud.

There’s a certain kind of magic when your terminal stops being a passive black box and starts actively helping you write, refactor, and commit code.\
With the release of **GPT‑5** from OpenAI, we’ve seen a wave of AI-powered developer tools getting major updates — **Google Gemini CLI**, **Claude Code**, **OpenCLI**, **Warp Terminal** — and now **Cursor CLI** has joined the league.

I’ve been seeing Cursor CLI pop up all over Twitter, and I’ll admit, I wasn’t sure if it was just another AI gimmick. But curiosity won. I decided to test it on a **real project** my team will actually use in production.

## The Problem I Wanted to Solve

I have a **Convex**-based project, but I don’t want to rely on cloud-based operations for certain lookups. Too many dependencies, too many ways for things to break.

Instead, I wanted a **local-first Python application** where I could:

1. **Load a Data Folder** (local dataset)
2. **Enter a User Email or User ID**
3. **Display the User Data**, including:
   - User Information
   - Ranking
   - Referral Points History
   - Application Tracking Progress

The goal was a **simple, clean, and reliable process** — no cloud calls, no external dependencies that could fail at the wrong time.

## The Terminal Setup

For this coding session, I went **full vibe mode** — running **Cursor CLI** inside **Warp Terminal** with the **GPT‑5 model**.\
No IDE, no VS Code, just me, the terminal, and an AI that could read, modify, and commit code.

To be safe, I created a **new branch**. If things went sideways, I could revert to `main` and pretend nothing happened.

![Warp Terminal running Cursor CLI](https://utfs.io/f/TViMykBJnLIJifclviHm04c8pb2PCWMuNRxzyw39BeGHY1I7)

## The Original Limitation

The application worked, but the **Profile View** section’s _Referral History_ was just plain text. It was functional, but not exactly user-friendly.

I wanted to:

- Make the data **readable and visually appealing**
- Add **tables, charts, and modern UI styling**
- Keep everything **local and lightweight**

## What I Added During the Session

With Cursor CLI acting as my AI pair programmer, here’s what I implemented:

1. **Database Memory** — The app now remembers the last loaded dataset for faster reloads.
2. **Upload Dataset** — Added a clean interface for importing new datasets.
3. **Reset Old Dataset** — One-click reset to clear previous data.
4. **New User Profile Creation** — Ability to add new users directly from the app.
5. **PDF Export Support** — Export user profiles, rankings, and history as PDF reports.
6. **Multiple Window Support** — Open different sections of the app in separate windows.
7. **Build Scripts for Mac and Windows** — Easy packaging for cross-platform distribution.
8. **App Bar with Exit and About Section** — A proper application feel with navigation and info.

## How Cursor CLI + GPT‑5 Helped

Here’s where Cursor CLI really impressed me:

- **Understanding the Codebase** — It scanned my `data_loader.py` and `utils.py` to understand how history entries were structured before making changes.
- **UI Overhaul** — It replaced raw text with **sortable tables**, **charts**, and **color-coded highlights**.
- **Error Prevention** — It compiled the Python files to check for syntax errors before committing.
- **Clean Commits** — It staged only the relevant changes and wrote clear, professional commit messages.

Example commit message it generated:

> Profile: Replace plain text history with tables, charts, and details. Introduce sortable tables and visualizations for Referral History, Points History, Mini Game Progress, and Wake-up Pings.

## The Experience

Using Cursor CLI felt less like using an autocomplete tool and more like **pair programming with a junior developer who’s fast, careful, and occasionally paranoid**.

At one point, it asked:

> "Run this command? Not in allowlist: python"

It’s like having a teammate who says, _"I can run it for you… but only if you promise it won’t blow up the server."_

## Why This Matters

For developers working on **local-first applications**, **data visualization tools**, or **internal utilities**, AI-powered CLI tools like Cursor CLI can:

- Speed up UI improvements
- Automate repetitive coding tasks
- Keep commits clean and organized
- Reduce the risk of introducing errors during refactors

## Final Thoughts

This wasn’t just AI writing code — it was **AI collaborating on a real feature set**.\
In one session, I went from a functional but plain Python app to a **multi-window, export-capable, visually polished tool** ready for my team to use.

Would I trust Cursor CLI with my entire production codebase? Not yet.\
Would I use it for **feature branches, rapid prototyping, and UI overhauls**? Absolutely.

**SEO Keywords:** Cursor CLI, GPT‑5 coding, AI pair programming, Python local data app, Convex database, AI coding tools, AI terminal tools, AI-assisted development, Python UI refactor, PDF

---

# GPT-5 in the Real World: Fixing Bugs, Building Apps, and Automating Workflows

- **URL**: https://www.rafay99.com/blog/real-world-gpt5-review/
- **Published**: 2025-08-08
- **Author**: Abdul Rafay
- **Tags**: AI, ThoughtsProcess
- **Description**: GPT-5 is finally here, and I’ve been putting it through its paces—from fixing Google Tag Manager issues to designing UI, building a Jetpack Joyride clone, and even solving client projects via WhatsApp chat. Here’s a real-world test drive of GPT-5’s capabilities, complete with humor, screenshots, and actual code. Nerds and non-nerds alike, welcome.

_So GPT-5 walked into my browser, and I thought, “Let’s break the internet… or at least my to-do list.”_ 😎

While most people were still wrapping their heads around GPT-4, OpenAI surprised us with GPT-5, and I couldn’t resist diving head-first into testing it. I loaded up t3.chat, brewed some tea, and told myself: if this model breaks, I’ll break with it. Spoiler alert: I didn’t.

This blog isn't just another tech review. It's a _real-world test drive_ of GPT-5 with tasks that range from web dev issues to UI refactoring, game creation, and even marketing copy help. And yes, there’s code. Lots of it. Let’s go, one task at a time.

---

## Task 01: Fixing Google Tag Manager Issues

For a while, I was unintentionally running **two Google Tag Manager setups**: one for analytics and one for ads. Rookie mistake, I know.

So I fed GPT-5 the context, including screenshots (yes, it can parse those too), and boom—step-by-step guidance. It actually:

- Identified the conflict
- Cleaned up the tag hierarchy
- Suggested best practices for load performance

It felt like having a Google Analytics consultant on demand—who doesn’t judge you.

## Task 02: Updating My Website UI with Astro + Tailwind

I wanted to migrate some React components using Framer Motion over to **Astro components** with **Tailwind CSS and built-in animations**. Problem: Tailwind animation logic isn't quite as intuitive if you're coming from Framer Motion.

But GPT-5? This thing understood component structures and animation syntax like a senior frontend dev. I used both:

- **Cursor CLI Tool** (blog on that coming soon)
- **t3.chat with GPT-5**

And guess what? It recreated animations with precision, gave suggestions for UI simplification, and even auto-generated Tailwind utility combos that I hadn’t thought of.

## Task 03: Building a Jetpack Joyride Clone Game

So I saw Sam Altman talking about using GPT for building games. I said, _Challenge accepted._ I prompted:

> "Can you make me a simple Jetpack Joyride game?"

It delivered. The initial version was basic, so I asked it to improve UI, controls, and design. Here’s the evolution:

### Initial Game Code:

```html
<!DOCTYPE html>
<html lang="en">
  <head>
    
    
    <title>Jetpack Joyride Clone</title>
    <style>
      body {
        margin: 0;
        background: #222;
        overflow: hidden;
      }
      canvas {
        display: block;
        margin: auto;
        background: linear-gradient(#87ceeb, #1e90ff);
      }
    </style>
  </head>
  <body>
    <canvas id="gameCanvas" width="800" height="400"></canvas>
    <script>
      const canvas = document.getElementById("gameCanvas");
      const ctx = canvas.getContext("2d");

      // Player
      const player = {
        x: 50,
        y: 200,
        width: 40,
        height: 40,
        velocityY: 0,
        gravity: 0.5,
        lift: -10,
      };

      // Obstacles
      let obstacles = [];
      let frame = 0;
      let score = 0;
      let gameOver = false;

      function drawPlayer() {
        ctx.fillStyle = "yellow";
        ctx.fillRect(player.x, player.y, player.width, player.height);
      }

      function drawObstacles() {
        ctx.fillStyle = "red";
        obstacles.forEach((obs) => {
          ctx.fillRect(obs.x, obs.y, obs.width, obs.height);
        });
      }

      function updateObstacles() {
        if (frame % 90 === 0) {
          const height = Math.random() * 200 + 50;
          obstacles.push({
            x: canvas.width,
            y: canvas.height - height,
            width: 40,
            height: height,
          });
        }
        obstacles.forEach((obs) => (obs.x -= 5));
        obstacles = obstacles.filter((obs) => obs.x + obs.width > 0);
      }

      function checkCollision() {
        for (let obs of obstacles) {
          if (
            player.x < obs.x + obs.width &&
            player.x + player.width > obs.x &&
            player.y < obs.y + obs.height &&
            player.y + player.height > obs.y
          ) {
            gameOver = true;
          }
        }
        if (player.y + player.height > canvas.height || player.y < 0) {
          gameOver = true;
        }
      }

      function drawScore() {
        ctx.fillStyle = "white";
        ctx.font = "20px Arial";
        ctx.fillText("Score: " + score, 10, 20);
      }

      function gameLoop() {
        if (gameOver) {
          ctx.fillStyle = "black";
          ctx.globalAlpha = 0.7;
          ctx.fillRect(0, 0, canvas.width, canvas.height);
          ctx.globalAlpha = 1;
          ctx.fillStyle = "white";
          ctx.font = "40px Arial";
          ctx.fillText("Game Over", canvas.width / 2 - 100, canvas.height / 2);
          ctx.font = "20px Arial";
          ctx.fillText(
            "Final Score: " + score,
            canvas.width / 2 - 60,
            canvas.height / 2 + 30,
          );
          return;
        }

        ctx.clearRect(0, 0, canvas.width, canvas.height);

        // Player physics
        player.velocityY += player.gravity;
        player.y += player.velocityY;

        // Update & draw
        drawPlayer();
        updateObstacles();
        drawObstacles();
        checkCollision();

        // Score
        score++;
        drawScore();

        frame++;
        requestAnimationFrame(gameLoop);
      }

      document.addEventListener("keydown", (e) => {
        if (e.code === "Space") {
          player.velocityY = player.lift;
        }
      });

      gameLoop();
    </script>
  </body>
</html>
```

### Upgraded Version with UI, Sprites, Background:

```html
<!DOCTYPE html>
<html lang="en">
  <head>
    
    
    <title>Jetpack Joyride Clone</title>
    <style>
      body {
        margin: 0;
        background: #222;
        overflow: hidden;
        font-family: "Arial", sans-serif;
      }
      canvas {
        display: block;
        margin: auto;
        background: #87ceeb;
      }
      #overlay {
        position: absolute;
        top: 0;
        left: 0;
        width: 100%;
        height: 100%;
        display: flex;
        flex-direction: column;
        align-items: center;
        justify-content: center;
        background: rgba(0, 0, 0, 0.6);
        color: white;
        font-size: 24px;
        text-align: center;
      }
      button {
        padding: 10px 20px;
        font-size: 18px;
        margin-top: 20px;
        cursor: pointer;
        border: none;
        background: #ff9800;
        color: white;
        border-radius: 5px;
      }
      button:hover {
        background: #e68900;
      }
    </style>
  </head>
  <body>
    <canvas id="gameCanvas" width="900" height="500"></canvas>
    <div id="overlay">
      <h1>🚀 Jetpack Joyride Clone</h1>
      <p>Press SPACE or Hold Mouse/Touch to Fly</p>
      <button id="startBtn">Start Game</button>
    </div>

    <script>
      const canvas = document.getElementById("gameCanvas");
      const ctx = canvas.getContext("2d");
      const overlay = document.getElementById("overlay");
      const startBtn = document.getElementById("startBtn");

      // Load images
      const playerImg = new Image();
      playerImg.src = "https://i.ibb.co/3m1V7nB/jetpack-guy.png"; // placeholder sprite

      const coinImg = new Image();
      coinImg.src = "https://i.ibb.co/4m1V7nB/coin.png"; // placeholder coin

      const bgImg = new Image();
      bgImg.src = "https://i.ibb.co/6b1V7nB/bg-layer.png"; // placeholder background

      // Game variables
      let player, obstacles, coins, score, gameOver, frame, bgX, flying;

      function resetGame() {
        player = {
          x: 100,
          y: canvas.height / 2,
          width: 50,
          height: 50,
          velocityY: 0,
          gravity: 0.5,
          lift: -10,
        };
        obstacles = [];
        coins = [];
        score = 0;
        gameOver = false;
        frame = 0;
        bgX = 0;
        flying = false;
      }

      function drawBackground() {
        ctx.drawImage(bgImg, bgX, 0, canvas.width, canvas.height);
        ctx.drawImage(
          bgImg,
          bgX + canvas.width,
          0,
          canvas.width,
          canvas.height,
        );
        bgX -= 2;
        if (bgX <= -canvas.width) bgX = 0;
      }

      function drawPlayer() {
        ctx.drawImage(
          playerImg,
          player.x,
          player.y,
          player.width,
          player.height,
        );
      }

      function drawObstacles() {
        ctx.fillStyle = "#ff4d4d";
        obstacles.forEach((obs) => {
          ctx.fillRect(obs.x, obs.y, obs.width, obs.height);
        });
      }

      function drawCoins() {
        coins.forEach((coin) => {
          ctx.drawImage(coinImg, coin.x, coin.y, coin.size, coin.size);
        });
      }

      function updateObstacles() {
        if (frame % 100 === 0) {
          const height = Math.random() * 200 + 50;
          obstacles.push({
            x: canvas.width,
            y: canvas.height - height,
            width: 50,
            height: height,
          });
        }
        obstacles.forEach((obs) => (obs.x -= 5));
        obstacles = obstacles.filter((obs) => obs.x + obs.width > 0);
      }

      function updateCoins() {
        if (frame % 150 === 0) {
          coins.push({
            x: canvas.width,
            y: Math.random() * (canvas.height - 50),
            size: 30,
          });
        }
        coins.forEach((coin) => (coin.x -= 5));
        coins = coins.filter((coin) => coin.x + coin.size > 0);
      }

      function checkCollision() {
        for (let obs of obstacles) {
          if (
            player.x < obs.x + obs.width &&
            player.x + player.width > obs.x &&
            player.y < obs.y + obs.height &&
            player.y + player.height > obs.y
          ) {
            gameOver = true;
          }
        }
        coins.forEach((coin, index) => {
          if (
            player.x < coin.x + coin.size &&
            player.x + player.width > coin.x &&
            player.y < coin.y + coin.size &&
            player.y + player.height > coin.y
          ) {
            score += 50;
            coins.splice(index, 1);
          }
        });
        if (player.y + player.height > canvas.height || player.y < 0) {
          gameOver = true;
        }
      }

      function drawScore() {
        ctx.fillStyle = "white";
        ctx.font = "20px Arial";
        ctx.fillText("Score: " + score, 20, 30);
      }

      function gameLoop() {
        if (gameOver) {
          overlay.innerHTML = `
            <h1>💀 Game Over</h1>
            <p>Final Score: ${score}</p>
            <button id="restartBtn">Restart</button>
          `;
          overlay.style.display = "flex";
          document
            .getElementById("restartBtn")
            .addEventListener("click", () => {
              overlay.style.display = "none";
              resetGame();
              requestAnimationFrame(gameLoop);
            });
          return;
        }

        ctx.clearRect(0, 0, canvas.width, canvas.height);

        drawBackground();

        // Player physics
        if (flying) {
          player.velocityY = player.lift;
        }
        player.velocityY += player.gravity;
        player.y += player.velocityY;

        drawPlayer();
        updateObstacles();
        drawObstacles();
        updateCoins();
        drawCoins();
        checkCollision();

        score++;
        drawScore();

        frame++;
        requestAnimationFrame(gameLoop);
      }

      // Controls
      document.addEventListener("keydown", (e) => {
        if (e.code === "Space") flying = true;
      });
      document.addEventListener("keyup", (e) => {
        if (e.code === "Space") flying = false;
      });
      canvas.addEventListener("mousedown", () => (flying = true));
      canvas.addEventListener("mouseup", () => (flying = false));
      canvas.addEventListener("touchstart", () => (flying = true));
      canvas.addEventListener("touchend", () => (flying = false));

      startBtn.addEventListener("click", () => {
        overlay.style.display = "none";
        resetGame();
        requestAnimationFrame(gameLoop);
      });
    </script>
  </body>
</html>
```

And just like that, my childhood nostalgia had a browser-based rebirth. Bonus points: GPT-5 even suggested adding characters and sound effects if I wanted to take it further.

**Images:**
![Starting of the GTP-5](https://utfs.io/f/TViMykBJnLIJiQx6zpm04c8pb2PCWMuNRxzyw39BeGHY1I7F)
![End Response of the GTP-5](https://utfs.io/f/TViMykBJnLIJG04xkNawb4kvpnSiWK6hNjUHqM9Qc3e51BOa)

## Task 04: Project Help Through Chat Logs

I was stuck with a client project, unsure about requirements and a bit short on time. So I:

1. Exported my WhatsApp chat
2. Gave GPT-5 full context
3. Asked it to summarize goals and recommend solutions

It analyzed everything, broke down campaign needs, and even recommended Mailchimp pop-ups, signup landing pages, and remarketing strategies.

Some of the things I asked it:

> "I want to collect leads but ditch Gmail forms. What's better?"

> "Here’s a list of ideas: signup forms, embedded forms, surveys, ads—what’s ideal for me?"

GPT-5 replied with real marketing insights. It was like having a digital strategist on call.

Screenshots for context:

![Website Screenshot 1](https://upoevdcxa3.ufs.sh/f/IN4OjmY4wMHBXnZ1dSQiFhHc4D8kv2YePwEzyQOnbx90SfpK)
![Website Screenshot 2](https://upoevdcxa3.ufs.sh/f/IN4OjmY4wMHBdbzZougyKaOogCUwHXbPlf4L8SE0TIV5JB39)
![Website Screenshot 3](https://upoevdcxa3.ufs.sh/f/IN4OjmY4wMHBJPtqZtF6usOK0TVqB8Lv2akdgf94EwY5pjRD)

## Final Thoughts: GPT-5 for Nerds & Mortals Alike

If you're a casual user, GPT-5 will feel like a faster, smarter version of what you're used to.

But if you're a _nerd_, like me (and probably you), then the magic starts when you:

- Feed it context-rich tasks
- Push its coding logic
- Use it for real-world workflows (like game creation or marketing automation)

I haven’t tested its full **tool calling** powers or deeper **Cursor integration**, but that’s coming next. Stay tuned.

---

# AI Code Generation: Can Free Tools Build Full Apps? A Software Engineer's Honest Review

- **URL**: https://www.rafay99.com/blog/ai-code-generation-free-tools-full-apps/
- **Published**: 2025-08-04
- **Author**: Abdul Rafay
- **Tags**: AI, ThoughtsProcess, WebDevelopment
- **Description**: Breaking down which AI generated coding tool is good

I still remember it like yesterday. Fresh out of uni, bright-eyed and bushy-tailed, an intern wading into the world of Machine Learning because, hey, it was _the_ trend. Then, one fateful day, my coworkers dropped a bomb: "Have you seen ChatGPT?" My reaction? Let's just say it was less 'Aha!' and more **"Holy Molly!"**

That first encounter with an AI model generating human-like text, and even _code_, was a revelation. Something so simple, yet so profoundly powerful. My brain immediately zeroed in on the code generation—this was a game-changer. Initially, I was doing what any budding engineer might: copy-pasting snippets from a web browser, hoping for the best. And let's be real, the quality often didn't quite match the hype.

### The Copilot Revelation: Speed Over Polish

Then came GitHub Copilot. For a measly ( $10 ) a month, this thing was a wizard. It wasn't about perfect, pristine code in my region—frankly, nobody here bats an eye at clean code as long as the feature ships and looks good. Simple! The velocity increase Copilot gave me was insane. My sprint demos became smoother, my coffee breaks longer. It just _worked_ as a developer productivity powerhouse.

### The AI Arms Race: Claude, Cursor, and Beyond

Just when you thought OpenAI had the entire AI coding kingdom cornered, a new challenger appeared: Anthropic's Claude. It was like watching a tech-themed wrestling match, and suddenly, the ring had more contenders. Then Cursor came along, transforming the coding experience even further. Boom! AI coding assistants were everywhere—from your web browser to every IDE imaginable, all designed to supercharge developer workflow.

To this day, my daily workflow is inseparable from Cursor and T3.chat, leveraging Claude's prowess for coding. They’re just _that_ good, especially when you're juggling a Master's degree, research, and daily projects in Node, React, Flutter, and Laravel. It’s a wild ride, and every little bit of automation helps!

### The Grand Experiment: Can AI Build a Full App?

Now, with all that background out of the way, we're at the exciting part. We've seen AI generate snippets, complete functions, and even refactor. But the new frontier, the bold claim echoing across the internet, is "full application development." Can these AI tools truly deliver on that promise? I'm curious, perhaps a little skeptical, but mostly just itching to find out.

### The Rules of Engagement (and Why They Matter)

Before we dive into the code-slinging chaos, we need some ground rules. Think of it as my broke-but-determined approach to tech validation.

1. **Free Tier Only:** Because, let's be real, a software engineer trying to master new tech while also pursuing a Master's degree and engaging in research isn't exactly rolling in cash. Plus, most people start here.
2. **Same Prompt, Every Service:** Fairness is key. We're giving each AI the exact same starting line.
3. **One Chance Only, No Do-Overs:** Just like real-world deadlines (minus the existential dread), what you get is what you get. This also reflects how many users interact with these tools casually.

Why these strict rules? Well, aside from my personal financial situation, it’s about leveling the playing field. Many of these incredible tools often run on the same powerful AI models under the hood—be it Claude, AutoGPT, or a flavor of ChatGPT. It’s a true test of their interface, fine-tuning, and direct applicability for everyday developers like me.

### Our Contenders: The AI Gladiators

What are our contenders in this AI coding showdown? We have a couple of intriguing tools that claim to do it all, from scaffolding to full-app generation:

1. **[Lovable](https://lovable.dev/)**
2. **[Bolt.new](https://bolt.new/)**
3. **[Chef by Convex](https://chef.convex.dev/)**
4. **[Orchids](https://www.orchids.app/)**

### The Gauntlet: Our Ultimate AI Prompt

Now, for the main event! The prompt itself needs to be robust enough to push these tools to their limits, demanding a full-stack (even if local-storage-based) web application, not just a bare-bones script. It's got to be better, right? Here's the precise prompt we'll be throwing at each of these services. May the best AI win!

```
Develop a single-page web application for a minimalist to-do list, focused on user experience and maintainability and with Auth as well.

The application should:
1.  **Frontend Framework:** Utilize a modern JavaScript frontend framework (e.g., React, Vue, Svelte, or similar) to construct the UI. The choice should reflect current best practices for component-based development.
2.  **Core Features:**
    *   **Add Tasks:** An input field to add new to-do items. Implement client-side input validation to prevent the creation of empty tasks.
    *   **Manage Completion:** Each to-do item should have a way (e.g., a checkbox or toggle button) to mark it as completed or uncompleted. Completed tasks should have a distinct visual style (e.g., strikethrough or faded text).
    *   **Delete Tasks:** A button or icon next to each task to allow users to delete individual to-do items.
3.  **Data Persistence:** All to-do items must be stored in the browser's Local Storage, ensuring data persists across browser sessions. The application should load existing tasks on startup.
4.  **User Interface:**
    *   **Clean & Responsive Design:** Implement a modern, clean, and responsive design that works well on both desktop and mobile screens. Basic CSS styling is sufficient, but it should be visually appealing.
    *   **Filtering:** Include basic filtering options (e.g., buttons or tabs) to display "All", "Active", or "Completed" tasks.
    *   **Clear Layout:** Organize the UI with a distinct header, an input section for new tasks, and a clear list display for existing tasks.
5.  **Project Structure & Documentation:**
    *   **Complete Project:** Generate a complete and runnable project directory, including all necessary configuration files (e.g., `package.json`).
    *   **Comprehensive README:** Provide a detailed `README.md` file that clearly outlines:
        *   Required dependencies and environment (e.g., Node.js version, browser compatibility).
        *   Step-by-step installation instructions.
        *   Clear commands to run the application locally.
        *   A brief overview of the key components and overall code structure.
    *   **Code Quality:** Ensure the generated code is well-commented, follows reasonable code best practices for the chosen framework, and is easy to understand.
```

Alright, Abdul Rafay, let's refine just that "Lovable" section. We'll make it crisp, clear, and perfectly slot into your existing blog post, handling the more complex prompt you used for it as a specific stress test for _this_ tool, leading into your universal prompt for the others.

### **Tool 1: Lovable.dev - The Ambitious Start**

Lovable.dev has been practically living in my ad feeds, so it was naturally the first one I had to put to the test. My initial take? It's got potential, it's _good_, but it definitely feels like there are some rough edges needing polish, or perhaps a full refactor in places.

For Lovable, I decided to push the boundaries right out of the gate, giving it a truly ambitious challenge—a stress test, if you will, to see how far these "full application" claims could truly stretch. My prompt went beyond a simple to-do list, aiming for real-world complexity. I tasked it with:

- **Adding Authentication:** Because what's a modern app without user logins?
- **Database Persistence:** Storing to-do items not just locally, but in a backend database. For this, I specifically chose **Supabase** as the backend.

The **prompting process** itself was quite detailed and involved, guiding me through various configurations, which hinted at the complexity it was trying to handle. In terms of raw speed, Lovable was impressively quick for such a task, taking approximately **3 minutes** to generate what it claimed was a complete application. Not bad for kicking off a new project!![Image related to: The Copilot Revelation: Speed Over Polish](https://utfs.io/f/TViMykBJnLIJbRyJLS4nRBrPQNqFmsSdU0jLhDYMVTkJ4Z76)![Image related to: The Copilot Revelation: Speed Over Polish](https://utfs.io/f/TViMykBJnLIJLVMWAjGODv8zKEuQRClSiYAsbdfeG73ThV1q)![Image related to: The Copilot Revelation: Speed Over Polish](https://utfs.io/f/TViMykBJnLIJCjDM4EbfZI7RHWaFYJP0low5xecpCi2OtEhs)

As you can see from the process, it’s not all sunshine and rainbows. While the detailed prompting _tried_ to cover a lot of ground, the actual output told a different story.

![Image related to: The Copilot Revelation: Speed Over Polish](https://utfs.io/f/TViMykBJnLIJGl0H5Aawb4kvpnSiWK6hNjUHqM9Qc3e51BOa)![Image related to: The Copilot Revelation: Speed Over Polish](https://utfs.io/f/TViMykBJnLIJkrwtutG3iDowrFjuG5fYXpRx8zcT73VgyUQe)

The generated UI? It was okay—functional, but nothing to write home about. The real disappointment, though, came when it failed to perform even the most basic "add to-do" task correctly, despite the heavy lifting I asked it to do with authentication and Supabase integration. That's a significant letdown when the fundamental feature falls short.

On a positive note, setting up the Supabase connection for the authentication feature was surprisingly straightforward; it just needed a few button clicks to link it to an existing Supabase project. The _idea_ of integrating a backend with such ease is fantastic, even if the execution on the core feature wasn't quite there.

**Lovable.dev Verdict:** While its ambition to tackle auth and external databases with impressive speed is commendable, and the setup for Supabase was intuitive, the failure on basic to-do functionality left a significant gap. It's a powerful _idea_, but the current free-tier execution indicates a need for substantial refinement to deliver on the "full app" promise for complex prompts. This initial deep dive for Lovable truly shaped my approach for the _other_ tools, leading me to define the **Universal Prompt** (detailed below) that aims for a strong, robust, yet achievable feature set for consistent comparison.

### Tool 2: Chef by Convex - The Backend Maestro

Next up in our coding crucible is Chef by Convex. Now, I have a soft spot for Convex itself; honestly, it's an amazing product for building robust backend applications. I'm talking production-level stuff, where with the right code and optimization, things really sing. Given my daily use of its API endpoints and services, I wasn't entirely surprised by Chef's performance in certain areas.

When putting Chef to the test with our **Universal Prompt**, its speed was impressive, living up to the snappy performance I expect from Convex's infrastructure. It's incredibly fast, and its real-time preview and websocket capabilities are just what you'd expect from a Convex-powered tool – no surprises there, and definitely a huge plus for rapid iteration.

The **prompting process** with Chef was quite straightforward and workable. It efficiently translated the prompt into a functional application, particularly on the backend.![Image related to: The Copilot Revelation: Speed Over Polish](https://utfs.io/f/TViMykBJnLIJTe15umJnLIJBWPvUF7zO3g50aD6HtkNEXpR2)![Image related to: The Copilot Revelation: Speed Over Polish](https://utfs.io/f/TViMykBJnLIJtUjvM25Tkd73eKjcbxAusS1ZaL02X5lBpmzU)![Image related to: The Copilot Revelation: Speed Over Polish](https://utfs.io/f/TViMykBJnLIJUL4jpPxZdb0IOL1s3KJqktcxwpW9faXP2muE)

However, and this is where the _chef_ sometimes leaves the presentation a bit simple, the **UI generated** by Chef tends to be quite minimalist. This isn't entirely unexpected, though, as Convex itself shines as a robust database and backend service. Its strength isn't primarily in generating visually stunning frontends, but rather in providing solid, functional backend foundations.

While the UI might be basic, the underlying backend functionality generated by Chef for this "simple" to-do application was robust. It leverages Convex's capabilities well, demonstrating its proficiency where it counts most for data persistence and real-time updates.

**Chef by Convex Verdict:** Chef delivers on its promise of speed and reliable backend functionality, unsurprisingly given Convex's core strengths. If you're looking for an AI tool that nails the data layer and real-time updates, especially with a Convex backend, this is a strong contender. However, don't expect a dazzling frontend out of the box. It’s a tool that excels at plumbing, perhaps leaving the interior decorating to the developer.

### **Tool 3: Orchids - The UI Powerhouse**

Now, if you're anything like me and appreciate a stunning frontend, Orchids.app immediately grabs your attention. This tool is, hands down, **amazing for designing a good-looking UI**. Even on its free tier, it conjures up applications with slick animations and that modern aesthetic we all crave. Visually, I genuinely _like_ this product a lot.

When put against our **Universal Prompt**, Orchids didn't just build a to-do list; it made it look good. Its commitment to a polished user experience is evident.

![Image related to: The Copilot Revelation: Speed Over Polish](https://utfs.io/f/TViMykBJnLIJv3Qu6YdxMXjfviDwkBcsUay3O21YNZQ9mzJd)![Image related to: The Copilot Revelation: Speed Over Polish](https://utfs.io/f/TViMykBJnLIJouOtlTgf5cFEHfqaQ1VpPtBs7YTRm3hZlNOA)

One key differentiator that immediately caught my eye: Orchids uses **Next.js** for its frontend framework, which is the latest version. This stands in contrast to many other tools, like those opting for React with Vite, which often inject JavaScript into a single HTML file. The Next.js choice gives developers significantly more control over the UI, offering a more structured and robust foundation for complex designs and routing, rather than just spitting out a simple SPA. It's a pro move for frontend architecture.

However, every orchid has its thorns, and this tool is no exception. While the UI is its undeniable superpower, there are a couple of significant limitations when it comes to building a truly "full" application as per our prompt:

- **No Database Integration:** Currently, Orchids lacks direct database integration. All data persistence relies solely on **Local Storage**. This is a major functional bottleneck for any app needing dynamic, server-side data or multi-user capabilities.
- **Export Workflow:** Here's the kicker for us developers. While many of these AI tools proudly feature an "Export to GitHub" button, allowing you to connect directly to a repo, remove demo code, and hook up your backend... Orchids doesn't have it yet. That coveted feature is marked "coming soon." For now, it's back to the old-school copy-and-paste method to get your beautifully designed code into your project. Not ideal for modern dev workflows, but the UI might just be tempting enough to make you consider it!

**Orchids.app Verdict:** If you prioritize a visually stunning, animated, and modern UI, Orchids is an absolute gem, especially with its Next.js foundation offering superior frontend control. It's a fantastic starting point for design-heavy projects. However, its current lack of database integration and the frustrating absence of a direct GitHub 

### The Grand Conclusion: So, Can AI Build a Full App?

After putting Lovable, Chef, and Orchids through their paces with some demanding prompts (and a few ambitious detours!), a clear picture emerges about the current state of free-tier AI code generation for "full applications."

Here's the lowdown, straight from the developer's trenches:

- **UI Superstars (with caveats):** Without a doubt, some of these AI tools are absolute gems for quickly spinning up **stunning user interfaces**. Orchids, for instance, proved it can deliver a modern, animated look using Next.js, making it a fantastic starting point if eye-catching design is your top priority. You can get that visually appealing shell in minutes.
- **Database Dilemmas:** This is where the "full application" dream often hits a snag. As we saw, many of these tools struggle with robust **database integration and complex backend connections**. While some, like Lovable, make the setup look easy, the actual functional persistence can be flaky. Others, like Orchids, simply default to Local Storage, which is great for client-side persistence but completely unsuited for multi-user or scalable applications. Chef by Convex, while backend-strong, leans on its own ecosystem. The general takeaway? Expect to roll up your sleeves and build out your backend.
- **Scalability Sidelined:** Let's be real—the code generated by these free-tier tools is designed for rapid prototyping, not for the rigors of **massive traffic or production loads**. Optimization for performance, security, and scalability is still firmly in the human developer's court. These are quick starts, not deploy-ready solutions for the next viral sensation.
- **Tech Stack Roulette:** The versioning and tech stack choices can be a bit of a mixed bag. While some tools might surprise you with a cutting-edge **Next.js** build, others might drop in slightly older (but still stable) packages like **Tailwind 3.x** or **React 18.x**, while newer versions are already out. It's a reminder that relying solely on AI might lead to a quick build, but also potential dependency headaches or missed opportunities for the very latest features and optimizations.

**The Verdict for Software Engineers:**

So, can free AI tools build a _full_ application? Not quite, at least not one ready for the wild west of production traffic or complex data management. They are, however, incredibly powerful accelerators.

My recommendation? **Leverage these tools to create your stunning-looking UI prototypes or foundational frontends.** Let AI handle the visual heavy lifting and the basic scaffolding. But from there, it's time for the human touch: **connect your robust database, optimize the code for performance, and ensure it's engineered to truly meet the client's needs and future scalability demands.**

AI is a fantastic co-pilot for the initial flight, but you, the software engineer, are still the seasoned pilot charting the course to a truly successful and sustainable application. The future of development isn't just AI _or_ humans; it's a dynamic, powerful partnership.

Until then..Keep Coding Nerds...

---

# Spilling the Tea: How a "Hack" Exposed Millions, and Why Your Backend Matters More Than Ever

- **URL**: https://www.rafay99.com/blog/tea-app-hack-lessons-why-backend-matters/
- **Published**: 2025-08-02
- **Author**: Abdul Rafay
- **Tags**: blog
- **Description**: A deep dive into the Tea App data breach, explaining why it was a hack caused by poor backend design, Firebase misconfigurations, and the critical importance of proper API architecture.

If you haven't been following, Tea is an app designed for women to share insights about men they've dated. Regardless of your personal feelings about the app's premise (and trust me, we all have them!), the security snafu that hit them is an absolute masterclass in "what not to do."

While many are calling it a simple data leak, I'm unapologetically calling it a hack. And no, it wasn't some fancy zero-day exploit or "vibe coding" gone wrong. It was, quite simply, a symphony of bad design decisions that turned a simple file bucket into a data public square. And spoiler alert: Firebase plays a starring role in this drama.

Let's uncork this bottle of un-tea-fied chaos.

### What Went Down? The "Tea" on the Breach

First, the facts. To ensure only women could sign up for Tea, the app required users to submit identity verification photos or IDs. These highly sensitive files (we're talking faces, government IDs, and even raw metadata like location from phone cameras!) were stored in a public Firebase bucket. And then, well, someone found all the URLs, saved every file, and _poof_ – hundreds of thousands of people's private data were exposed to the world.

To add insult to injury, this specific bucket hadn't even been in active use since mid-2024, meaning it primarily affected older users who thought their data was safe. And just when you thought it couldn't get worse, a second breach exposed all their in-app message data, forcing them to shut down the messaging feature entirely.

**The chilling takeaway?** Whether you love or hate this app, no one expects their identity documents or private conversations to be laid bare for the internet to feast upon. This is a fundamental betrayal of user trust.

### The Unlocked Door Fallacy: Why It's Still a Hack

Now, let's address the elephant in the room: "But the bucket was public! It wasn't a hack!"

My take? That's just silly. We use the term "hack" similarly to "steal." If someone leaves their front door unlocked, and a person walks in, rummages through their belongings, and takes their valuables, did they not steal? Absolutely! They just didn't have to pick a lock.

The same logic applies here. Yes, the files were on publicly accessible URLs. But those URLs are usually randomly generated (like UUIDs) and virtually impossible to guess en masse. You can't just "sniff" every public URL on the internet. To get _all_ the files, the perpetrators needed an _index_—a list of every single URL. And guess what? They got that index by hitting an exposed Firebase API endpoint that conveniently listed all the data in the bucket.

**This is the crucial distinction:** Exposing individual public URLs isn't ideal, but it’s often a design choice (like unlisted YouTube videos). Exposing an _endpoint that provides a comprehensive list of all those URLs_? That, my friends, is a fundamental security flaw that was exploited. They didn't "break in" through a strong door, but they sure as heck walked through an open garage, found the keys to the house, and took everything. That's a hack in my book.

### The Root Cause: When Your Database Becomes a Public Square

So, how did this happen? It all boils down to an architectural philosophy that, frankly, sends shivers down my spine: allowing direct client-to-database access without a proper API layer.

Let's visualize the difference:

**Diagram 1: The Secure API Model**

```mermaid
graph TD
    User["User (Client)"] <--> API["API / Server (Auth & Validation)"]
    API <--> DB["Database"]

    subgraph Explanation
        direction LR
        S1["How it works:"] --> S2("1. User sends a specific request (e.g., /getProfile?id=XYZ) to the API.")
        S2 --> S3("2. The API, written by developers, validates the user's identity and permissions.")
        S3 --> S4("3. If authorized, the API constructs a secure query to the database.")
        S4 --> S5("4. The database returns only the requested data to the API.")
        S5 --> S6("5. The API processes/reshapes the data and sends it back to the user.")
        S6 --> S7("Security: Logic is centralized in the API. Developers explicitly write code for authorization.")
    end
```

**Diagram 2: The Direct Database Access Model (Firebase / Bad Pattern)**

```mermaid
graph TD
    User["User (Client)"] --> DB["Database (Firebase/NoSQL)<br>(Rules / Permissions<br>-- Often Missing/Misconfigured)"]

    subgraph Explanation
        direction LR
        S1["How it works:"] --> S2["1. User's client-side code directly queries the database (e.g., db.collection('profiles').get())."]
        S2 --> S3["2. The database (theoretically) applies rules to determine access."]
        S3 --> S4["3. The database sends data directly back to the user."]
        S4 --> S5["Security: Relies heavily on complex, declarative rules that are easy to misconfigure or overlook, often 'exposed by default.'"]
    end

```

### Firebase: A Convenient Trap?

Firebase, being a "backend as a service" provider, simplifies app development by handling databases, file storage, authentication, and more. It gained popularity, especially among mobile developers, because it offered a seemingly elegant solution to avoid writing server-side code. "Why build an API," the thinking goes, "when the user can just query the database directly?"

This is where the convenience becomes a trap. In a traditional API, you're _forced_ to write code that explicitly defines _how_ data is accessed and _who_ can access it. When you're building an endpoint like `/getProfile`, it's glaringly obvious that you need to add authentication and authorization checks. It's part of the coding process.

With Firebase (and similar services that promote direct client access), you're often given a database that is "exposed by default." You then layer on rules or permissions to _restrict_ access. The problem? It's much easier to forget to restrict something, or to misconfigure a complex rule, than it is to forget to _write_ the code that grants access in the first place. This leads to common misconfigurations where an endpoint that should only show _your_ profile data ends up revealing everyone's, or worse, listing every single file in a storage bucket.

### Learning from the Spill: How to Brew Secure Apps

The core lesson from the Tea App fiasco is simple, yet often overlooked: **All data access should be explicitly defined in your source code, on a server.**

If you're building an application, you should be defining specific API endpoints (functions, mutations, queries) that act as the gatekeepers to your data. This forces you to think about:

- **Authentication:** Is the user who they say they are?
- **Authorization:** Does this user have permission to access _this specific piece_ of data?
- **Data Transformation:** Do I need to reshape or filter the data before sending it to the user?

Platforms like Convex (a personal favorite, full disclosure!) mandate this approach. You can't directly query the database from the client. Instead, you define explicit queries and mutations (as actual functions in your codebase) that mediate access, often with built-in authentication helpers. This makes security an integral part of development, not an afterthought.

### Beyond the Mobile Bubble: A Call for Full-Stack Sanity

A big reason issues like this persist, in my opinion, is a divide in the developer world. There's a tendency, especially among some mobile developers (and I say this as a former mobile dev!), to have an almost phobic aversion to anything server-side. Building "real" backend infrastructure often gets pushed aside for the convenience of services like Firebase, promising to remove the need to "think about infra."

But guess what? If you're not thinking about your infrastructure, you're leaving a gaping hole for disaster. The "Tea App" isn't an isolated incident; stories abound of companies, even major fast-food chains, getting "Fireponed" because mobile teams built their backends with publicly exposed databases.

My advice for every developer, regardless of your specialty: **Break out of your bubble!**

- **Mobile Devs:** Go build a proper web backend. Understand servers, APIs, and databases. Conquer your fear of JavaScript (or whatever language your backend uses).
- **Web Devs:** Dive into mobile development. Learn Swift/Kotlin, understand platform-specific challenges. Or truly dig deep into backend architecture.

Understanding the entire stack — from client to API to database — makes you a more valuable, more secure, and frankly, a more complete engineer. The average mobile dev can sometimes be indistinguishable from a "vibe coder" when it comes to server knowledge, and that's a problem we need to fix.

### Key Takeaways (The Strong Brew)

Here's the concentrated essence of what we've discussed:

1. **Write Your Data Access Code**: Always define server-side functions or API endpoints that control how data is accessed from your database. Don't rely solely on declarative database rules.
2. **Beware of "Exposed by Default"**: If a service encourages direct client-to-database access, or if data is exposed by default, proceed with extreme caution. It's a disaster waiting to happen.
3. **Broaden Your Horizons**: Don't limit yourself to one part of the stack. A deeper understanding of how front-end, back-end, and databases interact is crucial for building secure and robust applications.

This hack wasn't fancy. It was a basic failure of architectural understanding and secure defaults. Let this be a bitter lesson that we all take to heart.

What do you think? Was I too harsh on Firebase, or did I hit the nail on the head? Let me know your thoughts in the comments!

Until next time, Nerd...Keep Coding

---

# From Pixelated Panes to Polished Pixels: My OS Odyssey from Windows Lifer to Mac Convert (and Linux Lover!)

- **URL**: https://www.rafay99.com/blog/os-odyssey-windows-mac-linux-software-engineer/
- **Published**: 2025-07-28
- **Author**: Abdul Rafay
- **Tags**: OS
- **Description**: A software engineer's brutal, honest journey through Windows, macOS, and Linux. Discover the real-world frustrations and surprising delights of each operating system from a daily driver's perspective in this no-holds-barred OS comparison.

For what felt like an eternity, my digital life revolved around one constant: **Windows**. From the nostalgic green hills of XP to the familiar tiles of 11, I navigated Microsoft's ecosystem like it was my backyard. Every shortcut, every quirk, every "unexpected error" message – it was home. I was a **Windows** power user, through and through, occasionally peeking at **macOS** on YouTube videos like it was some exotic, unattainable luxury car I'd never get to drive. (Okay, maybe one two-minute joyride on my cousin's Mac, but that barely counts!)

Then came the leap. The big, bold, slightly terrifying jump from my lifelong **Windows** comfort zone straight into the beautifully alien world of **macOS**. Suddenly, my mouse moved _differently_, windows minimized with a graceful (yet confusing!) flourish, and the 'delete' key seemed to have gone on vacation. My muscle memory was having an existential crisis! The visual overhaul alone was enough to make my brain do a double-take.

But here's where my tech story gets really interesting: as a **software engineer** deeply entrenched in the daily grind of Node, React, Flutter, and Laravel, my **operating system** journey didn't stop at just two. Oh no. I've now officially punched my ticket and clocked in significant time on all three major players: **Windows**, **macOS**, and yes, even the glorious, quirky depths of **Linux**. From the polished desktops to the powerful command lines, I've truly lived and coded within each distinct digital universe.

And let me tell you, after navigating the peculiar charms and occasional frustrations of all three, I've gathered some genuinely fascinating (and often hilarious!) insights into their unique personalities. This isn't just a dry **OS comparison**; it's a personal, boots-on-the-ground review from someone who's experienced the full spectrum of **operating systems**. So, if you've ever wondered about the ultimate **Windows vs. Mac vs. Linux** showdown from a hands-on, daily-driver perspective – especially for a fellow tech enthusiast or **software engineer** – you're in for a treat. Let's dive in!

## The Unvarnished Truth: Every OS Sucks (And Why I'm Here to Prove It)

Before we dive into the nitty-gritty, let me drop a truth bomb right here, right now: **no operating system is perfect**. Period. If you're coming into this thinking **Windows** is the GOAT, **Linux** is the holy grail, or **macOS** is the flawless nirvana, then frankly, you can kindly skip this post. This isn't a fanboy forum. This is where we get brutally honest.

With that out of the way, let the spanking begin!

## Windows: My Ex-Lover, My Digital Tormentor

Oh, **Windows**… where do I even start? You’ve been a persistent pain in my rear for so long, it's hard to forget the trauma. I still get nightmares. Nightmares of waiting _hours_ to hunt down some obscure `.exe` file, or the agonizing crawl of a **Flutter SDK** download. Seriously, I've got a robust network connection, yet on my Windows machine, any heavy SDK or framework felt like it was trickling down through a sieve made of molasses.

And don’t even get me started on the processes! My God, the sheer _volume_ of background processes would kick my rig's behind! I had 16GB of RAM, and half of it was just... gone. Eaten by Windows! What in the actual heck are you doing with 8GB of my precious RAM?! The moment I dared to open an Android emulator alongside VS Code, my machine would gasp for air. Forget opening a browser for documentation – that was an elite move I couldn't afford. Even after all the debloating, the tweaking, and meticulously pruning background processes, you still sucked. Until I bumped my RAM to a ridiculous 40GB, you were basically holding my workflow hostage. Are you kidding me, Windows? What’s wrong with you?!

This is just the beginning. Let’s talk about installing applications. The sheer amount of time I had to spend navigating different websites, hunting down every single `.exe` file, then enduring that mind-numbing "click, click, next, next, finish" ritual. It's not just useless; it’s soul-crushingly annoying!

And the bloat! My machine was stuffed with apps I never used, like a digital hoarder's paradise. "Oh, but you can install applications with **Winget**!" someone might chime in. Sure, except Winget itself was broken on my fresh install! I had to update Winget through my browser, which, you guessed it, required downloading _another_ `.exe` file. The irony is thicker than a Windows update! And if you suggest using the Microsoft Store, please, for the love of all that is digital, see a doctor. You really need help.

## Linux: The Love-Hate Relationship of a Code Whisperer

Ah, **Linux**… A few years ago, when I first dipped my toes into your open-source waters, I felt like a god. I was the ultimate nerd, "ricing" my desktop, crafting intricate shell scripts to perfectly configure my laptop. It was exhilarating! But then reality hit. Now, I barely touch those scripts. Don’t get me wrong, they're cool, they're powerful, but for long-term daily use? Nah. There's a script for everything, from your lock screen to launching any application, but the novelty wears off.

Speaking of applications, why in the name of Tux are there so many ways to install them?! You’ve got package managers, Flatpak, Snap, `.deb` files, and the glorious (and sometimes terrifying) AUR! Please, for God's sake, choose one format to install applications! To make matters worse, each installation method often holds a different version of the same application. So, one feature might be available via Flatpak, while another bug fix is only in the Snap version. Seriously, well done, Linux; you've managed to make installing software more complex than quantum mechanics! If you want to dive deeper into this madness, check out my [other blog post](https://www.rafay99.com/) on the myriad ways to install apps.

The good thing about Linux is the customization. Right? …_Right_?! In terms of UI, absolutely. But in terms of drivers? Please, no! I beg you! Sure, you can eventually find most drivers on Linux, and when they work, they make life so much easier. But there's one driver that has driven me to the brink of insanity. Any guesses?

…It’s **Nvidia**. Not too long ago, Linus Torvalds famously told Nvidia: "Fu\*\* You." And when I watched that video, I thought, "It can't be _that_ bad." Oh, I was so wrong. So, so wrong. Nvidia drivers on Linux are a special kind of hell. If you're on Debian, you're pretty much doomed. Linux Mint, Pop!\_OS, or Ubuntu users might fare better, as things generally work out of the box. But with Arch Linux and any Gentoo-based distro, setting up Nvidia drivers is the absolute worst experience. They'll work fine in laptop mode, but the moment you connect an external display and switch to desktop mode, you're dead. Your Nvidia driver won't work, and your laptop will inevitably go into sleep mode. Like, _why_?! Why does this keep happening?!

## macOS: The Beautiful Prison with Hidden Annoyances

You think **macOS** is a safe haven? Think again. As of this writing, I’ve been using a Mac for about a week, and I've gathered enough data to thoroughly pull apart its shiny veneer. So, let’s begin. This is going to be fun.

First, let’s talk about **Apple ID**. Why, _why_ do I need an Apple ID just to download Xcode? Tell me that! I can download other apps without one, just like Windows. But for Xcode, a fundamental coding tool I bought this machine _for_ to build iOS applications, I’m blocked until I create an Apple ID. This drove me absolutely insane. "Okay," I thought, "I'll create an account."

But it wasn’t sunshine and rainbows. Because I tried too many times on my brand-new, $1700 Mac, it got _blocked_! Yes, my pristine new machine was bricked because I tried too hard to create a damn Apple ID. I literally had to contact Apple Support just to unlock my new freaking Mac so I could create the Apple ID and download Xcode.

At every step, it’s "This isn't secure," or "Are you sure?" I get the privacy thing, I really do, and I'm okay with some permissions. But blocking my entire device because I attempted to create an Apple ID too many times?! The OTP for my phone wasn't reaching me, so I had to try multiple times. And to top it off, I had to make an _international call_ to Apple Support. I was already broke, but now I’m even broker from that call! Did you know those calls are expensive?!

And let’s talk about basic apps. Why are so many fundamental tools missing? I need a separate application just for window snapping? Another for clipboard history? An _app_ to uninstall applications? In most operating systems, when you remove an application, all its dependencies are cleaned up. Not on Mac. Those orphaned files still exist, lingering like digital ghosts. Please, Apple, I beg you, add some basic default features!

The screenshot tool is another pain point, especially when I'm on an external display. If my mouse is on the external screen and I press `Command + Shift + 3`, it takes a screenshot of the _entire_ main screen, not the external one. I have to manually select the area or use a different key combo just to capture what I want. Why, God, why?! Or rather, Why, Apple, why?!

Oh, and the app download process is eerily similar to Windows: hunt for a `.dmg` or `.pkg` file, double-click, drag-and-drop. If you say "oh, but **Homebrew**!" — sure, it has _some_ applications, a decent few, but certainly not all of them.

Now for the good stuff, because it’s not all doom and gloom. The absolute best thing about **macOS** has to be the hardware synergy and optimization. The body, the keyboard, the trackpad, the battery life, the screen, the webcam, and especially the **memory management** – oh my God, it's _chef's kiss_. I have 16GB of RAM, and I push this machine hard. I’m doing web dev, mobile dev, editing videos, and writing content, and it never slows down. Crashes? They simply don't happen. The battery life is phenomenal, and it supports fast charge, which has made my life ridiculously easy.

In terms of keybindings and muscle memory, I'm still adjusting, but I'm learning. It’s a work in progress, just like my feelings about these three very different digital companions.

YES! This is exactly the kind of unvarnished, human take we need on the tech landscape. Your honesty is refreshing!

Alright, let's nail this conclusion, keeping that fiery, insightful spirit.

## The Verdict: No OS is Perfect, But One Sucks Less (For Me, Right Now)

So, after this wild, often frustrating, occasionally hilarious deep dive into the digital universes of **Windows**, **Linux**, and **macOS**, what's the ultimate verdict? If there's one resounding truth I've hammered home today, it's this: **every operating system sucks in its own glorious, unique way.** There's no flawless, magical platform waiting to solve all your problems – trust me, I've looked!

**Windows**, my long-time companion, feels like that ex you keep bumping into: full of baggage, resource-hungry, and with an app installation process that belongs in the Dark Ages. It’s the familiar pain you somehow endure.

**Linux**, the wild child of the bunch, offers unparalleled customization and freedom for the tinkerer in us all. But that freedom often comes at the cost of driver headaches (looking at you, Nvidia!), and an application installation ecosystem that’s more confusing than a polyglot coding convention. It’s a beautiful beast, but one that demands patience and a high tolerance for troubleshooting.

And then there's **macOS**, the new kid on my block. It's the aesthetically pleasing, hardware-optimized dream that feels like butter for a **software engineer** pushing their machine hard. Yet, it’s also the beautiful prison, with its walled garden, infuriating basic feature omissions, and an Apple ID gatekeeper that nearly drove me to tears (and international calling fees!)

Ultimately, as a **software engineer** churning out code in Node, React, Flutter, and Laravel, it's not about finding the "best" OS. It's about finding the one that sucks _least_ for your specific workflow, your sanity, and your wallet. For me, right now, the sheer performance, stability, and glorious memory management of **macOS** — despite its infuriating quirks and hidden costs — are winning. That smooth, consistent performance when juggling multiple dev environments? Priceless.

But who knows? The tech landscape is always shifting, and my journey is far from over. What about you? Have you made the jump? What’s been _your_ biggest OS headache or surprising delight? Drop your thoughts in the comments below – let's compare battle scars!

Until then Nerds..Keep Coding & Exploring

---

# Stop the Presses: Convex Is Here… And So Are the Growing Pains

- **URL**: https://www.rafay99.com/blog/convex-scaling-cache-nightmare/
- **Published**: 2025-07-25
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess
- **Description**: A wild journey into building with Convex, where backend magic meets real-world scaling headaches.

**Ah yes, Convex.** The backend equivalent of sliced bread—at least according to the tech hype machine. You’ve seen it. YouTube tutorials swooning. X (formerly Twitter) threads declaring it the One True BaaS™ for web and AI alike. Blog posts throwing around words like _"game-changer"_ and _"magic"_. So, naturally, when I landed a shiny new gig as a Full-Stack Software Engineer and got the task of building an onboarding flow, I thought: **"Why not lean into the hype?"**

So I did.

I spun up a nice little Next.js frontend, connected it with Convex for the backend, tossed Clerk into the mix for authentication, and let my AI copilots help with the heavy lifting. Fast-forward a few hours and a few too many coffees, and what I had was a codebase so pristine it could hang in a modern art museum. Every mutation lived in its own file. The UI clicked at endpoints like clockwork.

**Piece of cake, right?**

**HAHAHA.**
(_Cue the screaming._)

## The Calm Before the Storm

I presented the app to my manager. The response? “Wow, this is great!”
Everyone loved the sleek dashboard and smooth UX. We made a few tweaks, but nothing major. The vibe was optimistic.

Then came **July 20th, 2025 at 12 AM**—deployment time. And you know what? Everything actually worked. For a few days.

In just 12 hours, **200 users signed up.**
I watched the data stream in, jaw on the floor. It was like watching fireworks on New Year’s—except these fireworks were my backend APIs exploding in real-time.

## The Happy Story Ends

Traffic kept climbing. 500+ users online at once.
And then… the issues began.

### The Problem:

Client-side errors. Performance drops. Broken components.

But here's the kicker:
**No errors in the logs. Zero. Nada.**
The system _looked_ fine, but it was slowly dying inside.

So, I did what any engineer would do—meetings, debugging, late-night Slack rants, and more debugging.

Eventually, the culprit revealed itself:

> **Convex cache was hitting max capacity. Constantly.**
> And once it hit 100%, the application just... broke.

![Convex Cache](https://utfs.io/f/TViMykBJnLIJtE4tTZ5Tkd73eKjcbxAusS1ZaL02X5lBpmzU)

## The Original Code: What Went Wrong?

Here’s the original `getLeaderboard` function that led us down this rabbit hole:

```typescript

  args: {
    limit: v.number(),
    skip: v.number(),
    country: v.optional(v.string()),
  },
  handler: async (ctx, args) => {
    const maxProcessLimit = 1000;
    const processingLimit = Math.min(
      args.limit + args.skip + 100,
      maxProcessLimit,
    );

    let query = ctx.db.query("users");

    if (args.country) {
      query = query.filter((q) => q.eq(q.field("country"), args.country));
    }

    const users = await query.take(processingLimit);

    const sortedUsers = users
      .map((user) => ({
        userId: user.userId,
        name: user.name,
        profileImage: user.profileImage,
        country: user.country,
        totalPoints: Object.values(user.pointsBreakdown).reduce(
          (a, b) => a + b,
          0,
        ),
        directReferralCount: user.directReferralCount,
      }))
      .sort(
        (a, b) =>
          b.totalPoints - a.totalPoints ||
          b.directReferralCount - a.directReferralCount,
      )
      .slice(args.skip, args.skip + args.limit);

    const totalUsers = await ctx.db.query("users").collect();
    const totalCount = args.country
      ? totalUsers.filter((u) => u.country === args.country).length
      : totalUsers.length;

    return {
      leaderboard: sortedUsers,
      total: Math.min(totalCount, maxProcessLimit),
      hasMore: args.skip + args.limit < Math.min(totalCount, maxProcessLimit),
      pagination: {
        limit: args.limit,
        skip: args.skip,
        nextSkip:
          args.skip + args.limit < totalCount ? args.skip + args.limit : null,
      },
    };
  },
});
```

This code worked beautifully—for a demo. But in production, with real traffic? Not so much.

### Why it failed:

- **`collect()` pulls _everything_ into memory.** That’s like trying to drink from a firehose because you're a little thirsty.
- **No pagination safeguards.**
- **Heavy client-side computation.**
- **No caching optimization.**

## The Rewrite: Optimized and Cache-Friendly

So I rewrote the function. Introducing the **new and improved** `getLeaderboard`:

```typescript

  args: {
    limit: v.number(),
    skip: v.number(),
    country: v.optional(v.string()),
  },
  handler: async (ctx, args) => {
    const safeLimit = Math.min(args.limit, 50);
    const safeSkip = Math.max(0, args.skip);

    // Try to get precomputed leaderboard first
    const precomputed = await ctx.db
      .query("precomputedStats")
      .withIndex("by_type_country", (q) =>
        q.eq("statType", "leaderboard").eq("country", args.country || "global"),
      )
      .first();

    if (precomputed && Date.now() - precomputed.updatedAt < 300000) {
      const data = precomputed.data as any[];
      const sliced = data.slice(safeSkip, safeSkip + safeLimit);

      return {
        leaderboard: sliced,
        total: data.length,
        hasMore: safeSkip + safeLimit < data.length,
        pagination: {
          limit: safeLimit,
          skip: safeSkip,
          nextSkip:
            safeSkip + safeLimit < data.length ? safeSkip + safeLimit : null,
        },
        fromCache: true,
      };
    }

    // Fallback: Live DB fetch with index
    let query = ctx.db.query("users").withIndex("by_createdAt");

    if (args.country) {
      query = query.filter((q) => q.eq(q.field("country"), args.country));
    }

    const fetchLimit = Math.min(safeLimit + safeSkip + 20, 100);
    const users = await query.take(fetchLimit);

    const processedUsers = users
      .filter((user) => !user.email.startsWith("DEACTIVATED_"))
      .map((user) => ({
        userId: user.userId,
        name: user.name,
        profileImage: user.profileImage,
        country: user.country,
        totalPoints: Object.values(user.pointsBreakdown).reduce(
          (a, b) => a + b,
          0,
        ),
        directReferralCount: user.directReferralCount,
      }))
      .sort(
        (a, b) =>
          b.totalPoints - a.totalPoints ||
          b.directReferralCount - a.directReferralCount,
      );

    const sliced = processedUsers.slice(safeSkip, safeSkip + safeLimit);

    return {
      leaderboard: sliced,
      total: processedUsers.length,
      hasMore: safeSkip + safeLimit < processedUsers.length,
      pagination: {
        limit: safeLimit,
        skip: safeSkip,
        nextSkip:
          safeSkip + safeLimit < processedUsers.length
            ? safeSkip + safeLimit
            : null,
      },
      fromCache: false,
    };
  },
});
```

## Why This Works Better:

✅ Safe pagination with hard limits
✅ Precomputed leaderboard support (with 5-minute TTL)
✅ No `collect()`—goodbye memory blowups
✅ Index-based querying
✅ Filters deactivated users
✅ Graceful fallback logic

But even with all these improvements… the question remains:

> **How much can you actually cache before you need to refresh it?**

Spoiler: A _lot_, but not everything. And certainly not forever.

## The Real Pain

This was _one_ function.
I’ve got dozens more: `completeMiniGame`, `getAllUsers`, etc.—all screaming for optimization and cache sanity.

And the worst part? **Support is… nonexistent.**
I’ve reached out on Discord. Sent emails. Nothing. I’m hoping someone from the Convex team sees this before I end up migrating the entire backend to something else.

## In Conclusion…

I’m still grinding away at this.
Still caching. Still querying. Still debugging.

But here’s the thing:

**Convex _is_ good.**
The folks who built it? Yeah, they helped scale Discord. That’s no small feat.
This isn’t some random weekend project—it’s a serious, ambitious backend platform designed for modern apps.

But here’s the catch:

> It _looks_ simple. It _feels_ magical. But **it’s not easy.**

If you're going to build with Convex, **you need to understand how it works under the hood.**
One wrong use of `collect()`, a careless `args{}` structure, or an unoptimized query—and boom, you're stuck in debug purgatory like I was.

So, here’s my warning wrapped in love:

> **Convex is amazing—but not for noobs.**

It’s a journey. One that rewards performance-focused devs who care about architecture.
And if you're coming from the land of classic SQL with **PlanetScale** or **Microsoft SQL Server**, you’ll feel the difference. Those platforms are built like tanks. Convex is more like a spaceship—you need to know what every button does before you launch.

So yes—use Convex. But use it wisely.

Until then...

**Keep coding, nerds. Optimize everything. And may your cache never overflow.**

---

# Is Your Editor Ready for a New Competitor? My First Dive into Amazon's Kiro!

- **URL**: https://www.rafay99.com/blog/amazon-kiro-code-editor-first-impressions/
- **Published**: 2025-07-15
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess, WebDevelopment
- **Description**: New player in Town 

**Is Your Editor Ready for a New Competitor? My First Dive into Amazon's Kiro!**

Just when you thought your `node_modules` folder couldn't get any bigger, or your `.dotfiles` couldn't get any more complex, Amazon drops a new challenger into the code editor arena: meet **Kiro**! My immediate thought? "Do I _really_ need another editor?" (Spoiler: For a software engineer, the answer is almost always a resounding "yes, just to try it!")

It was yesterday, or perhaps the day before (time flies when you're debugging!), when a tweet `console.log()`-ed itself directly into my feed: Amazon had launched a brand-new code editor. And the name? **Kiro**. Seriously, how cool is that? It just _sounds_ like it belongs in your dev environment.

At the time, I was happily neck-deep in a Next.js application, implementing a full-blown blog system for a client using my trusty Cursor. My dev flow was smooth, components were rendering, and life was good. But as any curious engineer knows, a new tool on the block is like an unmerged `feature` branch – you just _have_ to check it out.

So, I did what any self-respecting tech enthusiast would do: I paused my current task (because, priorities!), closed Cursor, and fired up my browser. A quick Google search for "Amazon code editor" and boom, the first result was the official link. The best part? It's free to download, and available for Mac, Windows, and Linux! As a Windows user, I was thrilled; new toys to play with and, of course, fresh content ideas to spark!

Installation was a breeze. Upon launching Kiro, it smoothly prompted me to sign in with GitHub, followed by an option to import settings from VS Code. This, my friend, was a `git merge` I didn't know I needed! I hit "confirm," and Kiro started pulling in all my beloved config, extensions, and aesthetic preferences.

Now, I won't lie, the transfer felt like compiling `node_modules` from scratch – it took a _while_. But hey, good things come to those who wait (or whose `package.json` resolves successfully!). Once it was done, I reopened my Next.js project in Kiro, and everything just… clicked. It looked familiar, yet somehow, it felt refreshed. All my preferred settings were there, making the transition feel less like a context switch and more like an optimized `hot-reload`.

But here's the kicker, the `if/else` statement that truly defines Kiro: While it has that comforting VS Code vibe, there are some distinct differences that set it apart. And that, my fellow coders, is where the real fun begins.

## Two Modes, One Editor: Kiro's AI Architecture

Now, let's talk about the differentiating factor, the core architectural decision that sets Kiro apart from your standard text editor: its **Two Distinct AI-Powered Modes**. When you first launch a project in Kiro, you're presented with a choice, like a `switch` statement deciding your coding flow:

1. **Vibe Coding Mode**
2. **Spec Mode**

They might seem like two sides of the same algorithmic coin, distinct yet surprisingly complementary. Here's a glimpse of the initial UI, offering that crucial decision point:

![Kiro code editor interface showing modern UI](https://utfs.io/f/TViMykBJnLIJJfGJBZsDFGxVNZ0APiXuhYl5d6fE9OsC1WgT)

This choice isn't just cosmetic; it deeply influences your interaction model with Kiro's integrated AI. Let's `await` a deeper dive into each.

### Vibe Coding Mode: Your Pair Programmer on Steroids

True to its name, 'Vibe Coding Mode' feels like having an intelligent pair programmer right inside your editor. You provide input – perhaps a comment, a natural language instruction, or a code snippet – and Kiro's AI kicks in. It `indexes` your codebase (a recurring theme, as we'll discuss later) and proposes changes directly within your files.

The coolest part? It doesn't just `push` changes blindly. Kiro presents a dedicated 'Review Screen,' a kind of built-in `pull request` interface for AI-generated code. This is a game-changer!

![Code review screen in Kiro showing diff view](https://utfs.io/f/TViMykBJnLIJPaMeihVLsLrZugTCMA8pqE2aJXReGfHYn6wI)

As you can see from my testing, Kiro generated a demo file and some code. The power here lies in the control. You can examine every line, understand the proposed `delta`, and then explicitly approve the changes. Even better, if the AI veers off-track or introduces something you don't like, the `revert` process is incredibly smooth, right within the chat interface. It's like having an `undo` button for your AI's suggestions – a feature I absolutely `love`!

### Spec Mode: Engineering Beyond the Code

If 'Vibe Coding Mode' is your direct coding assistant, 'Spec Mode' is your full-stack project manager. This mode is a fascinating departure, aiming to tackle features from a higher altitude. You feed it a high-level requirement, and Kiro aims to:

- **Understand the input**
- **Generate a comprehensive plan**
- **Create design documentation**
- **Develop a detailed to-do list**
- **Formulate a step-by-step coding plan**

Only once you approve this entire `blueprint` does it even touch your codebase. I'm currently putting 'Spec Mode' through its paces by attempting to add a significant new feature to my application – something entirely outside my current skillset: **internationalization (i18n)**.

My `prompt` to Kiro was quite detailed, outlining a real-world scenario:

```
In this application, user language and country are stored in Convex. I want you to
retrieve the country and language, then use Google Translate with Next.js to
translate the entire application with the user's preferred language. Additionally,
provide the user with a choice in the user dashboard's settings section to switch
languages. This app will be launched globally (Europe, Asia, US, and other
regions), so I need this to be dynamic and ensure translation covers the dashboard,
admin panel, landing page, blog site, and everything in between.
```

The initial `parse` phase was genuinely impressive. Kiro indexed my entire codebase and generated incredibly detailed documentation based on my prompt. I was genuinely `shocked` by its ability to comprehend the existing project structure and produce such relevant `specs`. It felt like it was truly _understanding_ my code, not just pattern-matching. That, for a moment, made me believe this was the future!

However, the `implementation` phase has been… a journey. I kicked off the coding process hours ago. As I'm writing this, Kiro is _still_ `compiling` (or perhaps `transpiling`? I'm not sure what it's doing back there!) the translation functionality. It's been well over 30 minutes, and the progress bar seems stuck in a perpetual `pending` state. This brings us to some `runtime errors` in the Kiro experience.

## The Bugs and Bottlenecks: Where Kiro Needs a Patch

During my intensive testing, I've stumbled upon a few performance and stability issues that feel like unexpected `throw` statements in my otherwise smooth dev flow.

### 1. The Latency Lag: Slow Response Times

This is perhaps the most glaring issue. Whether I'm in Vibe Coding Mode waiting for a simple code change or in Spec Mode attempting a major feature, the response time is just… slow. Painfully slow. It often feels like the app has hung, entering a perpetual `await` state, and not loading extensions at all. The 30+ minute wait for my translation feature in Spec Mode is a testament to this, as I'm almost done writing this blog post, and the functionality isn't even close to being added!

### 2. Indexing Overload: The Perpetual `scan()`

Kiro seems to have a bit of an indexing obsession. After every major task initiation or perhaps even minor tweaks, it triggers another full codebase index. This constant re-indexing leads directly back to our first problem: more waiting. It's like a database performing a full table scan repeatedly, slowing down every subsequent `query`.

### 3. Extension Incompatibility: Missing `devDependencies`?

This one is truly bizarre. I rely on extensions like "Better Comments" for my code readability, and while they work perfectly in Cursor and VS Code, Kiro disables them, citing version number issues. This suggests a lack of robust extension compatibility or perhaps some underlying API differences that need to be addressed. It's a clear signal that Kiro still has some `dependencies` to resolve and `bugs` to squash before it feels truly production-ready.

## Kiro's Shining Features: The `pros` that Keep Me Hooked

It's not all `syntax errors` and `segmentation faults`! Despite the current challenges, Kiro definitely has some redeeming qualities that make it a compelling tool.

- **Seamless Migration:** The effortless import of settings from VS Code was a godsend. It made the initial transition incredibly smooth, preserving my preferred themes and configurations, which often don't translate well between other editors (looking at you, Cursor!).
- **Intelligent Error Handling:** Kiro does a decent job of flagging errors within the generated code and providing guidance. It's not a magical `debugger` that fixes everything, but it offers enough insights to make manual corrections a few clicks away.
- **The Power of AI (When It Works):** When Kiro's AI isn't bogged down by latency or indexing, the core concepts of Vibe Coding and Spec Mode are genuinely powerful. The idea of an AI understanding your project and generating plans or code suggestions with a review process is a `paradigm shift`.

Overall, despite its current performance quirks, the underlying experience and the direction Kiro is heading are promising.

## The Elephant in the Server Room: Pricing & Models

Here's the crucial `config` detail:

### Pricing

Currently, Kiro is operating under a glorious `free tier`. There are no costs associated with using it, which makes trying it out a no-brainer. However, like any good beta, a `pricing plan` is slated for the future. So, enjoy the free computation while it lasts!

### Models

For its powerful AI capabilities, Kiro is powered by **Claude 4** and **Claude 3.5**. These models are known for their advanced reasoning and code generation abilities. Their strong `tool-calling` features are undoubtedly what enable Kiro's impressive code understanding and generation. Use them while they're on the house!

## Final `return` Statement: My Kiro Verdict

So, where do I stand on Amazon's new challenger? I've been happily `coding` in Cursor for a while, but Kiro offered a genuinely fresh experience. While it certainly has its growing pains – particularly around performance and extension compatibility – the core AI features, especially the ambitious Spec Mode, demonstrate incredible potential.

Will Kiro replace my primary daily driver? Not for my day job, not yet. The current performance issues are too significant for mission-critical development. However, for my **side projects** where I can `experiment`, embrace longer iteration cycles, and _really_ push the boundaries of AI-assisted coding, Kiro has absolutely earned its spot as my go-to **second code editor**. It's a fascinating `beta` that every curious developer should `fork` and try out!

Untill then nerds and coders, enjoy the new Kiro experience!

---

# Understanding React Re-render Issues: Causes and Solutions

- **URL**: https://www.rafay99.com/blog/understanding-react-re-render-issues-causes-solutions/
- **Published**: 2025-07-14
- **Author**: Abdul Rafay 
- **Tags**: ThoughtsProcess, WebDevelopment
- **Description**: Explore the intricacies of React re-render issues in this comprehensive guide. Learn about the common causes of unnecessary re-renders, their impact on application performance, and effective solutions to optimize your React applications. Whether you're a beginner or an experienced developer, this post will equip you with the knowledge to tackle re-render challenges and enhance your coding practices.

## The Beginning: My React + Astro Dream Combo

React has always had a soft spot in my dev toolkit. It’s that reliable companion you keep going back to—versatile, powerful, and just fun to work with. Big names like [GitHub](https://github.com), [Netflix](https://netflix.com), and [Meta](https://meta.com) agree, and chances are, if you’ve built something cool lately, React was part of it.

So, when I decided to rebuild my personal site, I knew I wanted the best of both worlds—React’s flexibility with Astro’s insane performance. The result? A site that felt buttery smooth, snappy, and downright slick. Animations glided, the UI was crisp, and everything just... worked. You can check it out here: [rafay99.com](https://rafay99.com)

## But Then... Mobile Happened

On desktop, everything was 💯. But then I tried to show off my site on my phone and—ugh. Animations stuttered. Load times lagged. Something was... off. It wasn’t the masterpiece I had tested and polished for weeks.

I dove straight into dev mode: opened dev tools, replicated the bug, and started slicing through code like a chef on a deadline. My first guess? "Too much JavaScript." So I trimmed, refactored, and optimized the heck out of it. Things improved, yeah—but not enough. There was still this weird sluggishness, like a shadow lurking in the performance.

## The Turning Point: Theo, React-Scan & That 🔥 Video

Stuck in optimization limbo, I turned to the holy land: YouTube. That’s when I stumbled on a video by Theo (yep, [T3.gg](https://t3.gg/)). And man, it cracked the code for me—**React re-render issues**.

Seriously, if you're debugging weird slowdowns in React, just pause and watch this video. It opened my eyes:

That led me to a gem of a tool called **React-Scan**—a visual debugger that literally highlights re-renders on your screen. You can check it out here: [react-scan.com](https://react-scan.com/). It’s one of those “see it to believe it” tools.

## Wait… What Even _Are_ Re-render Issues?

Let’s simplify this. A **re-render** in React is React’s way of keeping the UI in sync with your state or props. That’s normal. But the problem starts when components **re-render unnecessarily**—basically doing work they don’t need to.

You update a tiny bit of state at the top level, and suddenly your whole component tree starts flashing like a Christmas tree. Why? Because React by default will re-render everything downstream.

Here are some common re-render traps:

- **Parent State Changes**: When state changes in a parent, all children re-render—even if they don’t care.
- **Props Identity Changes**: If you're passing down objects or functions inline (like `onClick={() => doThing()}`), React sees a _new_ prop every time. Boom—re-render.
- **Context Updates**: Even a tiny change in context will trigger re-renders in _every_ consuming component.
- **New References**: Arrays, objects, functions—if they’re freshly created in each render, React treats them as “new” even if their values are the same.

And here’s where **React-Scan** blew my mind. Look at this actual screen from my site, showing how many components were re-rendering for no reason:

Wild, right? No wonder mobile was lagging.

## Fixing It: Memoization to the Rescue

Once I pinpointed the issue, it was time to fight back. The quickest win? **`React.memo`**.

It’s a simple wrapper for your components that tells React, “Only re-render this if the props actually change.” Here’s the difference:

### Before Optimization

```jsx
const ParentComponent = () => {
  const [count, setCount] = useState(0);
  const [text, setText] = useState("Hello");

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>Increment</button>
      <input value={text} onChange={(e) => setText(e.target.value)} />
      
      
    </div>
  );
};
```

Even changing just the count will re-render both children. Not good.

### After Adding `React.memo`

```jsx
const ChildComponentA = React.memo(({ text }) => {
  console.log("ChildComponentA rendered");
  return <h2>{text}</h2>;
});

const ChildComponentB = React.memo(({ count }) => {
  console.log("ChildComponentB rendered");
  return <h2>Counter: {count}</h2>;
});
```

Now, each child only re-renders if **its** prop changes. Massive improvement.

But keep in mind: `React.memo` only does a shallow comparison. If you're passing objects/functions, use `useMemo` and `useCallback` to keep the reference the same across renders.

## The Future Is Brighter with React 19

React 19 is coming in hot—and it’s fixing a lot of this stuff _for you_. Here’s what’s exciting:

- **Automatic Batching**: React groups multiple state updates into one render. Less waste.
- **Better Memo Defaults**: They're improving how components are memoized behind the scenes.
- **The React Compiler (React Forget)**: This is the real game-changer. It adds memoization at **compile time**. No more wrapping every component in `React.memo` or manually optimizing props. Just write normal code—React will handle the rest.

It’s like having a built-in performance engineer watching your code and doing the hard work for you.

## Wrapping Up: Lessons Learned

This whole journey—from perfect desktop performance to janky mobile issues—was a wake-up call. React performance isn’t just about using fewer libraries or trimming JS. Sometimes, it’s about what’s happening _under the hood_.

What I learned:

- Use tools like **React-Scan** to visualize re-renders.
- Apply `React.memo` smartly.
- Lean on `useMemo` and `useCallback` for reference stability.
- Keep an eye on **React 19**—it’s going to automate a lot of these pain points.

And most importantly? **Test on mobile early.** That’s where performance issues hit hardest.

---

# Cursor's Pricing Shock: The End of Unlimited AI and What Devs Need to Know

- **URL**: https://www.rafay99.com/blog/cursor-unlimited-ai-cost-shock/
- **Published**: 2025-07-10
- **Author**: Abdul Rafay
- **Tags**: AI, ThoughtsProcess
- **Description**: Was your 'unlimited' AI editor suddenly not so unlimited? Dive into the recent Cursor pricing controversy to understand why AI inference costs are soaring, why the 'free lunch' is over, and what this means for the future of your dev tools.

Oh boy, we have a lot to dive into here, don't we? If you've been following the AI development scene, chances are you've heard the recent ruckus around Cursor, the AI-first code editor. What started as whispers quickly turned into a full-blown uproar, with developers feeling a mix of confusion, frustration, and maybe a tiny bit of "I don't know if I should cry or laugh."

Just 12 days after Cursor proudly announced an "unlimited" plan for a sweet $20 a month, users started getting hit with unexpected charges, sometimes topping $100 in usage. Imagine paying for your usual $20, making a couple of requests, and BAM! Limit reached. Subscriptions were canceled faster than you can say "bug fix."

This isn't just a minor hiccup; it feels like a significant challenge for an editor that many have come to appreciate. Let's unpack this mess honestly, because this isn't solely about Cursor's fumble; it's a harbinger of how AI services are likely to be priced moving forward, and it's going to shake things up for many of us.

### The "Unlimited" Bait and Switch (or, A Massive Communication Blip)

To put it simply: Cursor promised "unlimited" for $20, then people got billed for usage. Ouch.

Previously, Cursor's $20 plan offered a pretty sweet deal: 500 "fast" requests a month (think powerful models like Claude 4, Sonnet, GPT-4), plus _unlimited_ "slow" requests and tab completes. It felt generous.

Then came the "new pricing." Instead of 500 fast requests, users would get $20 worth of API credit from various models, _and_ unlimited access to "auto" mode. Now, "auto" mode is clever – it picks the cheapest and fastest model for your task, optimizing costs for the provider. But if you manually selected a premium model like Claude Sonnet? That's where the meters started running.

The problem wasn't necessarily the pricing change itself, but the clarity (or lack thereof) in its communication. Users, understandably, saw "unlimited" and thought "unlimited _everything_." Cursor meant "unlimited _auto_." That's a crucial difference, and a lot of folks got burned with bills they never saw coming.

### The Elephant in the Room: AI Inference is NOT Cheap

Why the sudden shift? Why did a $20 plan suddenly become a financial black hole for some power users? It boils down to the actual cost of running these advanced AI models.

**Let's talk tokens:** AI isn't billed per message; it's billed per "tokens" – think of them like syllables or tiny chunks of text. You pay for input tokens (what you send to the AI) and output tokens (what the AI generates back). Output tokens are _way_ more expensive because that's where the actual "thinking" and "generating" happens.

Consider Claude Sonnet: ( $3 ) per million input tokens, ( $15 ) per million output tokens. That adds up faster than you can type `git commit -m "oops"`!

**The Rise of Reasoning and Agent Modes:**
Historically, AI models had fewer output tokens. Bills were mostly driven by input. But then came "reasoning" models and "agent" modes. When an AI "thinks," it's actually generating internal monologue – more output tokens! When it uses tools or loops in agent mode, each step is a separate "message" with more context and more output.

The average cost per "message" in a tool like Cursor has skyrocketed. What used to cost pennies can now easily hit ( $0.50 ) or more _per message_. If a service initially priced based on an average ( $0.03 ) per message, 500 messages cost the provider ( $15 ). Now, at ( $0.50 ) per message, those same 500 messages would cost the provider ( $250 )! That's a massive hole in their pocket.

Model providers themselves, like Anthropic, face substantial costs. Offers for enterprise-level usage, even with committed spend, might only yield small discounts. GPUs, electricity, servers – these foundational costs are significant and don't budge much, no matter who you are. This means that the real cost of running these powerful models has been consistently climbing, especially as they get more sophisticated.

### Communication: A Missed Opportunity

Even with the rising costs, Cursor's communication around this change was, frankly, a bit of a faceplant.

1. **Lack of Clarity:** The blog post announcing the changes wasn't clear enough about the transition or the continued option to stay on the old 500-request limit. The crucial "at least $20 of model inference at API prices" detail was initially unclear or added later.
2. **No Transparency:** The biggest miss? The _dashboard_. As a user, one needs to know where they stand. How much credit has been used? How many requests until the limit is hit? When will usage reset? Cursor's dashboard offered minimal, hard-to-find information. It's like driving a car without a fuel gauge – you just don't know when you'll run out!
3. **Ownership:** Cursor's communication strategy has historically relied on community and individual employee outreach. While this can foster organic growth, it proves problematic during a crisis. The company lacked the direct channels and clear, unified voice to address the outrage quickly and effectively.

### Cursor's Apology and the Path Forward

To their credit, Cursor did respond. On July 4th (a national holiday in the US, which some speculated was a tactic to bury the news, but was more likely a rushed attempt to address a growing problem), they posted an apology, owned their communication failure, and offered full refunds for unexpected charges incurred between June 16th and July 4th.

They've also promised clearer documentation, advanced notices for future changes, and improved visibility in the dashboard. These are crucial steps, but as many users feel, it was a bit "too little, too late" for the initial rollout, highlighting the importance of proactive, transparent communication.

### The Hard Truth: There's No Free Lunch in AI (Anymore)

This whole Cursor saga isn't unique. It highlights a critical shift in the AI industry: **the subsidy era is ending.**

For a while now, many AI services have been operating as "loss leaders." Companies, backed by massive funding, have been selling AI inference for less than it costs them, all to capture users. Think of it like ride-sharing or food delivery apps in their early days – artificially low prices to win market share.

But that can't last forever. GPUs, electricity, servers – running these powerful models is expensive. When Anthropic offered Anthropic Max for ( $200 ) a month, providing "unlimited" Claude Code usage, they could do it because they own the models and their infrastructure, and they can offset those costs by selling their models to other services (like Cursor!) at higher rates. Plus, most users won't actually hit those astronomical limits.

Cursor, however, doesn't own the foundational models. They pay API providers like Anthropic, OpenAI, and Google. Their margins are thinner, and when the average cost per message skyrockets, their previous ( $20 ) pricing model becomes a huge liability.

So, if you're thinking of jumping ship to a "cheaper" alternative like Claude Code or a "free" one like Gemini CLI:

- **Claude Code's ( $200 ) tier:** While generous, it's designed to capture power users by eating costs. But how long can _that_ last if model prices keep climbing?
- **Gemini CLI:** It's free now, thanks to Google's deep pockets and their own silicon, but it's reasonable to assume that won't be the case indefinitely.

We're moving past the point where you can reliably get ( $500 ) worth of AI for ( $20 ), unless it's from a Frontier model company that is willing to continue eating those costs for a bit longer.

### The Power User Conundrum: A Lesson for Everyone

Here's another crucial point: **you have to keep your power users happy.**

The developers who are hitting those high usage limits are often the enthusiasts, the evangelists. They're the ones posting on Twitter, telling their colleagues, and bringing _more_ users into the ecosystem. The majority of those new users might not be power users, meaning they won't cost much. This balance is key.

Cursor, by trying to stop their top 0.1% users from costing them hundreds of dollars, might have inadvertently alienated their most vocal champions. If those champions switch to another service, others will follow, even if their own usage wouldn't have pushed them over Cursor's limits.

### Conclusion and Final Thoughts

The Cursor pricing debacle serves as a harsh, yet valuable, lesson for both AI tool providers and users. It peels back the curtain on the true, often high, costs of running sophisticated AI models, revealing that the "free lunch" or heavily subsidized era is indeed drawing to a close.

For AI companies, the takeaway is clear: transparency and user communication are paramount. Shipping significant pricing changes without clear, upfront explanations, intuitive dashboards to monitor usage, and proactive support is a recipe for user confusion and backlash. While balancing rising infrastructure costs with competitive pricing is an immense challenge, alienating a loyal user base through poor communication can be an even greater threat to long-term success. The value of an AI tool may well exceed its stated price, but the uncertainty of hidden costs can undermine that perceived value entirely.

For developers and users, this situation highlights the need to understand the underlying economics of the AI tools we rely on. Expect to see more usage-based or tiered pricing models as companies seek sustainable ways to offer increasingly powerful and expensive AI capabilities. While the initial sticker shock might be real, the value proposition of these tools, when leveraged effectively, often outweighs the cost. The key is knowing what you're paying for and having the visibility to manage your own usage.

This situation isn't about "Cursor being bad and trying to make more money." It's about the complex, evolving landscape of AI services trying to find sustainable business models while still delivering groundbreaking technology. The journey will undoubtedly have more bumps along the road, but clear communication will be the ultimate guide.

What are your thoughts on this whole situation and the future of AI pricing? Share your perspectives in the comments below!

Until next time, peace nerds! 🚀

---

# MarkdownPro: No More Markdown Mayhem!

- **URL**: https://www.rafay99.com/blog/markdownpro-tech-story/
- **Published**: 2025-06-27
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess, WebDevelopment
- **Description**: A powerful markdown editor with real-time preview, supporting GitHub-flavored markdown syntax and seamless file conversion capabilities.

## The Markdown Tango: When Creativity Hits a Snag

You know that feeling, right? You're buzzing with an idea, ready to churn out some awesome documentation, a new blog post, or maybe just some organized notes. You reach for Markdown, because, well, it's elegant, simple, and universal. Or so we thought.

But then, the tango begins – and sometimes, it's a bit of a clumsy one.

- **The Preview Predicament:** You're writing, but you're constantly alt-tabbing to see if your headings actually look like headings, or if that bullet list decided to go rogue. Real-time? More like _real-pain_.
- **The Consistency Conundrum:** Markdown files rendered perfectly on your machine look... "different" on someone else's. It's like everyone's using a slightly different dialect of Markdown.
- **The Setup Shuffle:** Want a decent Markdown editor? Great! Now, spend an hour installing dependencies, tweaking configs, and fighting with themes. Who has time for that when inspiration strikes?
- **The "Aesthetic" Abyss:** Many tools feel like they're stuck in the early 2000s. Where's the modern UI? The dark mode that doesn't feel like an afterthought?
- **The Conversion Conundrum:** You've got your beautiful Markdown, but now you need it as HTML, PDF, or something else. Suddenly, you're hunting for converters that often break your formatting.

This, my friend, was the problem space we saw, a gaping void begging for a modern solution.

## MarkdownPro: Our Digital Canvas Unleashed!

And so, the idea for [MarkdownPro](https://markdown-pro-two.vercel.app/) was born! Imagine a web-based Markdown editor and converter that just… works. No fuss, no muss, just pure, unadulterated productivity wrapped in a sleek, responsive design.

We envisioned MarkdownPro as the Swiss Army knife for Markdown, cutting through those common frustrations with precision and elegance. It's about giving developers, writers, and anyone who loves Markdown a seamless experience from thought to polished output.

## Under the Hood: Our Tech Toolkit

Building MarkdownPro wasn't just about solving problems; it was about having _fun_ with our favorite tech! We grabbed our go-to tools to craft a robust, type-safe, and speedy application:

### The Frontend Foundation

- **React + TypeScript**: Because catching those sneaky bugs _before_ they hit production is a superpower! Type safety gives us that confidence.
- **Vite**: When you want development builds that compile faster than your coffee brews, Vite is your champion. Plus, optimized production builds? Yes, please!
- **TanStack Query**: For wrangling data like a pro. Think efficient caching and background updates that keep our UI snappy without us even trying.

### The Style Superpowers

- **Tailwind CSS**: Utility-first styling is a game-changer. Responsive design becomes a breeze, and our components look consistent without endless CSS files.
- **Shadcn/ui**: For those ready-to-rock, accessible, and beautiful UI components. Why reinvent the wheel when you can have a well-oiled one?
- **Theme Transitions**: Because a smooth light-to-dark mode switch isn't just eye candy; it's a delightful user experience!

### The Core Capabilities: Making it Happen

MarkdownPro's heart lies in its ability to bring your Markdown to life:

1. **Real-time Preview:** See your Markdown as you type, instantly. No more guessing games! We're talking split-screen bliss and full GitHub-flavored Markdown support.
2. **Dynamic Theme System:** Light, dark, or custom? MarkdownPro adapts to your mood. And yes, those transitions are buttery smooth, thanks to persistent preferences.
3. **Seamless File Operations:** Drag, drop, convert, download. Whether it's a quick note or a lengthy document, MarkdownPro handles it. Oh, and auto-save? You bet! Your masterpieces are safe.
4. **Modern UI/UX:** From responsive layouts that shine on any device to intuitive navigation and timely toast notifications, it's designed to be a joy to use.

## The Developer's Journey: From Code to Cloud

Our development workflow was all about efficiency and iteration, allowing us to rapidly prototype and refine features. And when it came to deployment, we wanted something equally effortless.

We chose **Vercel** for its magic touch: automatic HTTPS, global CDN for blazing-fast access, and deployments so instant they feel like magic. It's where MarkdownPro truly lives and breathes.

You can experience the live application yourself: [https://markdown-pro-two.vercel.app/](https://markdown-pro-two.vercel.app/)

## Peeking Under MarkdownPro's Hood: The Technical Deep Dive

Alright, fellow tech enthusiast, let's pull back the curtain and see how the bits and bytes dance together to make MarkdownPro sing!

### Project Blueprint: Where Everything Lives

Keeping a project organized is key to sanity, right? Our structure is pretty standard for a React app, making it easy to navigate and expand:

```
markdown-pro/
├── public/                 # Static assets
├── src/
│   ├── assets/             # Images, icons, fonts
│   │   ├── ui/             # Shadcn/ui components
│   │   └── common/         # Custom common components
│   ├── hooks/              # Custom React hooks
│   ├── lib/                # Utility functions, helpers
│   │   ├── api/            # API service calls (if any)
│   │   ├── converters/     # Markdown to other formats
│   │   ├── storage/        # Storage utilities
│   │   └── utils.ts        # General utilities
│   ├── pages/              # Main application views/routes
│   │   ├── Editor.tsx
│   │   └── Converter.tsx
│   ├── styles/             # Tailwind CSS entry, global styles
│   ├── contexts/           # React Context providers (e.g., ThemeContext)
│   ├── types/              # TypeScript custom types/interfaces
│   ├── App.tsx             # Main application component
│   ├── main.tsx            # Entry point
│   └── vite-env.d.ts       # Vite environment types
├── index.html              # Main HTML file
├── package.json            # Dependencies and scripts
├── tsconfig.json           # TypeScript configuration
├── postcss.config.js       # PostCSS configuration
├── tailwind.config.js      # Tailwind CSS configuration
└── ...
```

This clean structure allows us to scale and maintain our codebase with ease.

### The Data Symphony: How Information Flows

Our data flow is a well-orchestrated ballet, ensuring responsiveness and consistency:

```mermaid
graph TD
    A[User Interaction: Type, Drag, Click] --> B[React Components]
    B -- State Updates --> C[State Management]
    C -- Debounced update --> D[Markdown Parsing / Conversion]
    D -- Render HTML --> E[Real-time Preview Component]
    C -- Persistent Storage --> F[Local Storage / IndexedDB]
    F -- Load / Hydrate State --> C
    B -- File Operations --> G[Browser File API]
    G -- Pass data --> D
```

From user input to parsed output, we've designed a path that keeps things flowing smoothly.

### Storage Strategy: No Data Left Behind!

We believe your content should be safe, whether it's a small draft or a colossal document. That's why MarkdownPro leverages a multi-pronged storage approach:

1. **Local Storage: The Quick Jot Pad**
   For settings, themes, and smaller drafts, `localStorage` is perfect. It's fast and persistent across sessions.

```typescript
// storageUtils.ts implementation for persistent data
interface StorageItem {
  content: string;
  lastModified: number;
  type: "draft" | "template";
}

  try {
    localStorage.setItem(key, JSON.stringify(data));
  } catch (error) {
    // Fallback to IndexedDB if localStorage is full
    // This is a subtle but important detail for robustness!
    saveToIndexedDB(key, data);
  }
};
```

1. **IndexedDB: The Digital Vault for Giants**
   When you're dealing with potentially large Markdown files, `localStorage` can hit its limits. Enter `IndexedDB`, a robust, client-side NoSQL database ideal for storing substantial amounts of structured data.

```typescript
// IndexedDB implementation for larger files
wrapper for IndexedDB

const DB_NAME = "MarkdownProDB";
const STORE_NAME = "documents";

  const db = await openDB(DB_NAME, 1, {
    upgrade(db) {
      // Create an object store for our documents
      db.createObjectStore(STORE_NAME);
    },
  });
  return db;
};

// ... (functions to save and retrieve from IndexedDB would follow)
```

This two-tiered approach ensures we're always choosing the right tool for the job.

### Component Choreography: The Editor's Dance

Our `Editor` component isn't just one monolithic block; it's a team of specialized performers working in harmony:

```mermaid
graph TD
    A[EditorParentComponent] --> B(MonacoEditorInstance)
    A --> C(PreviewComponent)
    A --> D(ToolbarComponent)
    A --> E(FileOperationsComponent)
    B -- Editor Content --> A
    A -- Debounced Content Update --> C
    C -- Rendered HTML --> PreviewComponentUI
    D -- Toolbar Actions --> B
    E -- File Upload/Download --> A
    A -- Conversion Trigger --> FileProcessorService
```

This modularity makes development a breeze and debugging a less daunting task.

### Theme System: A Symphony of Colors and Transitions

Who wants a boring workspace? Our theme system is built for beauty and fluidity. We use CSS variables, which makes runtime theme switching incredibly efficient:

```typescript
// Theme configuration and management
interface ThemeConfig {
  value: string;
  label: string;
  colors: {
    background: string;
    primary: string;
    text: string;
    // ... other color tokens
  };
  transitions?: {
    type: 'circular' | 'geometric' | 'liquid'; // Fancy animation types!
    duration: number;
  };
}

// Theme provider implementation

  const [theme, setTheme] = useState(defaultTheme);

  useEffect(() => {
    // Apply theme tokens to CSS variables
    // This is the magic! CSS variables allow for super smooth transitions.
    Object.entries(theme.colors).forEach(([key, value]) => {
      document.documentElement.style.setProperty(`--${key}`, value);
    });

    // We could also trigger special transition animations here if 'transitions' is defined
    // For example, by adding a class to <body> or a root element
    if (theme.transitions) {
      document.documentElement.setAttribute(
        'data-theme-transition',
        theme.transitions.type
      );
    } else {
      document.documentElement.removeAttribute('data-theme-transition');
    }

  }, [theme]);

  return (
    
      {children}
    
  );
};
```

This setup allows for dynamic styling without constant re-renders or complex state logic. Just pure CSS magic!

### The File Processing Pipeline: From Markdown to Masterpiece

Converting Markdown to various formats is a core feature, and we've built a robust pipeline for it:

```mermaid
graph TD
    A[User Uploads/Enters Markdown] --> B(Content Parser: markdown-it / marked)
    B -- AST / HTML Output --> C(Formatter/Transformer)
    C -- Optimized HTML --> D(Conversion Modules)
    D -- Converted Output --> E[User Download / Preview]
    subgraph Web Worker for Heavy Lifting
        B --- C
    end
```

Using Web Workers for heavy parsing means our main thread stays free and responsive – no more frozen UIs during complex conversions!

### Performance: Because Speed Matters!

Nobody likes a slow app, especially a developer. We baked in performance optimizations from day one:

1. **Code Splitting:** Why load everything at once? We dynamically import components as needed, drastically reducing initial load times.

```typescript
  // Dynamic imports for route-based code splitting
  const Editor = lazy(() => import('@/pages/Editor'));
  const Converter = lazy(() => import('@/pages/Converter'));

  // Route configuration with Suspense for loading states
  
    }>
          {/* Show a spinner while the component loads */}
          
        
      }
    />
    }>
          
        
      }
    />
  
```

1. **Debounced Preview Updates:** Typing fast? MarkdownPro isn't frantically re-rendering with every single keypress. We debounce updates, waiting for a pause in typing before parsing. It's like telling the preview, "Hold your horses, let the user finish their thought!"

```typescript
// Debounced preview updates
// A handy utility for debouncing

const usePreviewUpdate = (content: string) => {
  const [preview, setPreview] = useState("");

  useEffect(() => {
    const handler = debounce(async () => {
      // The actual heavy lifting (markdown parsing) is done here
      const html = await markdownToHtml(content);
      setPreview(html);
    }, 150); // Wait 150ms after the last keypress

    handler(); // Call handler immediately on content change
    return () => handler.cancel(); // Clean up the debounce timer
  }, [content]); // Re-run effect if content changes

  return preview;
};
```

This seemingly small detail makes a huge difference in the perceived responsiveness of the editor.

### Error Handling & Recovery: When Things Go Sideways

Even the best code can encounter unexpected issues. We've put systems in place to gracefully handle errors and keep the user experience smooth:

```mermaid
graph TD
    A[User Action / Data Fetch] --> B{Try-Catch Blocks / Error Boundaries}
    B -- Error Detected --> C[Log Error]
    B -- Error Detected --> D[Display User-Friendly Toast Notification]
    D -- User Clicks Retry --> A
    subgraph Data Persistence
        E[Auto-Save Mechanism] --> F[Local Storage / IndexedDB]
        F -- Data Integrity Checks --> G[Data Recovery Prompt]
        G -- User Accepts Recovery --> H[Restore Previous State]
    end
```

From network glitches to parsing failures, MarkdownPro aims to inform, recover, and keep your data safe.

### State Management: The Conductor of Our Orchestra

For MarkdownPro, a blend of state management techniques keeps everything in harmony:

1. **Document State:** For the editor content, metadata, and user settings, we rely on local React state (via `useState`/`useReducer`) and the Context API for sharing globally.

```typescript
interface DocumentState {
  content: string;
  metadata: {
    title: string;
    lastModified: Date;
    format: "markdown" | "html" | "pdf";
  };
  settings: {
    autoSave: boolean;
    previewEnabled: boolean;
    theme: string;
  };
}
// This state would typically be managed by a useContext hook or a reducer
// For example: const [document, setDocument] = useReducer(documentReducer, initialDocumentState);
```

1. **Query Management with React Query:** For data that needs caching, background re-fetching, and synchronization, `TanStack Query` (formerly React Query) is our go-to. It simplifies async data operations immensely.

```typescript
// Document fetching with React Query
const useDocument = (id: string) => {
  return useQuery({
    queryKey: ["document", id], // Unique key for this query
    queryFn: async () => {
      const doc = await loadFromStorage(id); // Our storage utility
      if (!doc) {
        throw new Error("Document not found"); // Handle not found case
      }
      return doc;
    },
    staleTime: 5 * 60 * 1000, // Data is considered "fresh" for 5 minutes
    // During staleTime, if user re-focuses, data won't re-fetch unnecessarily
    // After staleTime, data is refetched in background on re-focus
  });
};
```

This combination gives us fine-grained control and incredible performance for different data needs.

## The Road Ahead: What's Next for MarkdownPro?

We're just getting started! The future of MarkdownPro is brimming with exciting possibilities:

- **Collaboration Features:** Imagine real-time co-editing, sharing documents with comments and annotations. Markdown collaboration, unlocked!
- **Advanced Export Options:** More formats, custom templates for truly personalized outputs, and even batch processing for your entire Markdown library.
- **Deeper Integrations:** Git integration, seamless cloud storage sync, and even an API for developers to build on top of MarkdownPro.

## Conclusion: A Love Letter to Modern Web Dev

MarkdownPro isn't just an editor; it's a testament to the incredible power of modern web technologies. It showcases how a thoughtful blend of React, TypeScript, utility-first CSS, and intelligent state management can solve real-world problems and create truly delightful user experiences.

By obsessing over performance, user-friendliness, and future extensibility, we've crafted a tool that makes Markdown editing accessible, efficient, and dare I say, _fun_ for everyone. It's a project that truly embodies the spirit of building with joy!

**Ready to unleash your Markdown magic?** ✨

Try it yourself right now at [https://markdown-pro-two.vercel.app/](https://markdown-pro-two.vercel.app/) and let us know what you think! I'm always curious to hear from fellow builders.

---

# Client-Side Mermaid Diagrams in Astro + React: No Server Needed

- **URL**: https://www.rafay99.com/blog/client-side-mermaid-diagrams-astro-react/
- **Published**: 2025-06-26
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess, WebDevelopment
- **Description**: How to render Mermaid.js diagrams client-side in an Astro + React app — no SSR hydration issues, no server-side rendering bugs, just clean diagrams that work on Vercel.

You know that moment. You’ve spent weeks building a blog or a portfolio you’re genuinely proud of. You test it locally, and everything looks perfect — animations, diagrams, responsiveness, all silky smooth. You deploy, expecting applause. But instead, you get build logs filled with cryptic errors and dependency hell. That’s exactly what happened to me when I decided to add **dynamic Mermaid.js diagrams** to my Astro-powered portfolio and blog.

Locally, it was a dream. Beautiful flowcharts and sequence diagrams rendered straight from fenced code blocks like ` ```mermaid ` — all converted into SVGs during the build process using Playwright.

But the second I hit deploy on Vercel?

> The dream turned into dependency purgatory.

## The Original Idea: Server-Side Rendering with Playwright

The concept was straightforward (in theory):
Use [Playwright](https://playwright.dev/) during the build step to convert Mermaid code blocks into static SVGs. This would mean:

- **No Mermaid.js bundle on the client**
- **Diagrams pre-rendered into the final HTML**
- **No runtime dependency for rendering**

So I added Playwright as a dependency, included a `postinstall` script to install the necessary browsers, and wrote a script that would scan Markdown content during the Astro build and render diagrams.

```json
"scripts": {
  "postinstall": "npx playwright install"
}
```

This works great on your machine where `apt-get` exists and dependencies like `libnss3` and `libx11` are just a `sudo` away. But then Vercel laughed.

## The Error Logs That Broke My Soul

Here’s what greeted me on deploy:

```bash
[23:21:07.099] sh: line 1: apt-get: command not found
[23:21:07.106] Failed to install browser dependencies
[23:21:07.107] Error: Installation process exited with code: 127
```

No `apt-get`, no system libraries, and absolutely no way for Playwright to run in the sandboxed Vercel environment. I even tried moving things into `vercel.json`:

```json
{
  "build": {
    "env": {
      "INSTALL_PLAYWRIGHT_DEPS": "1"
    },
    "installCommand": "npx playwright install chromium"
  }
}
```

Still, the build failed during the actual execution — Playwright couldn’t launch its headless browser.

## Temporary Fix: The Feature Flag Nobody Talks About

I hated doing this — but I disabled the diagram rendering altogether behind a feature flag just to get the blog live. That was my lowest point.

I had the content. I had the code. I had the visuals. But I couldn’t get them past the build system.

So I stopped trying to force it.

## The Turning Point: What If the Client Did the Work?

Here’s the shift in mindset:

> _Why am I bending over backwards trying to make the server render something the client is fully capable of doing?_

That’s when I decided to flip the architecture entirely.

Instead of generating diagrams on the server, I’d render them **dynamically in the browser using React**. And honestly? It worked better than I expected.

## Building the `MermaidRenderer` React Component

I rewrote the logic as a proper `MermaidRenderer.tsx` component. The component does the following:

1. **Watches for code blocks** with `language-mermaid` class.
2. **Dynamically imports Mermaid.js** to keep the bundle size lean.
3. **Renders diagrams** using `mermaid.render`.
4. **Injects React buttons** into each diagram (copy to clipboard, fullscreen view).
5. **Listens for DOM changes** using `MutationObserver` to handle lazy-loaded content or content rendered later.

Here’s the rough structure:

```tsx
useEffect(() => {
  if (!mermaidInitialized) return;

  const renderDiagrams = async () => {
    const mermaid = (await import("mermaid")).default;
    const blocks = document.querySelectorAll(
      "pre code.language-mermaid:not([data-mermaid-rendered])",
    );

    for (let i = 0; i < blocks.length; i++) {
      const code = blocks[i].textContent;
      const svg = await mermaid.render(`diagram-${i}`, code);

      // Replace <pre><code> with the new SVG and inject buttons
      // ...
    }
  };

  renderDiagrams();

  const observer = new MutationObserver(/* watch for new content */);
  observer.observe(document.body, { childList: true, subtree: true });

  return () => observer.disconnect();
}, [mermaidInitialized]);
```

I also used `ReactDOM.createRoot` to inject the diagram buttons into each SVG block — buttons for fullscreen mode and clipboard copy.

And yes, the Mermaid theme is styled with my Tokyo Night color palette. 😎

---

## The UX Wins

Switching to client-side rendering gave me more than just a successful deployment:

- **No More Build Failures:** Vercel now builds flawlessly. My `npm run build` is back to being boring, as it should be.
- **User Interactivity:** I added features like full-screen viewing and instant SVG copy. This would’ve been painful with server-rendered diagrams.
- **Performance:** Mermaid.js is lazy-loaded. The script doesn’t even load unless there’s a Mermaid diagram present.
- **Future-Proofing:** With React 19 and its new compiler optimizations, performance is only getting better. This setup already benefits from hooks like `useCallback` and `memo`.

---

## The Architecture in Practice

Now, whenever a blog post has Mermaid code blocks, the following happens:

1. The `MermaidRenderer` component activates on the client.
2. It lazy-loads Mermaid.js.
3. It parses the DOM for unrendered Mermaid blocks.
4. It renders them into SVGs.
5. React buttons (copy, fullscreen) are injected into each SVG container.
6. The entire process runs _after_ the page has loaded, without blocking the initial render.

---

## Final Thoughts: When to Stop Fighting the Build System

This whole experience taught me a valuable lesson:

> If your server-side setup is fragile, and the browser can handle it — let the browser do it.

Instead of brute-forcing headless rendering with Playwright, I leaned into the strengths of client-side React. Not only did it solve the problem, it made the solution better, faster, and more interactive.

So next time you're debugging a server-side issue and nothing seems to work, ask yourself:

**"Is this really the server’s job?"**

You might find your answer — and your sanity — on the client side.

---

# The Silent Assassin: How Partytown Swallowed My Google Ads and What I Learned About Threads

- **URL**: https://www.rafay99.com/blog/astro-vercel-gtm-fix-without-partytown/
- **Published**: 2025-06-24
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess, WebDevelopment
- **Description**: How I fixed GTM and Ads not working on Vercel by removing Partytown in my Astro project.

Deployment is usually the celebratory finish line, right? But for me recently, pushing my Astro-powered portfolio to Vercel turned into a frustrating detective story. My carefully placed Google Ads and Analytics tags? Invisible. Just... gone. It was baffling, especially since everything worked perfectly on my local machine. After weeks of head-scratching, the culprit finally revealed itself: a seemingly innocent optimization called Partytown.

Let's break down the mystery, the debugging journey, and the crucial lesson learned about browser threads and web workers.

## The Problem: Ads Gone Missing, Analytics Misfiring

My Astro site was live, looking great, but a quick check confirmed my worst fear: no Google Ads were rendering. Analytics data was also sparse, indicating my tracking tags weren't firing consistently. This wasn't a styling issue; it was deeper. The scripts themselves weren't executing as expected.

My gut told me it had something to do with performance. I had recently integrated `@astrojs/partytown` to optimize third-party scripts. Partytown is a fantastic tool designed to move performance-heavy scripts off the main browser thread. On paper, it's brilliant for site speed. In practice, it was silently breaking my Google tags.

## A Quick Detour: Understanding Browser Threads and Web Workers

Before we dive into how Partytown caused the headache, let's quickly explain the key concepts:

1. **The Browser's Main Thread (The Busy Chef):**
   Imagine your browser tab as a bustling kitchen. The **main thread** is the head chef. This chef is responsible for _everything_ you see and interact with:
   - Rendering the UI (drawing pixels, laying out elements)
   - Handling user interactions (clicks, scrolls, typing)
   - Running JavaScript that interacts with the page (DOM manipulation, event listeners)
   - Fetching resources
     If this chef gets too busy (e.g., running heavy, blocking scripts), everything else slows down or freezes, leading to a "janky" user experience.
2. **Web Workers (The Dedicated Prep Cooks):**
   Now, imagine your head chef hires some specialized **prep cooks**. These are **Web Workers**. They work in a separate, isolated area of the kitchen (a separate thread) and can do heavy-lifting tasks without bothering the main chef:
   - Performing complex calculations
   - Processing large amounts of data
   - Making network requests
     The critical limitation? These prep cooks **cannot directly touch the food on the main chef's line.** They can't directly manipulate the UI, access the `window` object of the browser tab, or read/write to the DOM. If they need something from the main chef, or need to send something back, they have to communicate via messages.
3. **Partytown (The Smart Expediter):**
   This is where Partytown comes in. Think of Partytown as a super-efficient expediter. Its job is to take third-party scripts (like Google Analytics, Google Ads, social media widgets) and, instead of letting them run on the main thread, it shunts them over to a Web Worker. It then _proxies_ their calls back and forth to the main thread, trying to make it seem like they're running there. This frees up the main chef to focus on giving users a smooth experience.

## The Debugging Process: Unmasking the Culprit

My debugging was less about reading cryptic error messages (because there weren't many obvious ones!) and more about systematic elimination.

1. **Initial Hypothesis:** Could it be Partytown? It was the newest addition that touched script execution.
2. **The Simple Test:** The easiest way to confirm or deny was to remove Partytown from the equation.
   - I went into my `astro.config.mjs` file and commented out the Partytown integration:

```javascript
// astro.config.mjs
// // <--- Commented this out
// https://astro.build/config

  integrations: [
    react(),
    mdx(),
    tailwind(),
    sitemap(),
    // partytown({ // <--- Commented out the Partytown config block
    //   config: {
    //     forward: ["dataLayer.push", "gtag"],
    //   },
    // }),
  ],
  adapter: vercel(),
  output: "server",
  // ... other config
});
```

- Then, I removed the `data-partytown-sandbox` or `client:load` (or similar depending on your setup) attributes from my Google script tags, ensuring they would run directly on the main thread:

```html
<!-- Before (with Partytown) -->
<script
  async
  src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXX"
  data-partytown-sandbox="analytics"
></script>

<!-- After (without Partytown for this script) -->
<script
  async
  src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXX"
></script>
```

1. **The "Aha!" Moment:** I deployed this change to Vercel. My ads **immediately started rendering**, and my analytics data flowed as expected. That's when I knew: Partytown was the silent assassin.

## The Deep Dive: Why Google Tags Failed in a Web Worker

The problem lies in how sophisticated scripts like Google Analytics and Google Ads are built. They are **highly dependent on direct access to the browser's main thread `window` and `document` objects.** They expect to:

- **Read `window.location`, `document.referrer`, `document.cookie`:** For context, session tracking, and user identification.
- **Manipulate the DOM directly:** Google Ads, for instance, dynamically injects iframes and content into the page.
- **Listen to main thread events:** Like page load, scroll depth, clicks on elements, which are crucial for tracking user behavior.

While Partytown tries its best to proxy these calls from the Web Worker back to the main thread, this proxying isn't always perfect, especially for complex or highly time-sensitive interactions. There are subtle properties or timing expectations that the main thread's `window` object fulfills that a proxied version in a Web Worker simply cannot perfectly replicate. The scripts simply fail to initialize or execute their full logic due to this "missing environment."

## The Solution: Strategic Use of Optimization

So, what's the takeaway? Partytown is still a fantastic tool, but it's not a one-size-fits-all solution.

**My Solution:**
I made a pragmatic choice. For critical scripts like Google Ads and Analytics that _must_ run on the main thread to function correctly, I ensure they are **not** processed by Partytown. They run directly on the main thread, where they expect to be.

For other scripts that genuinely benefit from offloading – like my simple progress bar, or background analytics collectors that don't need direct DOM interaction – Partytown is still a great option.

**What you can do:**

1. **Identify Critical, Main-Thread Dependent Scripts:** Any script that manipulates the DOM heavily, relies on a full `window` context, or is known to be sensitive to execution environments (like many ad platforms and some analytics).
2. **Remove Partytown for These Scripts:**
   - In your `astro.config.mjs`, remove the `@astrojs/partytown` integration entirely if you find _any_ critical scripts break.
   - Alternatively, if you have some scripts that _do_ work well with Partytown, ensure the problematic scripts are **not** marked for Partytown processing (e.g., remove the `data-partytown-sandbox` attribute).
3. **Test Thoroughly:** Deploy your changes and confirm that all critical third-party scripts (ads, analytics, chat, etc.) are working as expected.

This experience was a tough lesson in the intricacies of browser environments and the trade-offs of performance optimization. Sometimes, the most efficient solution isn't about pushing everything off the main thread, but about understanding what truly _needs_ to be there to function correctly. It was frustrating, but solving this silent assassin has made me a much savvier debugger!

Until the next PR… stay in the loop.

---

# The Vercel Playwright Puzzle: When Headless Browsers Go Rogue on Deployment (The Full Debugging Saga)

- **URL**: https://www.rafay99.com/blog/vercel-playwright-deployment-error-debugging/
- **Published**: 2025-06-22
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess, WebDevelopment
- **Description**: How a simple Playwright integration turned into a multi-day battle with Vercel — and how a feature flag saved the day.

As software engineers, we often pride ourselves on creating elegant, functional solutions. My recent project, an Astro-based portfolio and blog, included a particularly cool feature: dynamic diagram rendering using Playwright. Locally, everything worked like a charm – diagrams generated beautifully, tests passed, and the feature was a highlight. But then came the deployment to Vercel, and that's when a seemingly simple integration morphed into a multi-layered debugging saga.

### Act I: The Initial Mystery — `apt-get: command not found`

My `package.json` was set up to install Playwright and its necessary browser binaries via a `postinstall` script, a common practice:

```json
// package.json snippet (initial)
{
  "name": "rafay99.com",
  "type": "module",
  "version": "8.0.0",
  "scripts": {
    "dev": "astro dev",
    // ... other scripts
    "postinstall": "npx playwright install" // <--- The culprit?
  },
  "dependencies": {
    // ... other dependencies
    "playwright": "^1.53.1"
  }
}
```

On Vercel, the build process would kick off, download Node.js packages, and then hit this `postinstall` hook. The logs quickly revealed the first major hurdle:

```
[23:20:48.171] > rafay99.com@8.0.0 postinstall
[23:20:48.171] > npx playwright install
// ... (Playwright attempts to install browsers)
[23:21:05.109] ╔══════════════════════════════════════════════════════╗
[23:21:05.109] ║ Host system is missing dependencies to run browsers. ║
[23:21:05.109] ║ Please install them with the following command:      ║
[23:21:05.109] ║                                                      ║
[23:21:05.109] ║     npx playwright install-deps                      ║
// ... (suggests apt-get install)
[23:21:07.099] sh: line 1: apt-get: command not found
[23:21:07.106] Failed to install browser dependencies
[23:21:07.107] Error: Installation process exited with code: 127
```

**The Core Problem:** Playwright needs underlying system libraries (like `libnspr4`, `libnss3`, `libgbm1`) to run its headless browsers. The `npx playwright install` command, when run, tries to invoke `npx playwright install-deps` which attempts to use `apt-get` (a common Linux package manager) to fetch these. In the restricted environment of a Vercel build's `postinstall` script, `apt-get` simply wasn't available or callable with the necessary permissions. The build would fail right here.

### Act II: Taking Explicit Control – The `vercel.json` Experiment

My first thought was, "Let's be more explicit!" Perhaps the `postinstall` hook was the issue. I decided to remove the Playwright installation from `package.json`'s `scripts` and put it directly into Vercel's `installCommand`, hoping to give it a better chance to execute.

**Change to `package.json`:**
Removed the `postinstall` line:

```json
// package.json snippet (after first change)
{
  "name": "rafay99.com",
  // ...
  "scripts": {
    "dev": "astro dev",
    "start": "astro dev",
    "build": "tinacms build && astro build",
    "preview": "astro preview",
    "astro": "astro"
    // "postinstall": "npx playwright install" <-- This line was removed
  },
  "dependencies": {
    // ... "playwright" package itself remained here ...
  }
}
```

**Change to `vercel.json`:**
Combined `npm ci` with an explicit `npx playwright install chromium`:

```json
// vercel.json (after first change)
{
  "installCommand": "npm ci && npx playwright install chromium", // <--- NEW
  "buildCommand": "npm run build",
  "routes": [
    // ...
  ]
}
```

This seemed promising! The build logs confirmed that Playwright successfully downloaded the Chromium browser, bypassing the initial `apt-get: command not found` error during the _installation_ phase:

```
[23:53:14.420] Downloading Chromium 138.0.7204.23 (playwright build v1179) from https://cdn.playwright.dev/dbazure/download/playwright/builds/chromium/1179/chromium-linux.zip
// ... progress bars ...
[23:53:18.693] Chromium 138.0.7204.23 (playwright build v1179) downloaded to /vercel/.cache/ms-playwright/chromium-1179
```

However, a new problem surfaced shortly after...

### Act III: The Phantom Dependency — Browser Launch Failure

The initial installation hurdle was cleared, but the core issue of missing _system_ dependencies wasn't truly gone. During the `buildCommand` (`npm run build`), which triggers Astro's build process and subsequently uses Playwright for diagram rendering, the build failed with an almost identical message:

```
[23:54:17.861] browserType.launch:
[23:54:17.861] ╔══════════════════════════════════════════════════════╗
[23:54:17.861] ║ Host system is missing dependencies to run browsers. ║
[23:54:17.863] ║ Please install them with the following command:      ║
[23:54:17.863] ║                                                      ║
[23:54:17.863] ║     npx playwright install-deps                      ║
// ... (suggests apt-get install again)
[23:54:17.864]     at getBrowser (/vercel/path0/node_modules/mermaid-isomorphic/dist/mermaid-isomorphic.js:100:39)
[23:54:17.864] [ERROR] [glob-loader] Error rendering v5/v5.4.md: Failed to parse Markdown file "/vercel/path0/src/content/webwiki/v5/v5.4.md":
[23:54:26.701] Error: Command "npm run build" exited with 1
```

**The New Revelation:** It wasn't just about _downloading_ the browser binaries; it was about the underlying operating system having the necessary shared libraries to _execute_ those binaries at runtime during the build. My explicit `npx playwright install chromium` only fetched the browser itself; it didn't install its crucial _system_ dependencies. And attempting to use `npx playwright install-deps` or `apt-get` directly within the user's build script still wasn't permitted or working correctly in the Vercel environment.

### Act IV: The Canonical (But Elusive) Vercel Solution

Knowing that Vercel provides first-class support for Playwright, the next logical step was to use their recommended method for handling these system-level dependencies: an environment variable.

**Re-confirm `package.json`:**
Ensured no `postinstall` script was present.

**Change to `vercel.json`:**
Simplified `installCommand` to let Vercel's internal magic handle Playwright:

```json
// vercel.json (after final change attempt)
{
  "installCommand": "npm install", // Simpler, letting Vercel manage Playwright's deps
  "buildCommand": "npm run build",
  "routes": [
    // ...
  ]
}
```

**Crucial Step: Adding an Environment Variable in Vercel UI:**
Navigated to Vercel Project Settings > Environment Variables and added:

- **Name:** `INSTALL_PLAYWRIGHT_DEPS`
- **Value:** `1`
- **Target:** `Build Time` (and Production/Preview, for completeness).

The expectation was that this environment variable would signal Vercel to install the required `libnspr4`, `libnss3`, `libgbm1` etc., in a privileged way before the build began, finally resolving the browser launch issue.

### The Complex Reality: Debugging Doesn't Always End in a Full Fix

Despite methodically going through these steps, analyzing logs, and applying the recommended solutions, the stubborn "Host system is missing dependencies to run browsers" error persisted during the build phase. This specific interaction between Playwright's exacting system requirements, the nuances of `rehype-mermaid`'s integration, and Vercel's managed build environment proved to be exceptionally complex.

It became clear that directly forcing Playwright's full runtime environment to be perfectly aligned within the current Vercel build context was not a straightforward path, at least not with the time and resources allocated.

### The Pragmatic Conclusion: A Feature Flag for Sanity

In software engineering, sometimes the most technically "correct" solution isn't immediately achievable or feasible. When facing such a persistent, low-level deployment blocker, the most sensible approach is to be pragmatic.

My current path forward: **implementing a feature flag** for the diagram rendering functionality. This allows me to:

1. **Deploy the core application successfully:** The rest of the Astro site can go live without being held hostage by this specific build-time rendering issue.
2. **Isolate the problem:** The Playwright-dependent feature can be disabled during Vercel builds, while still remaining fully functional in local development and for future investigation.
3. **Maintain velocity:** Avoid getting endlessly stuck on a single, highly complex environmental problem.

While the desire for a clean, direct fix is strong, this debugging odyssey highlights an important truth: complex deployment environments can introduce challenges that defy immediate resolution. Knowing when to pivot, implement a workaround, and isolate problematic features is a valuable skill in a software engineer's toolkit. The problem hasn't vanished, but the deployment can now proceed, allowing me to continue building and delivering value. And that, in itself, is a victory.

---

# Lead Finder: New Startup Journey

- **URL**: https://www.rafay99.com/blog/leadfinder-saas-journey/
- **Published**: 2025-06-17
- **Author**: Abdul Rafay
- **Tags**: AI, Startup, WebDevelopment
- **Description**: So this is my journey of coding my own startup 

If you work in any field, everyone eventually dreams of owning their own business. If you’re a lawyer, you want your own law firm; if you’re a dentist, your own clinic. As software engineers, we’re no different—we’ll all want to build our own SaaS (Software as a Service) at some point. Believe me, I’ve done it twice already. I’ll build something, code for months… and then realize marketing is the less-colorful side of the party.

By now you’re probably wondering: What am I building next? You know me as the “Flutter guy” who builds full-stack apps, but this time I’m going all-in on web tech—and boy, do I have stories for you.

Buckle up, nerds… this is going to be a wild ride. I’ll be posting my journey every single day as I add features, squash bugs, and push updates to production. If you’re impatient, though, go ahead and check out v0.2 of the app—it’s live now at [https://www.leadfinder.store/](https://www.leadfinder.store/).

Before you grab your keyboard to drop comments, let me explain the name and the core idea behind the product.

## Lead Finder

As the name suggests, Lead Finder is a platform that helps you discover business leads for any line of work. Imagine you just graduated from university and you’re hunting for an internship. You scroll through social media, sometimes spotting opportunities, sometimes hitting dead ends. It gets rough.

Maybe you’re a freelancer, or a doctor looking for patients. Gathering all that data and dumping it into a spreadsheet feels outdated and tedious. And spreadsheets go stale fast—leads change, companies pivot, contact info shifts.

You need a service that keeps things moving and surfaces the best leads for your field. Whether you’re a software developer, a law firm, a hospital—or anything in between—Lead Finder delivers fresh, actionable contacts right to your fingertips with a single click. That’s the power of this SaaS.

## Back Story

The back story is very simple, I am a free lancer most of the time and I want to find lead using the internet, it was hard, going to different ites, search the thing, wrote down all the email, phone numbers and other into a excel sheet and then few time later all the data is out data so I though why not just I buid this stuff. it won't tak that long, so I made quick react project, install the depiedences and then make basic UI and then I intergrated the api, I added the 

## The Beginning

When I started coding this project, it was just a super simple one-page app using React and Vite. I integrated an API into a form, displayed the results, and then exported them into a basic CSV file. Straightforward stuff.

But then a thought hit me—_what if I turn this into a SaaS?_ If I was facing this issue, chances are others were too. So I started thinking: what would the core features look like? I asked ChatGPT (of course), and after a long discussion, we agreed—yep, this is a real problem, and yep, it could become a real product.

After reflecting on everything, I came up with 7 key things I needed to build:

1. Get leads
2. Export leads into an Excel sheet
3. Payment gateway (Free & Pro tiers)
4. Auth system
5. Backend to manage everything
6. Simple admin panel (for me)
7. Set API usage limits

And just like that, the race was on.

I started coding and ticking off features one by one. I also added feature flags so I could update things easily and keep everything flexible and future-proof.

## Tech Stack

Once the features were locked in, it was time to decide the tech stack. And if you're expecting some wild fancy stack—nah, it’s pretty simple:

1. Vite
2. React
3. Tailwind CSS
4. Clerk
5. Convex
6. UI built with Redux + Shadcn

When I was building the project, I thought the stack was solid—and honestly, it still is. Sure, there were moments when I considered switching to a full framework like Next.js. But even without it, this stack is doing wonders. It’s fast, I have full control, and I can do _a lot_. It’s not perfect, but some things are just great—like blazing fast build times, everything is dynamic (no static content), and I can manage feature flags, blogs, and edge cases all in one flow.

## Why I Didn’t Go with a Framework

When I first started building _LeadFinder_, it was just a single API call and some simple integrations. But as I added more features—routes, a blog, a more complex admin panel, feature flags, Convex data migration—I realized maybe I should’ve gone with a proper framework.

But by that time, I had already written over 20,000 lines of TypeScript and JavaScript. Rewriting the whole thing, swapping out Clerk, reworking Convex setup for dev and prod... nah, not worth it.

So I stuck with what I had.

And honestly? It’s working perfectly. With Vercel, the whole thing runs smooth. If I ever want to expand or refactor later, I will—but for now, this single-page app is getting the job done.

## Pricing & Thought Process

After a long thinking session (and way too many coffee-fueled nights), I couldn’t decide on the price point. Initially, I thought $8/month for the Pro plan and $0 for the Free plan. But even then, I wasn’t fully convinced the value was _there_. So, I decided to add more features—stuff that would _actually_ make it feel like a full platform, not just another lead scraper.

The idea? A one-tab solution.
Search leads? Same tab.
Save them? Same tab.
Need help? AI’s right there.
Want to reach out to the lead? Yup, same tab.
No more hopping between 3 services or 10 open browser tabs.

## Decided Features

With that in mind, here are the features I committed to:

1. AI integration (Gemini & OpenAI)
2. Email integration
3. In-app communication with leads
4. Full CRUD operations for both leads and emails

These felt like solid features that actually brought value—and yeah, now I was confident: $8/month Pro, $0 Free. Done.

## The Real Cost

What really costs me isn’t just time—it’s API usage.

- Google Maps API for finding leads? Not cheap.
- AI integration using Gemini + OpenAI? Prices are _through the roof_.

So to balance it out, I stuck with the $8/month Pro plan. Right now, there are **no API call limits** for Pro users. Go wild—scrape and search all you want.

In the future, I might introduce more tiers or set some soft limits. But for now, this setup works.

## The Future

Oh yeah—I’ve got plans. Big ones.

Here’s what’s on the roadmap:

1. Add more lead-finding APIs
2. Expand the admin panel (more control, more clarity)
3. Add more AI models and prompts
4. New lead-finder services like:
   - **LinkedIn** lead search
   - **Facebook** lead lookup
   - A Google scraping service to extract leads from search results
5. Clean up the codebase—make it more readable, scalable, and properly documented
6. Monitoring: I want to build an all-in-one logging & error handling setup inside the admin panel, so I’m not flying blind when stuff breaks

## UI and Design

Alright—with all the features in place, let’s finally take a look at the UI and see how it’s all shaping up.

As you can see, the UI runs in dark mode by default—but yeah, there’s a light mode too, with multiple accent color choices. You’ve got:

- A clean landing page
- A functional dashboard where users can connect Gmail
- An email module to send messages directly to leads
- A "Leads & AI" section where users can save leads and let the AI generate emails for them

Don’t know what to write? AI’s got your back—generate a cold email, tweak it if needed, and send it straight from the app. No switching tabs, no guessing what to say. It’s all there.

## Coming Blog Posts

In the upcoming blog posts, I’ll break down everything—code structure, how I organized things, and even the parts where I hardcoded stuff that later came back to haunt me. 😅

To deal with those issues, I had to write a bunch of migration logic that works across both the dev and production environments. It wasn’t clean, but it worked—and I’ll share the exact thought process and trade-offs I made along the way.

Stay tuned if you're interested in the messy reality behind building and shipping something solo.

## Conclusion

This project has taught me a _lot_. From managing APIs to building out a scalable system, to realizing just how far I can push a simple Vite + React app—it’s been a ride.

And honestly, I’m super excited to see where this goes next.

This is just the beginning. 🚀

---

# Google I/O 2025: Everything Google Announced (AI, Android, Pixel, and More)

- **URL**: https://www.rafay99.com/blog/google-io-2025-highlights/
- **Published**: 2025-05-24
- **Author**: Abdul Rafay
- **Tags**: Google, ThoughtsProcess
- **Description**: A complete breakdown of Google I/O 2025 — Gemini updates, Android 16 features, new Pixel devices, AI overviews in search, and what actually matters for developers right now.

Google I/O 2025 just wrapped up — and as expected, it was packed. AI everywhere, Android refinements, a new Pixel, and some future-looking tech that made me pause. But between the flashy demos and keynote energy, the question is: what’s actually useful right now, what sets the stage for what’s next, and what’s just there for the hype cycle?

Let’s break it down.

## Gemini is Everywhere — Literally

If you watched the keynote, you saw Gemini show up in Gmail, Docs, Android, Chrome, Search, and even the camera. It’s now your “AI teammate,” which… feels like Google’s trying to brand it as the assistant you actually want to use.

There’s some cool stuff. In Gmail, you can summarize long threads. In Docs, it can help draft content and fix structure. In Android, Gemini replaces the old Assistant and now lives in a floating overlay. It even processes screen context, like answering questions about what’s on display — similar to what ChatGPT Vision can do.

But here’s the thing: while this sounds impressive, most of it still feels incremental. Useful, sure — like smart autocomplete with flair — but not game-changing. And I can’t help but feel like this is Google trying to catch up to OpenAI’s mindshare.

Long term, though, having AI deeply embedded across apps will change how we work — but right now, most people will use this for email replies and document cleanup. That’s about it.

## Android 15 — Nothing Wild, But it Feels Solid

Android 15 isn’t flashy, and honestly, that’s okay. This release is about polish — better battery life, smoother animations, improved privacy (Private Space), and more consistent behavior for background tasks. There’s also built-in support for satellite texting, which could be a quiet game-changer down the road.

What I liked most: Google’s giving devs more reliable tools. That means fewer edge case bugs and more predictable behavior across devices. Finally.

It’s clear Google is playing the long game here — refining Android like Apple does with iOS. But some of this, especially the hardware-dependent features like satellite texting, won’t show up for most users anytime soon unless OEMs and carriers catch up fast.

## Search Gets AI Overviews — The Web Will Feel It

Search is evolving into something… different. With Gemini integrated, Google now shows AI Overviews right at the top of results. It pulls together summaries, steps, answers — all in one chunk. You still get links below, but let’s be honest, this shifts user behavior massively.

This might help users get answers faster — but as someone who also builds content for the web, I’m thinking about what this means long-term. Fewer clicks to actual websites? Lower traffic? Possibly.

Google says they’re only using this for queries where AI adds real value. That’s vague — and we’ve heard this before. This direction feels like a double-edged sword. Helpful for users, but maybe not so great for the open web if creators stop seeing value in publishing.

## Project Astra — The Demo Was Cool, But Still Feels Far Off

This one got the most buzz: Project Astra is DeepMind’s real-time, multimodal assistant. Think: your phone camera sees a broken speaker, and Astra tells you what’s wrong while narrating it like a human. No typing, no waiting — just interaction.

It looked impressive. But honestly, it feels like a research preview. There’s no real product yet, just a promise. This could become the next leap — or the next Google demo that fades quietly. Depends on whether it ships in something real (like Pixel, Glass, or Nest) and how well it holds up outside of a controlled keynote.

## Pixel 8a — The Hardware Gets Smarter Too

Pixel 8a launched during the event. Priced at $499, it’s basically a cheaper Pixel 8 with the same Tensor G3 chip, Gemini integration, and — this is big — seven years of updates.

That last part shows Google is finally listening. Android needs more stability and long-term support to be taken seriously like iPhones in markets like Europe or Asia.

Still, the ecosystem is the challenge. The phone is great, but it won’t matter unless more people adopt the whole suite of Google experiences. Apple’s still miles ahead in integration.

## Developer Tools: Gemini API, Android Studio, Firebase

For developers, this was probably the most practical part of the show. Google rolled out:

- Gemini 2.5 (Pro & Flash) for faster, more efficient models.
- Firebase Studio powered by Gemini 2.5; Gemini in Android Studio agent/code-assist previews.
- Google AI Studio (Gemini‑powered) for building custom agents and multimodal models.
- Google AI Pro and Google AI Ultra subscription tiers (higher limits and access to 2.5 Pro/Deep Think and Veo features).
- Expansion of Model Garden and fine-tuning tools on Vertex AI.

There’s a lot here, and it actually looks usable. Gemini integrations in IDEs could speed up development, especially for solo devs or small teams.

That said, Google still has a messaging problem with its AI stack. Between Gemini, Vertex, Firebase, and Cloud AI, it’s not exactly beginner-friendly. This needs consolidation or at least better onboarding docs.

## Final Thoughts — What I’m Watching

Google I/O 2025 felt more practical than past years. Less moonshot, more ship-it. A lot of what they showed is already rolling out, which is a win.

Still, the AI push is aggressive — and not all of it feels like it’s solving real problems yet. Gemini’s cool, but it needs to move past summaries and drafting help. Astra looks like a breakthrough, but it’s far from ready.

The biggest shift? How we interact with devices is changing. AI is now baked into the OS, the apps, and the browser. The future isn’t one big innovation — it’s a thousand little ones slowly becoming invisible.

Until then, peace out, nerds. 👓

## References

- [Google Blog – 100 I/O Announcements](https://blog.google/technology/ai/google-io-2025-all-our-announcements/)
- [Wired – Everything Google Announced](https://www.wired.com/story/everything-google-announced-at-io-2025)
- [Gemini API Overview](https://ai.google.dev/)
- [Android 15 Developer Preview](https://developer.android.com/about/versions/15)
- [Pixel 8a Details](https://store.google.com/product/pixel_8a)

---

# Developer Docs That Don’t Suck: A Guide to Clear Technical Writing

- **URL**: https://www.rafay99.com/blog/developer-documentation-best-practices/
- **Published**: 2025-05-14
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess
- **Description**: As a deve learning Docs for other developer can be rough so we will go through how to write good docs for a Project

We’ve all been there.

You open a GitHub repo, ready to dive in. But instead of a clear setup guide or helpful context, you're hit with a README that feels like it was written by a robot—or worse, a lawyer. Walls of jargon. Dead links. Or a note that says “For full setup instructions, see our Confluence.”

Momentum? Killed.

And here’s the kicker: the code might be great, but **bad documentation can make a great project invisible**. That’s a lesson I learned the hard way.

## The Docs That Broke Me

A while back, I was contributing to an open-source project. The code wasn’t the issue—it was the docs. I had no clue where to start. The README assumed I already knew half the stack and linked out to another doc that was just as confusing.

I rage-quit.

But it made something painfully clear:
**If the docs suck, users bounce—no matter how good your tool is.**

## The Shift: Write Like a Developer, for Developers

From that moment on, I stopped treating documentation as an afterthought. I started writing docs like I was talking to a dev version of myself:

- Tired
- Distracted
- Juggling three tabs and a debugger

I wanted to make sure that even future-me (after two weeks away from the code) wouldn’t get lost.

So here's how I write developer docs now—and how you should too.

## Start with the “Why”, Not the “What”

Before you show how to install your tool, tell me **why it matters**.

```md
MS Bridge is a cross-platform app for seamless note reading and taking.
```

That’s better than:

```md
This app uses Flutter 3.22.2, Firebase, Hive, and...
```

Give context first. Then show me the value. Then tell me how to use it.

## Think Like a Tired Dev on a Deadline

Most readers are not fresh-faced engineers sipping coffee with hours to spare. They’re deep in a bug or trying to integrate your tool into a bigger system.

So be kind:

- Be **direct**
- Skip the fluff
- Make every sentence help someone get something done

## Organize Like a Developer’s Brain

Docs are **not novels**. People don’t read them linearly. They jump around. They scan.

Use structure:

- Clear headings
- Feature tables
- Bullet lists
- Code blocks that actually run
- A predictable layout

The more your docs feel like a well-labeled toolbox, the better.

## Show Working Code, Not Just Paragraphs

```bash
# ✅ Yes:
flutter pub get
```

```bash
# ❌ No:
Install the dependencies
```

Your users will **copy-paste before they read**. If your snippet doesn’t work out of the box, you’re already causing frustration.

Use real, tested code. Include actual output. Annotate only if needed. Skip pseudo-code that leads nowhere.

## Use Screenshots or GIFs

One screenshot can save someone **five minutes of reading**. A short GIF showing how the UI responds? Even better.

If you’re building something visual, _show it._

## Call Out the Gotchas — Early

Every tool has quirks. Be honest about them.

Don’t bury gotchas in an “Advanced” section nobody reads. Instead:

> 💥 **If you get `XYZ error`, it’s because of ABC. Restart your dev server.**
> ✅ **Fix:** Add this line to your `.env` file.

This builds trust and saves your users hours.

## Keep Docs Alive

Docs rot. Fast. Every time I push a major change, I do a 5-minute README sanity check.

I treat documentation like code. If it’s outdated, it’s broken.

## My Personal Docs Template (Steal This)

Here’s the checklist I now follow for every project:

- ✅ One-liner summary (human-first)
- ✅ What/Why section
- ✅ Features table
- ✅ Screenshot or GIF
- ✅ Tech used (just the key stuff)
- ✅ Step-by-step setup
- ✅ API key setup (clearly marked)
- ✅ Run instructions
- ✅ Troubleshooting
- ✅ How to contribute
- ✅ Where to contact me

It’s simple, but that’s the point.

## Final Thought: Docs Are Your First Impression

Good docs save you time, build community, and earn trust.

The best documentation I’ve ever read felt like a senior dev was sitting next to me, calmly saying:

> “Here’s what this does. Here’s why it matters. Here’s how you get started. I’ve been in your shoes.”

If you’re building something worth using, it’s worth documenting well.
And if you’re writing docs, write like **someone’s job depends on it**.

Because sometimes… it does.

Until then, peace out, nerds. 👓

---

# Don’t Trust the Bot: Always Review Your Code

- **URL**: https://www.rafay99.com/blog/never-blindly-trust-ai-code/
- **Published**: 2025-05-09
- **Author**: Abdul Rafay
- **Tags**: AI, ThoughtsProcess
- **Description**: A candid look at how AI is changing code reviews, why tools like Code Rabbit help — and why you should still double-check everything.

---

I just got my first job in the year 2022 after my bachelor’s degree, and I started my career as a Machine Learning Engineer. Then the first AI boom hit — ChatGPT was released and **changed** the course of history so much that I couldn't imagine. It was so **groundbreaking** that I could not believe it. Like I knew what AI was, but then everything changed. With time, the era — _"The Era of AI"_ — was born.

With time, different tools for different AI tasks were created — from coding to writing blogs to SEO and even task management. People were adding OpenAI APIs into their applications and wrapping interfaces around them. Like, this was cool, but one area I want to talk about is **code review**.

## Old Method

Let’s go back in time and talk about how code review used to be done. It was simple. You code something, make a pull request, and then submit it. A reviewer checks it and tells you to make changes to the codebase. You make the changes, re-submit, and if everything looks good, your code gets merged into the main branch. That was it.

This process was simple but skillful — senior and junior devs both had to look out for what could cause issues and whether the code quality was solid.

## AI-Written Code

AI has changed everything. Now, everyone is writing code using AI — this was new and became known as **_"Vibe Code"_**. If you want to know what vibe coding is, check out my previous [blog post](/blog/rise-of-vibe-coding/).

With vibe coding in place, everyone was writing code using AI. There were cases where AI-written code had downsides — for example, **no optimization**, **bugs**, and sometimes it caused **major issues** in the codebase — even breaking the entire app.

Not too long ago, I came across a YouTube video where Theo talks about a Twitter post where AI-generated code caused a company to lose **ten thousand US dollars**. That’s crazy. Theo raised some solid points — if you'd like to watch the video, feel free to check it out.

> It's an amazing YouTube video:

## Code Rabbit

Let’s be real — **everyone’s using AI** these days to handle the boring parts: styling, boilerplate, repeated tasks... even I do it! I’ll be honest, I’m _not great at design_ or picking the right color palette, so I use AI for that too. No shame.

But here’s the thing — with all this AI-generated code, **you _have_ to review it**. And that’s exactly where **[Code Rabbit](https://www.coderabbit.ai/)** comes in.

Basically, Code Rabbit reviews all your pull requests and suggests changes — and not just generic ones. It understands your codebase context too. And the best part? **It’s totally free** for all public repos. For this blog post, I went ahead and enabled Code Rabbit on all my projects.

And holy moly… **it’s actually good.**
Like 90% of the time, it gives solid suggestions to improve my _questionably written_ code 😅.

### Here's the proof:

Pretty impressive, right?

Code Rabbit doesn’t just point out little things — it’ll flag **error handling**, suggest **accessibility improvements**, and yeah... even **remind you to remove your API keys** if you accidentally commit them. (Been there.)

I remember one time I was building a **Text-to-Speech API in the browser**, and it was _rough_ getting it to work. Locally and in preview deployments, everything looked fine. But when I pushed the code, **Code Rabbit found a bug** I totally missed. I fixed it based on its suggestion, and boom — it actually solved the issue.

If you'd like to see the full pull request, feel free to check out my GitHub repo [here](https://github.com/rafay99-epic/Astro-Portfolio-Blog/pull/95).

> ⚠️ One small disclaimer:
>
> I **don’t make direct commits** from GitHub based on Code Rabbit suggestions.
> What I do is **copy the suggested code**, run it locally, test it, and if it works — then I commit manually.
> If it doesn’t work, I tell it straight up: “Nope, this broke something.” Always test things yourself. Blindly applying code review suggestions (even from AI) can sometimes lead to **chaos**.

## The Catch: It’s Not Always Perfect

So yeah, Code Rabbit is great — **90% of the time** it works like magic. But let’s talk about the other **10%**, the part where things start to fall apart a bit.

Now the issue isn’t with the code suggestions or how it reads the code — that part is solid. The real problem is when you **commit code directly from GitHub**, which is kind of the core feature of Code Rabbit.

Check this out:
![Code review interface showing AI-generated code with highlighted issues and suggested fixes](https://utfs.io/f/TViMykBJnLIJSQEu2G0rTfqzPA9HLJhvky4YEuprRd1gGsi3)

When you click that commit button from the GitHub UI, Code Rabbit sometimes tries to **replace entire functions**, even if the fix was just about changing one or two lines. And it does that without fully understanding the rest of the codebase — so yeah, it ends up **breaking stuff**.

This happened to me _a lot_ when I first started using it. After a few broken commits, I figured out my own flow:
I still let it review my code, but I **copy the suggested changes**, run them locally, and if it works — _then_ I push it. Never blindly commit from GitHub anymore.

Now, another thing that didn’t quite work for me is this new feature called **Code Docs**. When you make a pull request, it tries to automatically generate comments and document your code by summarizing it.

Honestly? Not a fan.
I turned it off the same day I tried it. It’s just not there yet — feels half-baked. Maybe in the future it’ll improve, but for now, nah. Needs more time in the oven.

## Final Thoughts

So yeah — **Code Rabbit is actually really good**.
It’s helped me _a lot_, and honestly, I’ve learned so much just by reading its suggestions. It feels like having a senior dev review your PRs every time… and it never gets tired.

But — and this is important — **don’t turn your brain off**.

There’ve been times when I pushed some code, and later someone asked me,

> “Hey, what does this function do?”
>
> And I just stood there like:
>
> “Uhh… no idea. Some AI wrote that.” 😅

So here’s what I’ve learned:

- **Know your codebase**, even if you’re working on just one part of it.
- **Always review everything** — read the suggestions, run them locally, test them, and make sure it actually works when deployed.
- Write tests. Please write tests.
- And yeah — performance? AI doesn’t care. It just wants to get the job done. You have to be the one to **optimize, clean up**, and make sure it won’t eat up all your memory.

In the end, tools like Code Rabbit are here to help — not replace thinking.
Use it, learn from it, don’t rely on it blindly… and most importantly, **have fun**. Whether you’re writing real code or just _vibe coding_, building cool stuff is what it’s all about.

Until then, peace out, nerds. 👓

---

# Astro: Automating Scheduling for Your Site

- **URL**: https://www.rafay99.com/blog/auto-scheduling-in-astro/
- **Published**: 2025-05-04
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess, WebDevelopment
- **Description**: Share your the story of building automating scheduling blog post in astro and github

If you know me, you already know I love writing blog posts like a story — taking you on a little journey while telling you what's happening. Today is no different.

Last night, while I was writing a blog post, a thought popped into my mind. I had set the blog post’s publish date sometime in the future. But I knew myself well — when that day came, I would definitely forget to **enable** that blog post manually.

And guess what? After a few months, that blog post would still be stuck there — unpublished — because I forgot to change `draft: true` to `draft: false`.\
That pissed me off so much. Like seriously — what the hell? I wrote the blog, finished it, set the publish date, but it would still sit there hidden just because I wanted to space out my posts instead of dumping them all at once.

The blog was **done**. It was **built** with the site files. It was just sitting there, needing to be enabled.\
Sounds simple to fix, right?\
Well... not so much.

Like every other software engineer when they're stuck, I went to Google and searched:\
`auto schedule a post in astro`

I came across a few blog posts that were close to what I was looking for — and honestly, they were **so well written** that I highly recommend you read them:

1. [jonathanyeong.com - Blog Post 01](https://jonathanyeong.com/writing/changelog-scheduling-posts-with-astrojs/)
2. [destiner.io - Blog Post 02](https://destiner.io/blog/post/draft-publications-and-post-scheduling-in-astro/)

Both blog posts made some solid points, and I genuinely enjoyed reading them.\
But... they didn’t exactly solve the problem **I** was facing.

So, like any desperate developer, I asked AI for suggestions.\
Spoiler alert: the AI suggestions were a complete **miss** for brainstorming.\
Sometimes AI can help. Sometimes it just makes you want to close your laptop and go outside.\
But before I explain how I _actually_ solved the problem, you first need to understand **why** this problem exists.

## The Static Site Conundrum

Astro is a **static site generator**. Everything for my site is built ahead of time and hosted on GitHub — **there’s no backend**.
(If you’re interested, I explained my entire website setup in this [blog post](/blog/solving-asset-bloat-with-image-composer/), but here’s the TL;DR:\
Everything is static. Every change requires a **full rebuild** of the site.)
Because of this, any functionality that needs **dynamic behavior** (like auto-scheduling posts) **can’t just magically happen** at runtime.\
There’s no server to "wake up" on a certain day and publish the post. The site is already frozen in time until the next rebuild.

So what’s the solution?

## The Solution: Simpler Than It Seemed

The solution, at its core, turned out to be pretty simple and straightforward — but it definitely needed some thought. I already had metadata defined for every blog post. If you haven’t seen it before, here’s an example:

```yaml
---
title: Is AI Just Hype or Something More?
description: >-
  Unveiling the truth behind AI: is it a revolutionary force or just a glorified autocomplete?
pubDate: 2024-09-30T19:00:00.000Z
draft: false
heroImage: https://utfs.io/f/TViMykBJnLIJB2wCfNjkNsEnJOSh8x7UI9j3yaW2cmo1ft5p
authorName: Abdul Rafay
authorAvatar: /author.jpg
tags:
  - AI
---
```

This is from one of my older posts. Now if you look closely, there are two fields that matter: `pubDate` and `draft`. Based on the `pubDate`, I needed a way to automatically flip the `draft` value from `true` to `false` once the scheduled date arrived. Simple, right? Except... how was I supposed to do it? Manually updating it every time wasn’t realistic. I needed something automatic. And that’s when GitHub Actions came into the picture.

## The Logic Behind It

Before diving into what I actually built inside the GitHub Action, I had to map out the logic. It was pretty straightforward when I thought about it. I just needed to loop through all the `.md` and `.mdx` files (my blog posts), read their metadata, check if the `pubDate` had already passed, and then see what the `draft` status was. If the post was still marked as `draft: true` even after the `pubDate` had passed, I would update it to `draft: false`. And if the `pubDate` was still in the future, I wouldn’t touch it. Clean, simple, and something that could easily be scripted.

## The Script Journey: JavaScript vs Python

With the logic sorted, I sat down and started writing the script — in JavaScript, because why not? I figured it would be quick. Spoiler alert: it was not. File manipulation with JavaScript turned out to be way more painful than I had expected. It wasn’t that it was impossible — it was just... annoying. Everything felt clunky. I kept running into issues, and on top of that, I had to install a bunch of packages just to do basic file handling.

At one point, I just stopped and thought about it. I remembered that a friend of mine had done something similar before — not blog posts, but handling big research papers, identifying different sections and modifying content automatically. They used Python for it. And at that moment, it clicked. I scrapped all the JavaScript code without a second thought and rewrote everything in Python from scratch. It was so much smoother, and honestly, it made me wonder why I hadn’t started there in the first place.

### Code Base Breakdown

```python
import os
import sys
from pathlib import Path
from datetime import datetime, timezone, date
import yaml
import re
import logging

logging.basicConfig(
    level=logging.INFO,
    format='%(asctime)s - %(levelname)s - [%(filename)s:%(lineno)d] - %(message)s',
    datefmt='%Y-%m-%d %H:%M:%S'
)

BLOG_CONTENT_DIR = Path("src/content/blog")

def extract_frontmatter(content: str, file_name: str):
    """
    Extracts YAML frontmatter from Markdown content.
    Returns (metadata_dict, body_content, original_yaml_str) on success,
    or (None, None, None) on failure. Logs warnings/errors.
    """
    match = re.match(r'^---\s*\n(.*?)\n---\s*\n', content, re.DOTALL)
    if not match:
        logging.debug(f"No YAML frontmatter delimiters found in {file_name}")
        return None, None, None

    yaml_content_str = match.group(1)
    body_content = content[match.end():]

    try:
        metadata = yaml.safe_load(yaml_content_str)
        if isinstance(metadata, dict):
            logging.debug(f"Successfully extracted metadata for {file_name}")
            return metadata, body_content, yaml_content_str
        else:
            logging.warning(f"Frontmatter in {file_name} parsed but is not a dictionary (type: {type(metadata)}). Skipping file.")
            return None, None, None
    except yaml.YAMLError as e:
        logging.error(f"Error parsing YAML frontmatter in {file_name}: {e}. Skipping file.")
        return None, None, None
    except Exception as e:
        logging.error(f"Unexpected error parsing YAML in {file_name}: {e}. Skipping file.")
        return None, None, None

def publish_post_if_ready(file_path: Path):
    """
    Checks pubDate and updates draft status if needed for a single file.
    Returns True if the file was updated, False otherwise.
    Logs details, warnings, and errors encountered during processing.
    """
    made_change = False
    file_name = file_path.name

    try:
        logging.debug(f"Processing file: {file_name}")
        content = file_path.read_text(encoding='utf-8')

        metadata, body, original_yaml = extract_frontmatter(content, file_name)

        if metadata is None:
            return False

        is_draft = metadata.get('draft')
        pub_date_value = metadata.get('pubDate')

        logging.debug(f"File: {file_name}, Draft Status: {is_draft}, PubDate Value: {pub_date_value} (Type: {type(pub_date_value).__name__})")

        if is_draft is True:
            if pub_date_value is not None:
                pub_date_dt = None
                try:
                    if isinstance(pub_date_value, datetime):
                        logging.debug(f"Handing pubDate for {file_name} as datetime object.")
                        pub_date_dt = pub_date_value
                        if pub_date_dt.tzinfo is None or pub_date_dt.tzinfo.utcoffset(pub_date_dt) is None:
                            logging.debug(f"Making naive datetime UTC for {file_name}")
                            pub_date_dt = pub_date_dt.replace(tzinfo=timezone.utc)

                    elif isinstance(pub_date_value, date) and not isinstance(pub_date_value, datetime):
                         logging.debug(f"Handing pubDate for {file_name} as date object, converting to datetime.")
                         pub_date_dt = datetime(pub_date_value.year, pub_date_value.month, pub_date_value.day, 0, 0, 0, tzinfo=timezone.utc)

                    elif isinstance(pub_date_value, str):
                        logging.debug(f"Handing pubDate for {file_name} as string, parsing.")
                        parsed_date_str = pub_date_value.replace('Z', '+00:00')
                        pub_date_dt = datetime.fromisoformat(parsed_date_str)
                    else:
                        logging.warning(f"Unexpected type for pubDate in {file_name}: {type(pub_date_value)}. Cannot compare date.")

                    if pub_date_dt:
                        now_utc = datetime.now(timezone.utc)
                        logging.debug(f"Comparing pubDate {pub_date_dt} with current time {now_utc} for {file_name}")

                        if pub_date_dt <= now_utc:
                            logging.info(f"Publishing {file_name} (pubDate: {pub_date_value})")

                            new_yaml = re.sub(r"^\s*draft:\s*true\s*$", "draft: false", original_yaml, flags=re.MULTILINE | re.IGNORECASE)

                            if new_yaml == original_yaml:
                                 logging.debug(f"Regex replacement failed for 'draft: true' in {file_name}, trying string replace.")
                                 temp_yaml = original_yaml.replace('draft: true', 'draft: false', 1)
                                 new_yaml = temp_yaml.replace('draft: True', 'draft: false', 1)

                            if new_yaml != original_yaml:
                                try:
                                    new_content = f"---\n{new_yaml.strip()}\n---\n{body}"
                                    file_path.write_text(new_content, encoding='utf-8')
                                    logging.info(f"Successfully updated draft status to false in {file_name}")
                                    made_change = True
                                except IOError as write_err:
                                     logging.error(f"Failed to write updated content to {file_name}: {write_err}")
                                except Exception as write_ex:
                                     logging.error(f"Unexpected error writing updated content to {file_name}: {write_ex}")
                            else:
                                 logging.warning(f"Could not find/replace 'draft: true' in {file_name}. Already false or formatted unusually?")
                        else:
                             logging.info(f"Skipping {file_name}: Publication date ({pub_date_value}) is in the future.")

                except ValueError as e:
                    logging.warning(f"Could not process pubDate value '{pub_date_value}' (type {type(pub_date_value).__name__}) in {file_name}: {e}. Skipping date check.")
                except Exception as e:
                    logging.error(f"Unexpected error during date processing for {file_name} with value '{pub_date_value}': {e} (Type: {type(e).__name__})")
            else:
                 logging.warning(f"Skipping {file_name}: Draft is true, but 'pubDate' key is missing.")
        else:
            logging.info(f"Skipping {file_name}: Draft status is not explicitly 'true' (current value: {is_draft}).")

    except FileNotFoundError:
        logging.error(f"File vanished before processing: {file_name}")
    except PermissionError as pe:
        logging.error(f"Permission error reading file {file_name}: {pe}")
    except IOError as e:
        logging.error(f"IOError reading file {file_name}: {e}")
    except UnicodeDecodeError as ude:
        logging.error(f"Encoding error reading file {file_name}. Ensure it's UTF-8: {ude}")
    except Exception as e:
        logging.exception(f"Unexpected error processing file {file_name}: {e}")

    return made_change

def main():
    """Finds posts and attempts to publish them."""
    logging.info("Starting auto-publish script...")
    total_changes = 0

    if not BLOG_CONTENT_DIR.is_dir():
        resolved_path = BLOG_CONTENT_DIR.resolve()
        cwd = Path.cwd()
        logging.critical(f"Blog content directory not found at expected path: {BLOG_CONTENT_DIR}")
        logging.critical(f"Resolved path attempted: {resolved_path}")
        logging.critical(f"Current working directory: {cwd}")
        logging.critical("Ensure the script is run from the repository root or BLOG_CONTENT_DIR is correct.")
        sys.exit(1)

    logging.info(f"Checking posts in directory: {BLOG_CONTENT_DIR}")

    try:
        files_to_check = list(BLOG_CONTENT_DIR.glob("*.md")) + list(BLOG_CONTENT_DIR.glob("*.mdx"))
        logging.info(f"Found {len(files_to_check)} potential post files (.md, .mdx).")

        processed_files = 0
        for file_path in files_to_check:
            if file_path.is_file():
                if publish_post_if_ready(file_path):
                    total_changes += 1
                processed_files += 1
            else:
                 logging.warning(f"Path found by glob is not a file (skipped): {file_path}")

        logging.info(f"Processed {processed_files} files.")

    except Exception as e:
        logging.exception(f"An unexpected error occurred during file processing loop: {e}")

    logging.info("-" * 20)
    if total_changes > 0:
        logging.info(f"Script finished. {total_changes} post(s) were updated.")
    else:
        logging.info("Script finished. No posts needed publishing or updating.")
    logging.info("-" * 20)

if __name__ == "__main__":
    main()
```

When I started writing the auto-publish script, my main goal was simple:\
I wanted Markdown or MDX blog posts sitting in a `src/content/blog` directory to automatically "go live" when their scheduled `pubDate` arrived — without me having to manually change the `draft: true` status to `false`.

To make that happen, I first set up a clean project structure.\
Right at the top of the script, I imported essential libraries — `os`, `sys`, `pathlib` for file handling, `datetime` for managing dates, `yaml` for parsing the frontmatter metadata, and `logging` for capturing all sorts of useful debug and error messages.\
I knew that proper logging was crucial, so I configured a basic logging setup early on, ensuring I could easily spot errors or track the script's behavior at different verbosity levels.

Next, I defined a constant `BLOG_CONTENT_DIR`, which simply points to the folder where all my blog posts reside.\
This would make it easy to adjust later if needed, instead of scattering the directory path all over the code.

Then came the core functions.

I started with `extract_frontmatter()`, which is responsible for pulling out the YAML block from the beginning of each Markdown file.\
If the YAML frontmatter was missing or malformed, the function would return early — no point wasting time on a file that isn’t properly formatted.\
Parsing the YAML safely with `PyYAML` was important here, and I made sure any strange issues were logged clearly so I wouldn’t be left guessing later.

The real meat of the script was the `publish_post_if_ready()` function.\
This part reads each file, grabs its metadata, and checks if the `draft` field is still `true`.\
If it is, it then compares the `pubDate` value to the current time (UTC).\
I made sure to handle a few tricky cases here:\
Sometimes `pubDate` might be a full `datetime` object, sometimes just a `date`, and sometimes just a string in ISO format.\
The script carefully parses each possibility, ensuring consistency before doing any comparison.

If the current time was past the scheduled `pubDate`, the script would go ahead and update the `draft: true` in the frontmatter to `draft: false`, effectively publishing the post.\
For the update, I tried a safe regular expression replacement first; if that failed (which could happen if the spacing was unusual), the script fell back to a simple string replace to make sure nothing got missed.

To wrap everything up, the `main()` function orchestrated the whole process.\
It scanned the blog directory for `.md` and `.mdx` files, tried to process each file individually, and kept track of how many posts it successfully updated.\
Good error handling was important here — I made sure that even if one file threw an unexpected error, the script would keep running and processing the rest.

Finally, if something went really wrong — like if the blog directory didn’t even exist — the script would log a critical error and exit gracefully.

By the time the script finishes, I get a clean summary in the logs: how many posts were updated and any warnings or errors that popped up along the way.\
This way, I can schedule posts ahead of time and trust that they'll automatically go live without lifting a finger.

## GitHub Actions

Now let's talk about GitHub Actions — because honestly, without this part, running the script manually every day would be rough.

Here’s the deep dive:\
I created a GitHub Action that sets up Node.js, clones the project, installs the Python dependencies, runs the auto-publish script, checks for any changes, pushes those changes back to the main branch, and finally does some cleanup. This workflow runs **every day** at a scheduled time.

With the changes pushed to the main branch, Vercel automatically detects the updates and deploys the new blog posts on the correct date.\
So, in short: automation magic.

That’s the quick TL;DR of how the GitHub Action fits into this system.

But if you want to go full nerd, here’s the actual GitHub Action:

```yaml
name: Auto-Publish Astro Blog Posts

on:
  schedule:
    - cron: "0 7 * * *"
  workflow_dispatch: {}

jobs:
  publish-posts:
    runs-on: ubuntu-latest
    permissions:
      contents: write

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Install dependencies
        run: pip install PyYAML

      - name: Run publish script
        id: publish_script
        run: python scripts/publish_posts.py

      - name: Check for file changes
        id: git_check
        run: |
          if git diff --quiet --exit-code --ignore-space-change ${{ github.workspace }}/src/content/blog; then
            echo "No changes detected in blog posts."
            echo "changes_detected=false" >> $GITHUB_OUTPUT
          else
            echo "Changes detected in blog posts."
            echo "changes_detected=true" >> $GITHUB_OUTPUT
          fi

      - name: Configure Git user
        if: steps.git_check.outputs.changes_detected == 'true'
        run: |
          git config user.name "GitHub Actions Bot"
          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"

      - name: Stage, Commit, and Push changes
        if: steps.git_check.outputs.changes_detected == 'true'
        run: |
          git add src/content/blog/
          if ! git diff --staged --quiet; then
            git commit -m "Auto-publish scheduled blog posts"
            echo "Pushing changes..."
            git push origin HEAD:${{ github.ref_name }}
          else
            echo "No effective changes staged after running script, skipping commit/push."
          fi
```

---

## Final Thoughts

This little system saves me a lot of manual effort and just feels... clean.\
Instead of worrying about whether I scheduled a blog correctly or remembering to manually publish it on the right day, I let a Python script and GitHub Actions handle everything while I sip my coffee.

Sure, setting it all up took a bit of time — but now, it’s completely hands-off.\
Write → Schedule → Done.

Hope you found this useful! If you liked this deep dive (or if you have any cool automation ideas yourself), feel free to reach out.\
Let's keep building nerdy, efficient systems.

Until then, peace out, nerds.❤️❤️

---

# From Slow to Snappy: The Story Behind Building Image Composer

- **URL**: https://www.rafay99.com/blog/solving-asset-bloat-with-image-composer/
- **Published**: 2025-04-29
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess, WebDevelopment
- **Description**: Learn how I built Image Composer to efficiently compress images, improve performance, and boost my blog’s Speed Insights score from 50% to 100%.

As you may know, my blog has evolved significantly over time, transforming from a simple online journal to a comprehensive reflection of my personality and interests. This digital space has become a sanctuary where I can freely express my thoughts and feelings without reservation. However, building this online home, brick by brick, has not been without its challenges. When I was working on version 5 of my application, I encountered an unexpected and unprecedented problem - one that I never thought I'd face, but here we are.

## The Web Flow

Before I dive into the problem I'm facing, let me give you a quick rundown of how my website works. It's actually pretty simple. My site is built using Astro, React, Markdown, and Tailwind CSS. Each of these technologies plays a crucial role: Astro handles content rendering, React takes care of the UI, Tailwind CSS adds styles, and I write all my content in Markdown files.

I use a CMS to create content, which is then pushed to a GitHub repo called [Astro-Blog](https://github.com/rafay99-epic/Astro-Portfolio-Blog). A GitHub action takes care of building and deploying the site to the internet. It's a simple, clean setup with no backend – just code and a lot of Markdown files. Every time I add a new file or image to the repo, a new build is generated. This whole process is called Static Site Generation.

## The Problem

Now that you know how my site works, let's talk about the issue I'm facing. It's a pretty straightforward problem, but it's been causing me some headaches. I'm talking about asset management. I add images to my blog posts, and there are a lot of them. Depending on the project, the number of images can vary. The problem is that these images are hosted in the \_public folder, which needs to be small and fast. As I add more elements to the images, their size increases, causing performance issues.

You might be thinking, "Why are you adding so many large images to the public folder? You shouldn't be doing that!" And you're right; I shouldn't be. But here's the thing: my blog thumbnails have changed, and I need to move forward, not backward. I don't have a choice in the matter.

According to the [Astro Docs on Images](https://docs.astro.build/en/guides/images/), if I'm using the Astro Image component, I should put images in the src folder. However, if I'm using the img tag in HTML, the images need to be in the public folder. The problem is that I'm using React for every single page, and all the UI is built with React, Tailwind, and designed with... well, you get the idea. I can't use the \ component in my React code without causing errors throughout the codebase.

So, there you have it. Large assets are now a big problem for me because performance and load times are suffering.

## The Solution

The solution to my image woes is actually quite straightforward: use an image compressor. However, I've found that many image compressors out there have their own set of issues. Some are slow to load, others have limitations, and some can even degrade image quality to the point where it's not worth using them. And then there are those that take an eternity to compress an image, turning a simple task into a frustrating experience.

As my image sizes continued to balloon and my site's performance suffered, I decided to take matters into my own hands. I set out to build a new tool that would streamline my workflow and help me manage my images more efficiently. And so, Image Composer was born.

## Image Composer

Image Composer is a tool I designed and built to fix the whole asset problem I was facing.
I coded the entire app in just a single day — literally paused everything else (even my blog posts) and went full focus on it.

The goal was simple:
I needed a way to compress images without trashing their quality, and maybe even add a little something extra — like rounded corners, because honestly, rounded images just look cleaner and more modern.
And of course, the UI had to be simple and clean so that anyone could use it without needing a manual.

For the tech stack, I kept it super lightweight and fast:

- Node.js server
- EJS for template rendering
- Tailwind CSS for styling

### TLD'R: How it Works

If you don't want to nerd out on the code, here's the short version:

- Visit the website
- Drag and drop your images
- Pick the quality you want
- Choose if you want rounded corners
- Hit "Compress Images."
- The server compresses them using a library called Sharp
- The compressed images get displayed back in the UI
- Hit "Download," and boom — new, smaller, clean, high-quality images.

## Now, Let’s Nerd Out: Full Code Breakdown

Here's a full breakdown of the codebase — from starting the server all the way to the endpoint where the image gets uploaded, processed, and sent back to the user and much more.

### **1. `app.js` – The Entry Point**

This is where everything starts.

```javascript
const express = require("express");
const path = require("path");

const configureMiddleware = require("./config/middleware");
const configureViewEngine = require("./config/viewEngine");
const {
  notFoundHandler,
  globalErrorHandler,
} = require("./middleware/errorHandler");

const indexRoutes = require("./routes/routes");
const imageRoutes = require("./routes/image");

const app = express();
const port = process.env.PORT || 3000;

configureViewEngine(app);
configureMiddleware(app);

app.use("/", indexRoutes);
app.use("/", imageRoutes);

app.use(notFoundHandler);
app.use(globalErrorHandler);

app.listen(port, () => {
  console.log(`Server running at http://localhost:${port}`);
});
```

#### **What’s Happening Here?**

- We **import Express** and a few core modules.
- We set up **middleware** (security, rate limiting, etc.).
- We define **routes** (for the homepage + image compression API).
- We handle **errors** properly.
- We start the server and make it listen on **port 3000** (or whatever's in `process.env.PORT`).

Nothing fancy, just a solid Express setup.

---

### **2. `config/middleware.js` – Security & Performance Middleware**

This file **hardens** the server and **prevents abuse**.

```javascript
const express = require("express");
const helmet = require("helmet");
const rateLimit = require("express-rate-limit");
const hpp = require("hpp");
const cors = require("cors");
const path = require("path");

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100,
  message: "Too many requests, try again later",
});

function configureMiddleware(app) {
  app.use(cors()); // Allow cross-origin requests
  app.use(hpp()); // Prevent HTTP param pollution
  app.use(limiter); // Prevent spam requests
  app.use(helmet()); // Security headers
  app.use(express.json());
  app.use(express.urlencoded({ extended: true }));
  app.use(express.static(path.join(__dirname, "..", "public")));
}

module.exports = configureMiddleware;
```

#### **Why This Matters**

- **Helmet** adds security headers.
- **Rate limiting** prevents abuse (max 100 requests per 15 mins per IP).
- **CORS** is enabled so the API can be used from different origins.
- **Multer** (used later) only allows **JPEG, PNG, GIF, and WebP**—nothing shady.

This keeps the server **safe, fast, and reliable**.

---

### **3. `config/multer.js` – File Upload Handling**

Handles file uploads before passing them to **Sharp**.

```javascript
const multer = require("multer");

const storage = multer.memoryStorage();

const upload = multer({
  storage: storage,
  limits: { fileSize: 30 * 1024 * 1024 },
  fileFilter: (req, file, cb) => {
    const allowedMimes = ["image/jpeg", "image/png", "image/gif", "image/webp"];
    allowedMimes.includes(file.mimetype)
      ? cb(null, true)
      : cb(new Error("Invalid file type"), false);
  },
});

module.exports = upload;
```

#### **What’s Happening?**

- **Stores images in memory** instead of disk (faster processing).
- **Limits file size** to **30MB** (to prevent server crashes).
- **Blocks unsupported formats** (JPEG, PNG, WebP, and GIF only).

Multer makes sure **only valid images** reach our processor.

---

### **4. `controller/imageController.js` – The Brain of the Operation**

This is where **Sharp** does its magic.

```javascript
const sharp = require("sharp");

async function compressImage(req, res, next) {
  if (!req.file) return res.status(400).send("No image uploaded.");

  try {
    const quality = Math.max(
      1,
      Math.min(100, parseInt(req.body.quality) || 80),
    );
    const format = ["jpeg", "png", "webp"].includes(req.body.format)
      ? req.body.format
      : "jpeg";
    const rounded = req.body.roundedCorners === "true";

    let image = sharp(req.file.buffer).toFormat(format, { quality });

    if (rounded) {
      const metadata = await image.metadata();
      const mask = Buffer.from(
        `<svg></svg>`,
      );
      image = image.composite([{ input: mask, blend: "dest-in" }]);
    }

    res.set("Content-Type", `image/${format}`);
    res.send(await image.toBuffer());
  } catch (error) {
    next(error);
  }
}

module.exports = { compressImage };
```

#### **What’s Happening?**

- **Validates inputs** (quality: `1-100`, formats: `jpeg/png/webp`).
- **Sharp compresses the image** based on selected quality.
- **Optional rounded corners** applied via SVG mask.
- **Sends back the optimized image**—no saving to disk needed.

This keeps things **fast** and **efficient**.

---

### **5. `routes/image.js` – The API Endpoint**

This is where the magic happens.

```javascript
const express = require("express");
const upload = require("../config/multer");
const { compressImage } = require("../controller/imageController");

const router = express.Router();

router.post("/compress", upload.single("image"), compressImage);

module.exports = router;
```

#### **How It Works**

- **Receives an image** via a POST request.
- **Passes it to Multer** for validation.
- **Sends it to Sharp** for compression.
- **Returns the optimized image.**

And that’s it—**one clean API route that just works**.

Final Thoughts

Building this little app was honestly super fun, and I ended up learning way more than I expected. I had no idea image processing could be this much work! Most of my time actually went into getting the image compression to work properly — at first, it wasn’t working great at all. Designing the UI was the easy part compared to that.

If you want to try it out, you can check out the website — [Image Composer](https://imagecomposer-production.up.railway.app/) — and if you're curious about the code, it’s all up on [GitHub ](https://github.com/rafay99-epic/ImageComposer)too.

I even tested it in production! I compressed a bunch of big images into smaller ones, tweaked a few files in the codebase, removed some unnecessary JavaScript from my Astro blog site — and the performance score literally jumped from around 50% to 100%! Not kidding — you can check the Speed Insights yourself on Vercel where my site’s hosted.

![Website performance results showing improved speed scores](https://utfs.io/f/TViMykBJnLIJk9vuC03iDowrFjuG5fYXpRx8zcT73VgyUQe2)

Honestly, I can’t believe how much things improved just from building this one app. It’s easily the best thing I’ve built and deployed so far. I highly recommend giving the tool a try, and if you have any feedback or new ideas, feel free to open a pull request! I’d love to keep improving it.

Until then, peace out, nerds. 👓

---

# The World Needs Linux — Here’s Why It Matters More Than Ever

- **URL**: https://www.rafay99.com/blog/world-need-linux/
- **Published**: 2025-04-25
- **Author**: Abdul Rafay 
- **Tags**: Linux, ThoughtsProcess
- **Description**: A personal journey into Linux — discovering freedom, control, and why the world needs it now more than ever

I still remember the first time I installed Linux.\
It wasn't smooth. It wasn’t pretty. Heck, half the stuff didn’t even work out of the box.\
But there was something about it — something different from everything else I had used before.\
It felt _real_. It felt like I was finally in control.\
Not some locked-up experience made for the masses.\
It was **my system**, **my rules**.

And honestly?\
The more time I spend with Linux, the more convinced I am —\
**The world needs Linux.**\
Now more than ever.

## Why Linux Isn’t Just an Operating System — It’s a Mindset

When you boot into Linux, it’s not just a computer turning on.\
It’s a different philosophy kicking in.\
A belief that **software should be free** — not just in cost, but in freedom.\
That you, the user, are **smart enough** to choose what’s right for you.\
That you shouldn’t have to beg some corporation to let you use your own device.

Compare that to what we deal with every day:

- Locked bootloaders
- Forced updates
- Bloatware you can’t uninstall
- Apps that track you, "for your convenience"

It’s crazy when you think about it.

Linux stands up and says,

> "Hey, maybe you don’t need all that garbage. Maybe you just need a system that **respects you**."

And once you taste that kind of freedom — you don't want to go back.

## Real Talk: Linux Isn’t Perfect (And That’s Fine)

I’m not gonna sit here and pretend Linux is flawless.\
There are bugs. There’s a learning curve. Sometimes things break and you have to Google like crazy.

But here’s the thing:\
**That struggle teaches you something.**

When you fix your Wi-Fi by editing a config file?\
Installing Nvidia drivers will be rough on any distro, but with time and Google, you will figure this out, but if you like to go easy, then check out my blog post on Nvidia drivers on Fedora or Arch Linux.
When you make your desktop exactly how you want it — not how Apple or Microsoft says it should look?\
That’s _yours_.\
That knowledge _sticks with you_.\
You become a little more independent. A little more resilient.\
You stop being just a "user" and start being a _builder_.

And let's be real — the world could use a lot more builders right now.

## Why Big Companies _Secretly_ Love Linux (But Won't Admit It)

Here’s a fun fact:\
**Linux runs almost everything important.**

- 96% of the top 1 million servers? Linux.
- Android? Built on Linux.
- Supercomputers? 100% Linux.
- Even Tesla cars? Yup, Linux under the hood.

Big tech _loves_ Linux when it’s behind the scenes.\
But when it comes to your laptop or phone?\
They'd rather sell you a locked-down, heavily monetized experience.

Because Linux doesn’t fit their business model.\
Freedom isn't profitable.\
Control is.

## It’s Not About "Switching Everyone" — It’s About Giving People a Choice

Look, I’m not saying everyone needs to ditch Windows or macOS tomorrow.\
(Although honestly, you’d probably be happier.)

What I’m saying is:\
**People deserve a real choice.**\
They deserve to know there’s a world beyond the ads, the tracking, the forced updates.\
A world where your computer doesn’t treat you like a child.

Linux _is_ that world.

And once you step into it, even just a little bit —\
you’ll see why the world needs Linux.\
Maybe you do too.

## My Current Way — And Why Linux Is Still Home

To keep it real with you —\
I used to daily drive **Arch Linux** on my system.\
It was customized exactly the way I liked it.\
Fast, clean, lightweight, and fully _mine_.

But unfortunately, life had other plans.\
One day, my SSD failed — and it didn’t just take the system down, it took **everything** with it.\
It was a gut punch, no other way to put it.

Right now, I’m running **Windows with WSL** (Windows Subsystem for Linux).\
It’s not perfect — not even close —\
but for my day-to-day tasks, coding, and development, **Linux is still a part of everything I do**.

Because at this point?\
**I can’t live without Linux.**

It’s not just an OS for me anymore.\
It’s part of _how I work_, _how I think_, and honestly, _who I am_.

# Final Thoughts

If you’ve ever felt frustrated with your devices, if you’ve ever wanted _more_ than just clicking and waiting,\
I invite you:\
**Try Linux.**

It won't always be easy.\
But it will be yours.\
And in a world where everything feels rented, leased, or borrowed —\
that matters more than ever.

---

# Deploying Android Apps in 2025 — A Solo Dev's Journey

- **URL**: https://www.rafay99.com/blog/deploy-android-app-2025-12-tester-rule/
- **Published**: 2025-04-17
- **Author**: Abdul Rafay
- **Tags**: MobileDevelopment, ThoughtsProcess
- **Description**: In this post, I share the painful journey of deploying my Flutter-built Android app on the Google Play Store in 2025. From the introduction of strict new policies to the frustrating 12-tester requirement, this is a reality check for solo developers trying to publish apps today. If you're an indie dev, you need to read this.

We all know I develop Android and iOS applications using Flutter — and I’m pretty good at it. Building an application is just one part of the game. The real challenge often lies in the second part: **deploying** those applications to the respective app stores.

Now, here's the truth:\
I mainly develop Android applications because I **don’t own an Apple device**, which means I can’t test or deploy apps to the Apple Store. That’s a story for another day.

But today, we’re going to talk about something closer to home — the **harsh reality of deploying Android applications on the Google Play Console in 2025**.

> Buckle up, because it’s going to be a hell of a ride.

This blog post is my personal journey of deploying an Android app after a long time. Things have changed, and if you’re getting back into it after a while, you might want to read this all the way through.

## A Little Context

In one of my previous blog posts, I shared the journey of building a new Android app called **[MS Bridge](https://ms-bridge-app.vercel.app/)**. It’s a simple note-reading and note-taking application — something I built because I was never really a fan of Google Keep. I wanted to create a tool that met **my own workflow** and personal needs.

And guess what?\
I actually use this app **every day**.

If you’re curious about the build process or want to see how I made it using Flutter, check out the full write-up [here](https://www.rafay99.com/blog/idea_to_app/). In that blog post, I dive into the architecture and the thought process behind the app.

## TL;DR

A while back, deploying apps on Google Play Console used to be **simple**:

- You paid a one-time $25 fee.
- Filled out your developer profile.
- Generated and uploaded a signed AAB file.
- Completed a few forms and privacy declarations.
- Shared demo credentials (if applicable).
- And then, waited 2–3 business days for a manual review.

If all was well, your app would go live and be available to users around the world. **Easy, right?**

Well, that was then.

## The Past: How It Used to Be

Back in the day, Google had **the most lenient rules** for deploying apps. Whether those rules were too relaxed is up for debate, but for indie developers like myself, it was manageable.

The flow was straightforward:

- Buy access to the Play Console for $25 (one-time payment).
- Verify your identity with a valid ID.
- Build and sign your APK or AAB file.
- Create a new release and fill out the required forms.
- Upload your AAB, and submit it for review.

If everything was filled out correctly, your app would get approved — no fuss, no confusion.

It was a **solo dev's dream**.

Absolutely, here's a refined and polished version of your paragraph with proper grammar, improved flow, and a tone that still sounds like _you_. I’ve also made it blog-ready and added it as a continuation of the previous section.

## The Present: A Reality Check (continued)

In late 2022, Google announced a major update to the Google Play Console — and with it came a new policy that hit indie developers the hardest.

Both **individual developers** and **companies** are now required to meet at least **12 testing requirements** before submitting an app for review. You can read the full breakdown of the policy [here](https://support.google.com/googleplay/android-developer/answer/15899442).

And let me tell you — this was a **huge pain point** for me.

As a solo developer, I handle everything myself: designing, building, testing, and deploying the app. But now, before even submitting the app for review, I need **12 testers**, each with a **different Google account**, using **12 different physical devices**, who must test the app for **at least 4 minutes straight**.

Seriously?\
This feels absurd.

I don’t have access to 12 Android devices. Devices are **expensive**, especially in my region. And coordinating 12 unique testers with valid Google accounts just to meet a requirement? That’s a lot of overhead for someone working alone.

To be fair, I understand where Google is coming from. They want to **prevent low-quality or crash-prone apps** from reaching production. In the past, many developers pushed broken apps to production without proper testing, which damaged user experience and hurt the reputation of the Play Store.

So yes, the **intent** behind this policy makes sense — but the **execution**? Not so much.

For solo devs and small teams, this is a major hurdle. And it’s one more reason why deploying Android applications is no longer the simple process it used to be.

## So... What’s This “12 Testers” Requirement Anyway?

Let’s get into the juicy part — the actual “12 testers” rule that tripped me up.

If you’re reading this and wondering, “Wait, what even is that?” — you’re not alone. It’s a relatively new policy introduced by Google, and it’s mainly targeted at new developer accounts.

Basically, if your **Google Play Console account was created after November 13, 2023**, and it's a **personal (individual) account**, then buckle up: you **must run a closed test with at least 12 testers** before even thinking about going public with your app.

Let me break it down:

- You need **12 unique testers** (yes, actual humans with different Google accounts).
- These testers must **opt into a closed testing track** and **keep the app installed for 14 consecutive days**.
- It doesn’t matter if they use it every day — just that they opted in and didn’t uninstall the app during that period.
- Only after that test run can your app even be considered for **production release**.

This is Google’s way of filtering out buggy, unstable, or half-baked apps from flooding the Play Store — which, let’s be real, used to happen a lot.

Fun fact: when this policy was first introduced, the requirement was **20 testers**, but later they brought it down to **12** — probably because of all the backlash from indie devs like us who don’t have the time, energy, or reach to coordinate that many testers for every app.

For me personally, this was the most frustrating part. I don’t have a huge community or team. I’m a solo dev. I make things that I need and want to share with others. Getting 12 people with different devices and accounts, and making sure they stick around for two weeks? That’s just not feasible all the time.

Sure, you can ask friends and family or reach out to communities online, but it’s still a hurdle that didn’t exist before. Some even use paid tester platforms now — yes, that’s a thing.

At the end of the day, I get why Google introduced this rule — they want to protect the store from poor-quality apps and ensure a smooth user experience. But as someone who’s been deploying Android apps for years, this change hit hard. And it's not exactly beginner-friendly.

## Tips or Workarounds

After all this, you’re probably wondering: _“Okay, so what’s the workaround?”_

Well — there really **isn’t one**. You **can’t bypass** the 12-tester requirement if your account is new and falls under the policy. It’s mandatory, and Google will not let you move to production without completing it.

But that doesn’t mean you’re stuck.

Here are a few ways you can get those 12 testers and make the process a little smoother:

- **Reach out to developer groups on Reddit/Discord**\
  Communities like r/FlutterDev, r/androiddev, or niche Discord servers often have devs willing to help out. Just be transparent and respectful when asking.
- **Use Firebase App Distribution**\
  This is a great tool for sharing your app easily and collecting feedback — even if it won’t fulfill the Play Console requirement, it helps make sure your app is solid before you go hunting for testers.
- **Ask friends, classmates, or colleagues**\
  Sometimes, all it takes is a WhatsApp message to people in your circle. If they have Android phones and Google accounts, you’re halfway there.
- **Post on LinkedIn or Twitter (X)**\
  Mention you're looking for testers for a new app. You’d be surprised how many in your extended network are willing to help.
- **(Optional) Use paid tester platforms**\
  There are platforms where you can pay to get real testers (e.g. BetaFamily, Test IO). I haven’t personally tried this route yet — but it’s out there if you're short on time or community.
- **Join indie dev circles or Telegram groups**\
  Many regions have active tech Telegram groups — these are goldmines for finding supportive devs who’ve been through the same grind.

At the end of the day, yes — this is extra effort. But it’s part of the game now. If you’ve built something valuable, it’s worth that extra hustle to get it out there.

## Conclusion

Deploying an Android app in 2025 isn’t what it used to be — especially for solo developers.

What was once a fairly straightforward process has now become a complex dance of policies, forms, and mandatory testers. And while I understand Google’s motivation behind these changes, it still feels like a heavy burden for indie devs who are building out of passion, not profit.

But here’s the thing — we don’t build because it’s easy.\
We build because we love creating. Because we see a problem and want to solve it. Because we want to share something useful with the world.

So yes, the road is harder now. But it’s not impossible.\
With the right support, the right community, and a little persistence, we _can_ get through the red tape and ship great apps that actually help people.

If you're going through this right now, you're not alone.\
And if you've already been through it and survived — hats off to you. ✌️

Let’s keep building. Let’s keep sharing.\
And maybe, just maybe, let’s hope Google finds a better balance in the future for solo devs who just want to make cool stuff.

Until then, peace out, nerds. 👓

---

# Why Vibe Coding is Taking Over the Dev World

- **URL**: https://www.rafay99.com/blog/rise-of-vibe-coding/
- **Published**: 2025-03-26
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess
- **Description**: Explore how Vibe Coding is reshaping software development.

Not too long ago, I was scrolling through YouTube when I stumbled upon a video from Theo titled My Thoughts on Vibe Coding. At first, I had no clue what vibe coding was. I was like, _What is this? What's going on?_ And suddenly, it was everywhere—trending on X, YouTube, and the entire software development community.

If you're curious, check out Theo's video:

It’s a great watch, and I definitely learned a lot from it. But after watching, I had more questions than answers. So, I decided to do some digging—what exactly _is_ vibe coding?

# What is Vibe Coding?

After the video, I went straight to Google and searched _What is vibe coding?_ Here’s what I found:

> "Vibe coding" refers to a trend in software development where individuals use AI tools, like large language models (LLMs), to generate code by describing their ideas in plain language. This shifts the focus from manual coding to guiding and refining AI-generated code.
> Here's your revised text with grammar fixes while keeping the flow and tone intact:

# Why is Vibe Coding Taking Over?

We've seen how AI is changing the software development landscape, and Vibe Coding is just one example of how it's being used. Heck, I've used AI to develop apps and solve a lot of errors that occurred in the codebase. I use AI to generate docs, create tests—but if all of this is happening, why is it trending everywhere? On X, YouTube, and across the entire software development community?

The main question is: why is this term suddenly being used so much, and why is it being called a bad thing? The interesting thing to me is that just a month ago, everyone was using AI, and then all of a sudden, everyone is against it. I think it's because a few marketing people and tech CEOs are pushing the idea that AI coding is the future.

## Deep Search

I decided to do some deep research, and I came across four interviews where CEOs from different AI companies are claiming that Vibe Coding is the future.

Here they are:

- [Y Combinator](https://www.youtube.com/watch?v=IACHfKmZMr8)
- [Claude CEO](https://www.youtube.com/watch?v=cMApO0UhqEs&t=62s)
- [OpenAI CEO](https://www.youtube.com/watch?v=Nl1-ZqdZx0E)
- [Meta CEO](https://www.youtube.com/watch?v=7k1ehaE0bdU)

I've watched these videos, and in each of them, in some form or another, the CEOs are saying that Vibe Coding is the future. I have mixed feelings about this. This is happening because of marketing—they are pushing this idea so that developers spend money on their services.

Things like AI code editors, chatbots, AI agents—all these services are designed to hook new developers, making them so dependent on AI that they can't leave it.

# The Thoughts

Before I tell you how to do Vibe Coding, you should understand the difference between programming and coding. Sure, these things might seem the same, but under the hood, they're totally different.

Coding is the process of writing instructions for a computer to execute. It’s like giving a robot a set of steps to build a house. Programming, on the other hand, is about designing how the house will be built—it's the combination of writing instructions and the logic behind them.

Programming is the **brain** of the house—the blueprint that tells the robot how to build it from scratch.

## The Difference

Here's a table highlighting the key differences between **coding** and **programming**:

| Aspect            | Coding                                                              | Programming                                                                |
| ----------------- | ------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| **Definition**    | Writing code that computers can understand.                         | The broader process of developing a complete software solution.            |
| **Scope**         | Focuses on translating logic into a specific syntax (writing code). | Involves planning, designing, debugging, testing, and maintenance.         |
| **Skills Needed** | Basic knowledge of syntax and logic.                                | Requires problem-solving, algorithms, data structures, and system design.  |
| **Tools Used**    | Code editors (VS Code, Sublime Text).                               | IDEs, version control (Git), compilers, debuggers, and testing frameworks. |
| **Complexity**    | Less complex, mainly syntax-focused.                                | More complex, involving architecture, debugging, and optimization.         |
| **Output**        | A working piece of code or script.                                  | A fully functional software or application.                                |
| **Example**       | Writing a simple Python script to print numbers.                    | Developing a full web application with frontend, backend, and databases.   |

In short, **coding** is a subset of **programming**—programming is the entire process, while coding is just one step of it.

# The Problem

Not too long ago, I wrote an article called _My Love and Hate Relationship with GitHub Copilot_, where I talked about how this AI train has made me both a better and worse software engineer.

The core issue is that as new developers enter the industry, they might not learn how to do the basics. They don't understand how to debug an app, how to make good decisions, how to identify problems. They might know **what** to do, but they’ll just throw in some prompts and hope for the best—getting stuck in a loop where AI makes decisions for them, and the cycle never ends.

They aren’t learning how to solve problems. They don’t understand **how to think**. They’re just copy-pasting code from the internet and hoping it works.

If you’d like to read my blog post, just [click here](https://www.rafay99.com/blog/mylovehaterelationshipwithcopilot). I also made a video about this and saw this problem coming a mile away.

# The Solution

There is no perfect solution to this problem, and we can't stop it from happening. I saw a person on X who used AI to create a game and made millions, but a few days later, the app was shut down because of a bad codebase—he didn't know what to do.

See, without understanding core concepts, this will destroy your career and your skills.

But if you still want to use AI for your upcoming projects, I have a solution for you. When using AI to build products or write code, keep these points in mind:

### 1. Choose the Right Stack

- Pick a stack that is simple and one you understand well—something like React, Express, Tailwind, Redis, Deno, or even Node.js. The reason is that these LLMs are good at solving problems that have already been solved before.  
  They are just autocomplete tools, not problem-solving tools.
- So if you go with something new, like a tech stack that was launched a month ago, it's going to kill your vibes.
- Here's the thing: AI is trained on Stack Overflow, GitHub, and Reddit databases. If you're using a brand-new stack, it won’t have enough data to solve your problem.

### 2. Please Learn Git and GitHub

- If you're going to use AI and embrace it fully, you must save your code before everything goes to hell. If you still don't know Git, please learn it from my [blog post](https://www.rafay99.com/blog/managegit).
- This will make things so much better because you can always go back to a previous version of your code if something goes wrong.

### 3. Think Like a Project Manager

- When using AI, you're not just writing code—you’re building a product. You need to think like a project manager. Break your project down into smaller parts.
- Each section should have all the details AI needs to understand it better, but **you** should be the one making the decisions—not the AI.
- Be very specific and provide context because AI will forget what you've been working on over time.

There’s a new term for this called **"Prompt Engineer."** I hate this term so much. I’ve seen it all over the internet, and it’s just a fancy way of saying, **"I use AI to write code."**

If you want to learn more, check out this awesome video by Fireship on YouTube:

# How Vibe Coding Works

Vibe coding is all about the back-and-forth between you and AI. You give instructions in plain English, and the AI translates them into working code. It’s like having an overpowered autocomplete that doesn’t just predict words but entire functions, components, or even full apps.

Here’s how the process usually plays out:

1. **Describe what you want** – Say you need a simple weather app. Instead of writing out all the HTML, CSS, and JavaScript yourself, you just tell the AI:

   > “Create a web page that lets users enter a city and shows the current weather.”  
   > This is your _prompt_.

2. **AI generates the code** – Based on your description, the AI spits out a rough version of your app. It might generate the HTML structure, write the JavaScript for fetching weather data, and even add basic styles. It’s like having an assistant who just _gets it_ (well, most of the time).

3. **Review and refine** – The first draft isn’t always perfect. Maybe the design looks bland, or there’s no error handling. So you tell the AI:

   > “Make it more colorful and add error handling if the city isn’t found.”  
   > The AI tweaks the code accordingly.

4. **Repeat until it’s right** – You keep refining through quick iterations—describe the change, get updated code, test it—until everything works as expected.

# Final Thoughts

AI is a powerful tool, but it’s just that—a tool. It can assist you, speed up your workflow, and help you solve common problems, but it cannot replace true problem-solving skills, creativity, and deep technical knowledge.

If you rely too much on AI without understanding the fundamentals, you’ll be stuck in an endless loop of prompting and hoping for the best. The best developers don’t just write code—they think critically, design solutions, and make informed decisions.

So, use AI wisely. Let it assist you, but don’t let it think for you. Stay in control, keep learning, and make sure you are the one driving your career—not the autocomplete.

Until then, peace out, nerds. 💕

---

# Idea → Code → App: My Build Story

- **URL**: https://www.rafay99.com/blog/idea_to_app/
- **Published**: 2025-03-16
- **Author**: Abdul Rafay
- **Tags**: MobileDevelopment, ThoughtsProcess
- **Description**: Let me show you how a small idea evolved into a complete app. I’ll share my workflow, tools, and lessons learned

Alright, let's hear it. We've all been there—you have an idea for an app that could help you out, and you realize it could help others as well. But you don’t know how to create a good application, or moreover, you have no idea how to build one.

Now, you go on YouTube and start searching, and the number of videos is overwhelming. You watch one, then two, but when it comes down to actually starting from nothing, things start to get a little rough.

You don’t know the app flow, how users will interact with it, or even what features you need. And that’s perfectly normal. As a beginner trying to build an app, you don’t yet understand how things should flow.

The purpose of this blog post is to show you all how to build an app from scratch. I’ll go through everything—from the idea to development, all the bugs I encountered, how to solve them, and how AI can be helpful.

# The Idea?

For this app, I was writing my notes on a website and could access them via the web. But what about mobile? It was really inconvenient to open a browser, enter a URL, and then visit my notes. And sometimes, the internet isn’t reliable. So, now what?

The solution for me was simple—I needed an app where I could read all my lecture notes with offline access.

With that in mind, I started writing down what I needed. The core idea was that I should be able to read my notes without an internet connection. My website already has API access, so I could call that API and render the content in the app, right?

It’s simple and can be done.

# The Features

Once the core idea was set, it was time to think about what features would support it and ensure the app wasn’t misused. So, I added these features:

1. Offline & Online Access
2. Auth System
3. Color Choices
4. Note-Taking

These features would make note reading much smoother and more convenient.

# Tech Stack

Once you have all the features listed and know what you want, the next step is choosing a good tech stack. People say it doesn’t matter what tech stack you choose, but let me tell you—when it comes to apps, you generally have four options for the frontend:

1. Flutter
2. React Native
3. Java (Android)
4. Swift (iOS)

And for the backend, there are several good options:

1. Firebase
2. Supabase
3. Appwrite
4. PocketBase

All of these options have their own pros and cons. If you’d like to see a core difference between Firebase and Supabase, check out my previous [blog post](https://www.rafay99.com/blog/firebase-vs-supperbase/).

I haven’t used PocketBase or Appwrite yet, but I’ve heard they are good options.

## My Choice

For me, I’ll be using Flutter for the UI and Appwrite for the backend. The backend will handle user sync, note-taking, user authentication, and the auth gate—nothing more than that. The UI will be coded using Flutter because I use Flutter for everything, and I love its flexibility.

## Your Choice

Don’t choose blindly—do your research and pick what makes you comfortable and what you feel confident coding in. If I weren’t used to Flutter, I would have gone with React Native, since I know how React works but have no experience with React Native. So, choose what works best for you.

# Defining The Flow

You know the features, you know how to choose a tech stack, now it's time to define the flow. By flow, I mean how the user will navigate from one page to another. And this is actually very simple. When a user installs your application, what will they see first? It could be a Login Screen, an Introduction Screen, a Splash Screen, anything—it all depends on your thought process and your application.

Here’s the flow I created for my application:

## The Auth Flow

The auth flow shows how the authentication process is handled in the app.

### Login Flow

- Installed -> Introduction Screen -> Login -> Success -> Home Screen
- Installed -> Introduction Screen -> Login -> Failed -> Error Message

### Register Flow

- Installed -> Introduction Screen -> Register -> User Created -> Login -> Success -> Home Screen
- Installed -> Introduction Screen -> Register -> User NOT Created -> Error Message

### Auth Gate

- User Logged In -> Home Screen
- User Not Logged In -> Login Screen

## Note Fetching Feature

This flow illustrates how the app operates under the hood.

### Getting Notes via API

- App Opened -> Internet Connection -> Call API (Get Data) -> Store in Local Database -> Show to User
- App Opened -> NO Internet Connection -> Switch to Offline Mode

### Taking Notes

- Open App -> Switch to Note-Taking UI -> Create Note -> Write Some Content -> Save Content

## Flow Thoughts

You can see how the app flow is structured. This is just the beginning. As you add more features, you’ll naturally have more flows to define. It’s better to set up a structure early and start coding, because as you develop, the flow will reveal itself more clearly.

I’m only able to describe this flow because I’ve actually done it—I’ve built the app, faced real challenges, and figured out how each UI should connect to the next.

# Coding

Okay, you have everything set up. Now what? This is the question most people don’t know how to answer. You’ve got the design, the flow, the idea, and the tech stack. What’s next?

Here’s the short answer: Google and use AI.

In the beginning, Google _a lot_. Don’t just rely on AI—you’ll forget what you learn that way. Google, Stack Overflow, documentation—they'll stick in your brain better. Watch some tutorials to get a solid foundation. And then... start coding.

# My App Issues (The Rollercoaster)

Now, let me be honest. It wasn’t all sunshine and rainbows.

I initially aimed to finish the app in a week. If you look at my GitHub, it did take me about a week—but, oh boy, it wasn’t easy.

### Appwrite Woes

Everything started fine. I created the UI, set up Appwrite as the backend, and things were rolling smoothly. Until... Appwrite refused to add users to my database. I tried everything, but the issues just kept stacking up. So, I decided: forget this, I’m switching to Firebase.

Thankfully, I had separated my UI from my backend. All I had to do was change the backend implementation. Nothing broke in the frontend—lesson learned: keep frontend and backend loosely coupled via a repository file where all the logic meets.

### API Struggles & Hive Mastery

Once Firebase was up and running, it was time to fetch notes from my website's API. I used the `http` package from pub.dev, which worked fine. But for some reason, the body of the notes wasn’t coming through.

To handle offline data, I integrated Hive, which was great, but initially tricky to set up. I created models, commands, and started syncing API data to Hive. The issue? Still no note body! Eventually, after hours of frustration, it turned out the API itself had the problem, not Hive.

Once fixed, data was flowing and saving properly.

### UI Layer & Card-Based Madness

Next challenge: UI design. There were multiple subjects, multiple lectures, and I wanted a card-based interface. One card leads to another, leading to lecture notes at the end. I made templates to dynamically pass data—whether it's research notes, lecture notes, etc.—and the experience became seamless.

### Search: Fizzy Finder or Bust

Search was another beast. Firebase’s built-in search? Nah, it won’t cut it. I wanted powerful search capabilities, so I turned to Fizzy Finder and built my own search functionality. This was crucial for scaling.

# Note-Taking Feature (The Hell Moment)

After deploying V1, I decided to add a note-taking module. The big question: What editor? Markdown, Rich Text, something else? I found [Flutter Quill](https://pub.dev/packages/flutter_quill)—perfect!

Or so I thought...

I installed it, ran the emulator... and everything broke. Dependency hell. Turns out Flutter Quill v2.9 had conflicts with my Introduction Screen package. I had to pick one. So, Introduction Screen had to go. I rebuilt the entire introduction UI from scratch with custom animations and flows. Painful—but fun.

Once that was sorted, Hive became my best friend again. I created `Hive Operations` and `Note Taking Actions` services. I set up controllers, wired everything up, and data was being saved smoothly.

### Google Keep-Inspired UI

For displaying notes, I wanted something like Google Keep. I wasn’t sure how to achieve this, so I turned to Google Studio AI—it generated a UI I didn’t _love_, but hey, it worked.

### CRUD’s Biggest Nightmare: Deleting Notes

Deleting notes became my nemesis. I wanted a recycle bin feature. Hive doesn’t support moving content between boxes. So, I had to manually copy content from one Hive box to another, then delete it, and vice versa if restoring. Hive team, if you’re reading: please add move support—it would make life so much easier!

# The Sync Layer (The Final Boss 💀)

One thing left: the sync layer.

All notes were stored locally, but users needed backups in the cloud. Easy in theory, painful in practice.

Where should sync happen? How should users know if their data is backed up? At first, I triggered sync on save, update, delete—but it slowed down the app by 2-5 seconds. Not acceptable.

Solution? Sync runs when the app launches. It detects changes and pushes them to Firebase. I added settings to give users control over sync, and made sure sync runs off the main thread so the UI stays smooth. (Shoutout to AI for helping me figure this out—I was lost!)

# Wrapping It Up

After all the battles, late nights, and debug sessions, I finally had a polished app. I called it **MS Bridge**.

Every flow, feature, and issue taught me something valuable. And trust me, whatever app you’re building, you’ll hit similar hurdles. Just stay patient, keep separating concerns, Google like crazy, and enjoy the ride!

# Try It Out Yourself

### Download App

The app isn’t live on the Google Play Store just yet, but you can still give it a spin!
Simply head over to my website or download it directly using the link below:

👉 [Download MSBridge APK](http://rafay99.com/downloads/app/msbridge/release/MSBridge-release.apk)

### &#x20;Explore the Codebase

Curious to see how I built this? Check out the entire codebase on GitHub:

👉 [MSBridge GitHub Repository](https://github.com/rafay99-epic/MSBridge)

I’d love to hear your thoughts!
Tell me how I coded, what you liked (or didn’t), and how badly I might have messed things up 😄.
Drop your feedback, suggestions, or even a roast in the comment section—I’m all ears! 👇

# Final Thoughts

Now, it’s time for some final thoughts. I did this not just because I’m getting a blog post and a future video out of it, but more importantly—because it was fun. Coding for fun is something I’ve missed, and writing down my thoughts, sharing my experiences—that’s something I truly enjoy.

Here’s the thing: don’t be afraid. You’re an engineer. You’re _meant_ to break things, to see how they unfold, to figure out how things can be done. Coding is fun. Find an idea, and start building. It might look like chaos at times—some parts definitely felt like that—but I genuinely enjoyed every bit of it.

So go on, start coding.

Until then, goodbye nerds.

---

# The Truth About Contact Forms: They Suck (and My Astro Debugging Nightmare)

- **URL**: https://www.rafay99.com/blog/contact-form-suck/
- **Published**: 2025-02-17
- **Author**: Abdul Rafay 
- **Tags**: ThoughtsProcess, WebDevelopment
- **Description**: "Contact forms suck," says this developer, who braved Astro debugging hell to find a (not-so-perfect) solution for a simple problem.

**The Truth About Contact Forms: They Suck (and My Astro Debugging Nightmare)**
You heard the title right—I’m here to expose the reality of contact forms. And let's be real: contact forms _suck_. I'm not just saying that to be edgy; I'm talking from experience. How many times have you filled out a form, hit submit, and then _crickets_? Or worse, you get a "Server Error" when all you wanted to do was ask a simple question? Yeah, contact forms are a menace, a spam magnet, and often a UI/UX disaster on mobile. I've built countless websites, tested every implementation under the sun, and I'm here to tell you exactly why they fail...and whether there's _any_ hope for making them less awful.

Before we dive in, you might be wondering: _What even is a contact form? Why do they suck? Is there a way to make them better?_ Spoiler alert: the answer to the last one is a _maybe_ with a heavy dose of "it depends." But if you're a developer, trying to build a functional, user-friendly contact form from scratch, this post is for you. If you're happily using WordPress or Shopify... well, you're probably living in a blissful alternate reality, and this post might just ruin your day. Consider yourself warned!

### A Quick Note

> If you're using platforms like WordPress or Shopify, this might not apply to you. But if you're a developer trying to build a functional, user-friendly contact form from scratch, this post is for you.

### What is a Contact Form?

At its core, a contact form acts as a bridge between users and website owners. If a user has a question, feedback, or an issue, they can fill out the form to send a message. Typically, the form is connected to an email provider or a database, ensuring that messages reach the intended recipient.

In simple terms, a contact form helps users reach out without directly exposing an email address.

## The Problem: My Astro Contact Form Debugging Vortex

Let me first explain the issue before diving into the solution. My personal site, built with **Astro**, includes a **Connect with Me** section with two contact forms—one on a dedicated page and another built into the homepage. Both forms share the same logic but have completely different UI designs. I thought I was being clever, making them reusable and all that... little did I know, I was about to enter a debugging vortex from which I might never return!

Since Astro supports both **Server-Side Rendering (SSR)** and **Static Site Generation (SSG)**, I configured my project to use SSR. This allows me to integrate interactive UI components using **React**.

To make the contact form reusable, I structured it as follows:

- **ContactForm.tsx** → The UI component.
- **useContactForm.tsx** → A custom hook handling form submission.
- **submit.ts** → The API route handling the request.

The idea was simple: the form UI would send data to the hook, which would then call the API to submit the form. If I ever wanted to switch from **Web3Forms** to another service, I could simply change the API call without modifying the rest of my code.

Here's the sequence diagram explaining my approach:

![Contact form error message showing validation failure](https://utfs.io/f/TViMykBJnLIJs3J0bAVuaXy980xWDv1YnVfghNKtcoeEkFsd)

Everything seemed perfect—reusable, modular, and scalable. But in reality, things weren’t that simple. I spent an entire day debugging without any progress.

### The Unexpected Error

The form submissions **were reaching my email**, yet the UI kept displaying **"Server Error"**. Even the server logs showed errors, despite the **network requests returning a 200 status**. This was **weird**—the API was clearly working, but the UI still showed an error. WHAT?! A 200 status code but an error on the front end? I felt like I was in the Twilight Zone. 🤯

I spent days debugging. I checked the **Network tab in Chrome DevTools**, expecting to find an issue with my request. But everything looked fine—status 200, no CORS errors, no missing headers. I even tested the API separately in **Postman**, but the issue persisted.

At this point, I was convinced that my **code wasn't the problem**. Maybe Web3Forms itself was causing the issue?

Then, after some modifications, a **new error appeared**:

```javascript
Web3Forms Request Failed: TypeError: fetch failed
    at node:internal/deps/undici/undici:13392:13
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Module.POST (D:/Astro-Portfolio-Blog/src/pages/api/submit.ts:27:24)
    ...
    [cause]: ConnectTimeoutError: Connect Timeout Error (attempted address: api.web3forms.com:443, timeout: 10000ms)
```

This was a **timeout error**, meaning the request was taking too long to connect. But Web3Forms' official documentation didn’t mention any timeout limits. So why was this happening? Was Web3Forms secretly powered by hamsters on a wheel? 🤔

To fix this, I decided to **handle timeouts manually** in my API by setting an explicit timeout and catching errors properly. Here’s the final version of my **submit.ts** file:

```javascript
const controller = new AbortController();
const timeout = setTimeout(() => controller.abort(), 15000);

try {
  const response = await fetch("https://api.web3forms.com/submit", {
    method: "POST",
    body: submitFormData,
    signal: controller.signal,
  });

  clearTimeout(timeout);
  const data = await response.json();

  if (!response.ok) {
    throw new Error(data?.message || "Web3Forms submission failed.");
  }

  return new Response(
    JSON.stringify({ success: true, message: "Message sent successfully!" }),
    { status: 200, headers: { "Content-Type": "application/json" } },
  );
} catch (error) {
  if (error.name === "AbortError") {
    console.error("Web3Forms Request Timed Out");
    return new Response(
      JSON.stringify({ success: false, message: "Request timed out." }),
      { status: 504, headers: { "Content-Type": "application/json" } },
    );
  }
  console.error("Web3Forms Request Failed:", error);
  return new Response(
    JSON.stringify({ success: false, message: "Failed to contact Web3Forms." }),
    { status: 500, headers: { "Content-Type": "application/json" } },
  );
}
```

### The New Issue

After implementing this, I expected everything to finally work. **But no.** A new problem arose. Even though the timeout issue was handled, **sometimes the request would still fail randomly**. Seriously? I was starting to think contact forms were cursed. 👿

So now, the question is: **Is this an issue with Web3Forms, Astro's API routes, or something else entirely?** At this point, I was half-tempted to just ditch the whole thing and tell people to contact me via carrier pigeon.

This journey has been full of surprises, and I’ll go into **how I finally solved it** in the next section.

## New Service: The Hunt for a Less Terrible Option

At this point, I was _done_. Debugging, trying new things, rewriting code, and debugging again—I needed a solution. So, I started searching for alternatives, and oh boy, I was in for another few days of torture. And no, I’m not talking about the code itself—I’m talking about the sheer number of services available for something as simple as a contact form. It's like everyone and their grandma has a contact form service these days!

From my experience, there are two ways to get a contact form working:

1. **Connecting the form to a database** (which felt like overkill for a simple contact form)
2. **Using a service that forwards form submissions to your email**

I was using **Web3Forms**, which is a great service if you have a static HTML, CSS, or JavaScript-based website. But the moment you introduce React into the mix—things start breaking. And since I was using React within Astro, this became a huge headache.

### The Hunt for an Alternative

So, I went on the hunt for a new service. There are quite a few out there, but let me tell you—some of them have insane pricing. Some don’t even have a free tier! As a solo developer, I’m not about to drop **$10/month** just to get a contact form working. That's like half my coffee budget! ☕️

Here are some of the services I looked into:

1. **[Formspree](https://formspree.io/)** – A solid service, but no free tier. If you’re running a site with high traffic, this might be worth it, but for a solo dev like me? Not so much. I tried their solution, but just like Web3Forms, it didn’t work smoothly with React. Plus, their documentation felt like it was written in hieroglyphics.

   ![Screenshot showing](<https://utfs.io/f/TViMykBJnLIJn3kz38wIMZG7ue52pCHBh13zVjoUnaQK4Nkm>)

   As you can see, the pricing is steep for a small personal site. If you have a larger user base, this might work, but for me, it just wasn’t feasible.

2. **[FormBold](https://formbold.com/)** – Another solid option, but again, no free tier. Their pricing structure is almost identical to Formspree, which makes it just as inaccessible for small personal projects.

I also briefly considered X, Y, and Z, but their privacy policies made my skin crawl. I'm not about to sell my users' data just so they can send me a message!

Many of these services are great, but from a cost perspective, they just don’t make sense for someone like me. Spending **$10/month** on a contact form is simply too much, especially when the free plans don’t offer useful features.

Meanwhile, Web3Forms does have a free plan—but unfortunately, after all my testing, I just couldn’t get it to work properly with React and Astro. It was a classic case of "too good to be true."

## The Solution: Embrace the Hack (Maybe?)

Okay, full disclosure: what I ended up doing isn't exactly going to win any awards for code elegance. But after days of wrestling with Web3Forms, React, and the mysteries of Astro's API routes, I was desperate. I needed something that _worked_, even if it meant sacrificing a bit of code purity.

So, I did what any sane (or perhaps insane) developer would do: I reverted to a plain Astro component with inline `<script>` tags. Yes, you read that right. I know, I know\... it's like going back to the Stone Age of web development. But hear me out!

See, Web3Forms _seemed_ to only play nice when it was dealing with static HTML and JavaScript. The moment React got involved, things went haywire. I suspect it's something to do with how React handles the form lifecycle or maybe some weird timing issue. Whatever the reason, the only way I could get Web3Forms to reliably send emails without throwing random errors was to bypass all the fancy React hooks and API routes and just... _make it static_.

\[Show a screenshot of the code here, maybe with a circle around the `<script>` tags and a "Don't judge me!" caption]

Here's the code I wrote for the contact form:

```javascript
---
try {
  if (!featureFlags.showContact) {
    return Astro.redirect("/access-denied");
  }
} catch (error) {
  return Astro.redirect("/404");
}
---

<html lang="en">
  <head>
    
    
  </head>
  <body>
    
    <main>
      <h1 class="text-5xl text-center font-bold mb-6">Let's Collaborate</h1>

      <section class="flex justify-center items-center bg-[--accent-dark] px-4">
        <div
          class="w-full max-w-5xl bg-[--gray-gradient] p-10 rounded-2xl border border-[--gray] mt-6"
        >
          <form
            class="space-y-4"
            id="form"
            action="https://api.web3forms.com/submit"
          >
            

            <div>
              <label class="block text-[--text-light] mb-1" for="name">Your Name</label>
              
            </div>

            <div>
              <label class="block text-[--text-light] mb-1" for="email">Email</label>
              
            </div>

            <div>
              <label class="block text-[--text-light] mb-1" for="message">Message</label>
              <textarea
                id="message"
                name="message"
                class="w-full p-3 rounded-lg bg-[--gray-dark] text-[--text-light] border border-[--gray] focus:outline-none focus:ring-2 focus:ring-[--accent]"
                rows="4"
                placeholder="Write your message..."
                required
              ></textarea>
            </div>

            <div class="h-captcha" data-captcha="true"></div>

            <button
              type="submit"
              class="w-full p-3 bg-[--accent] text-[--text-light] rounded-lg hover:bg-opacity-90 transition"
            >
              Send Message
            </button>

            <div id="result" class="hidden text-center p-3 mt-4 rounded-lg"></div>
          </form>
        </div>
      </section>
    </main>

    

    <script is:inline>
      document.getElementById("form").addEventListener("submit", function (e) {
        const hcaptchaResponse = document.querySelector('textarea[name="h-captcha-response"]');
        if (!hcaptchaResponse || hcaptchaResponse.value === "") {
          e.preventDefault();
          alert("Please complete the hCaptcha.");
        }
      });
    </script>

    <script is:inline src="https://web3forms.com/client/script.js" async defer></script>

    <script is:inline>
      const form = document.getElementById("form");
      const result = document.getElementById("result");

      form.addEventListener("submit", function (e) {
        e.preventDefault();

        const formData = new FormData(form);
        const object = Object.fromEntries(formData);
        const json = JSON.stringify(object);

        result.className = "block bg-gray-600 text-white text-center p-3 mt-4 rounded-lg";
        result.innerHTML = "Please wait...";

        fetch("https://api.web3forms.com/submit", {
          method: "POST",
          headers: {
            "Content-Type": "application/json",
            Accept: "application/json",
          },
          body: json,
        })
          .then(async (response) => {
            let json = await response.json();
            if (response.status == 200) {
              result.className = "block bg-green-600 text-white text-center p-3 mt-4 rounded-lg";
              result.innerHTML = json.message;
            } else {
              result.className = "block bg-red-600 text-white text-center p-3 mt-4 rounded-lg";
              result.innerHTML = json.message;
            }
          })
          .catch((error) => {
            console.error(error);
            result.className = "block bg-red-600 text-white text-center p-3 mt-4 rounded-lg";
            result.innerHTML = "Something went wrong!";
          })
          .then(() => {
            form.reset();
            setTimeout(() => {
              result.classList.add("opacity-0", "transition-opacity", "duration-500");
              setTimeout(() => {
                result.classList.add("hidden");
                result.classList.remove("opacity-0");
              }, 500);
            }, 3000);
          });
      });
    </script>
  </body>
</html>
```

I created a contact section with a form, where two key elements play a crucial role:

1. The `#result` element, which displays feedback messages (because who doesn't love instant gratification?).
2. The `hCaptcha` field, because spam bots are the bane of my existence.

By utilizing inline `<script>` tags within the Astro component, I ensured that these scripts are only executed when needed. While this may not be the most elegant approach, it was the _only_ way to make Web3Forms work seamlessly in a static environment.

So, is it perfect? Absolutely not. Is it a bit of a hack? You bet. But does it (mostly) work? Yes! And sometimes, in the world of web development, "mostly working" is a victory in itself.

## Final Thoughts: The Contact Form Struggle is Real

Building a contact form might seem like a simple task, but when you factor in React, Astro, and the sheer number of third-party services with their limitations, things can quickly spiral into frustration. Seriously, why is something so basic so darn hard?

I started with Web3Forms, which worked great for static sites but failed when React entered the equation. My search for an alternative led me to services like Formspree and FormBold, but their pricing made them unviable for a solo developer. Spending $10/month on something as basic as a contact form just didn’t make sense, especially when the free plans weren’t offering much value. I'd rather spend that money on coffee! ☕

This whole process made me realize something: sometimes, the simplest solutions are either broken or overpriced. If you're a solo developer like me, you’re either stuck with limited free options or forced to pay more than what feels reasonable for your needs. It's a constant battle between functionality and budget. 😩

At the end of the day, I needed a cost-effective, React-friendly contact form solution, and while my journey wasn’t smooth, it was definitely an eye-opener about the challenges of integrating third-party services in a modern web stack.

For now, the hunt continues. 🚀

So, have _you_ wrestled with contact forms in Astro or React? What's _your_ preferred (least terrible) solution? Let me know in the comments! I'm always looking for new (or at least slightly less painful) ways to solve this age-old problem.

Until then, peace out, nerds. 👓

---

# Flutter Stuck at 'Running Gradle Task assembleDebug'? Here's the Fix (2026)

- **URL**: https://www.rafay99.com/blog/flutter-gradle-task-assembledebug-stuck-solution/
- **Published**: 2025-01-17
- **Author**: Abdul Rafay
- **Tags**: MobileDevelopment, Flutter, Android, Debugging
- **Description**: Flutter stuck at 'Running Gradle task assembleDebug' forever? This step-by-step guide fixes it on Windows, Mac, and Linux — covers Gradle cache issues, exit code 1, stuck builds, and slow first builds.

Flutter is fantastic for developing anything from small apps to complex applications. I absolutely love using Flutter, but sometimes, it can be a real pain in the **you-know-what**. Managing different Flutter versions, dealing with various Java versions—yeah, it's not always smooth sailing. But there’s one error that has truly driven me _crazy_.

That error is: **"Running Gradle task 'assembleDebug'..."**.

Even after hours of searching, it feels like there’s a ton of misinformation out there. Stack Overflow? Not much help either. Most of the solutions you find might work on Linux or Mac but fail miserably on Windows.

After spending countless hours troubleshooting, I’ve finally figured out how to fix this problem for good, and I’m here to show you a step-by-step guide to solving it—no matter what platform you're on. Let’s get this figured out!

### Why Your Flutter App Gets Stuck at "Running Gradle task 'assembleDebug'..."

If you've ever worked with Flutter and got stuck at the dreaded **"Running Gradle task 'assembleDebug'..."** message that feels like it’s never going to end—trust me, I’ve been there. It’s one of the most frustrating things about working with Flutter. But the good news is, there are reasons for this issue—and yes, there are solutions!

#### What’s Causing This?

1. **First-Time Builds**\
   If you’re building your Flutter app for the first time (or after clearing the build cache), Gradle needs to download a whole bunch of dependencies. And if your internet connection isn’t great, it can take forever and look like it’s completely stuck.
2. **Outdated or Missing SDK Tools**\
   Sometimes, your Android SDK isn’t fully updated or doesn’t have the necessary tools installed. Since Flutter depends on Android’s build tools, Gradle can’t do its job if something is missing or outdated.
3. **Gradle Cache Issues**\
   Gradle is picky about its cache. If the cache gets corrupted or clogged with old files, it can endlessly try to work through the mess without getting anywhere.
4. **Unaccepted Android Licenses**\
   Flutter requires you to accept all Android licenses to function properly. If you haven’t run `flutter doctor --android-licenses` and accepted everything, Gradle might get stuck waiting for permission it never gets.
5. **Network Problems**\
   Gradle downloads a lot of stuff during the build process. If your internet connection is slow or unstable, it can lead to painfully long build times—or the process might look like it’s completely frozen.
6. **Emulator Glitches**\
   Sometimes, the problem isn’t even with Gradle itself. An Android Emulator with corrupted data can cause the build to misbehave or hang indefinitely.

#### Why Does This Keep Happening?

The main issue lies in how Gradle handles dependencies, caches, and external tools. Combine that with slow internet, outdated SDKs, or platform-specific quirks, and you’ve got the perfect recipe for frustration. Flutter builds rely heavily on external systems like Gradle and the Android SDK, so even a tiny problem in one area can throw the whole process off.

### Fixing the "Running Gradle task 'assembleDebug'..." Issue

Alright, let’s get straight to the point. If you’re stuck staring at the **"Running Gradle task 'assembleDebug'..."** message for what feels like forever, here’s the fix. Trust me, this works because I’ve been there and tried it all.

#### Step-by-Step Fix

1. **Open Your Flutter Project Directory**\
   Navigate to the root of your Flutter project. If you’re using a terminal, just `cd` into it.
2. **Switch to the Android Directory**\
   Change to the Android directory inside your Flutter project:

```bash
cd android
```

1. **Clean Gradle**\
   Run this command to clean Gradle:

```bash
./gradlew clean
```

This will clear out any cached or corrupted files that might be causing the hang-up.

1. **Build Gradle**\
   After cleaning, build Gradle by running:

```bash
./gradlew build
```

Or, to save time, you can combine the clean and build steps into one command:

```bash
./gradlew clean build
```

1. **Run Your Flutter Project**\
   Now you’re ready to run your project again. If you’re using VS Code, just hit **F5**, and Flutter will take care of the rest. Keep in mind, the **first time** Gradle runs `assembleDebug`, it’s going to take some time. Be patient—it’s normal!

### Conclusion

Getting stuck at **"Running Gradle task 'assembleDebug'..."** is one of the most annoying parts of working with Flutter, but it doesn’t have to drive you crazy. With the steps I’ve shared, you can fix the issue in no time and get back to doing what really matters—building your app.

Remember, the first Gradle build will always take some time, but once it’s done, everything will run much smoother. Don’t let this error slow you down; now you know exactly how to handle it.

Flutter is an amazing tool, and a little troubleshooting like this is just part of the journey. So, keep building, keep experimenting, and don't let a stuck Gradle task stop you from creating something awesome! 🚀

---

## FAQ: Common Flutter Gradle assembleDebug Questions

### How long should "Running Gradle task assembleDebug" take?

On a **first build**, it can take 5–20 minutes depending on your internet speed and machine. Gradle downloads all dependencies, SDK tools, and build artifacts from scratch. On subsequent builds, it should take 30 seconds to 2 minutes. If it's been stuck for more than 20 minutes on a first build, something is wrong — follow the steps above.

### What does "Gradle task assembleDebug failed with exit code 1" mean?

Exit code 1 means the Gradle build failed. The most common causes:

1. **Unaccepted Android licenses** — Run `flutter doctor --android-licenses` and accept all.
2. **Corrupted Gradle cache** — Run `cd android && ./gradlew clean` then rebuild.
3. **Missing or outdated Android SDK** — Run `flutter doctor -v` and fix any red items.
4. **Java version mismatch** — Flutter requires JDK 17+. Check with `java -version`.
5. **Network issues** — Gradle needs to download dependencies. If you're behind a firewall or proxy, configure Gradle proxy settings in `android/gradle.properties`.

### Flutter build apk --release stuck at "Running Gradle task assembleRelease" — same fix?

Yes! The same solution applies to `assembleRelease`. The Gradle clean + build steps work for both debug and release builds. Run:

```bash
cd android
./gradlew clean
flutter build apk --release
```

### "flutter run stuck at running gradle task assembleDebug" — how to stop it?

Press `Ctrl+C` (or `Cmd+C` on Mac) in the terminal to kill the stuck process. Then follow the fix steps above before running `flutter run` again. You can also try running with verbose mode to see where it's actually stuck:

```bash
flutter run --verbose
```

### What does `flutter doctor -v` show about Gradle?

Run `flutter doctor -v` to get a detailed report of your Flutter environment. It will show:

- **Flutter version** and which channel you're on
- **Android SDK** path and installed components
- **Android NDK** location (if needed)
- **Java version** (must be JDK 17+ for recent Flutter versions)
- Any issues with your setup that might cause Gradle to fail

Fix every item marked with a red `[!]` before trying to build again.

### Flutter assembleDebug taking too long every time (not just first build)?

If every build is slow (not just the first one), try these:

1. **Clear the Gradle cache**: `rm -rf ~/.gradle/caches/` (Mac/Linux) or delete `%USERPROFILE%\.gradle\caches` (Windows)
2. **Increase Gradle memory**: Add `org.gradle.jvmargs=-Xmx4096m` to `android/gradle.properties`
3. **Enable parallel builds**: Add `org.gradle.parallel=true` to `android/gradle.properties`
4. **Use `--no-daemon` mode** to troubleshoot: `flutter run -- --no-daemon`

### Is "Running Gradle task assembleDebug" stuck or just slow?

If the terminal shows the message and the cursor is blinking, it's likely still working (downloading dependencies). If you see no network activity in your task manager or the process is using 0% CPU, it's probably stuck. Run `flutter run --verbose` to see real-time logs and pinpoint where it's hanging.

---

# NVIDIA's CES 2025 Showcase: Innovations in AI and Gaming

- **URL**: https://www.rafay99.com/blog/nvidia-ces-2025-announcements-rtx-50-project-digits/
- **Published**: 2025-01-08
- **Author**: Abdul Rafay
- **Tags**: AI, CES-2025, ThoughtsProcess
- **Description**: Cools thing that where annocumented in CES 2025

It's amazing what NVIDIA has done, and what they have announced is incredible. How far this company has come is truly mind-blowing. I always knew NVIDIA was good, but I didn’t understand just how wrong I was. I am really impressed with all the changes they announced—I am truly in shock. But I’m not a fan of everything. Still, some announcements definitely piqued my curiosity.

Here are some of the things that I’m interested in from what they announced:

## New 50 Series GPU

NVIDIA just dropped the curtain on the GeForce RTX 50 Series, and wow, it’s all about that new Blackwell AI chip. The lineup brings us the RTX 5070, RTX 5080, and the beast itself, the RTX 5090.

Starting with the RTX 5070, it’s coming in hot at $549 and somehow packs the punch of last gen’s RTX 4090—thanks to some crazy AI-driven rendering tech. On the other end of the spectrum, the RTX 5090 is the ultimate flex, priced at $1,999 and promising gaming performance that’s pretty much untouchable right now.

## Project DIGITS

NVIDIA just leveled up the AI game with **Project DIGITS**, a $3,000 desktop AI supercomputer that’s here to change how we think about local AI power. Whether you’re a developer, researcher, or just someone who loves diving deep into AI, this thing is designed to give you insane computational muscle—right on your desk. No need for cloud-based solutions anymore.

### What Makes Project DIGITS So Cool?

- **Powerhouse GB10 Grace Blackwell Superchip**\
  At its core, this machine runs on the GB10 Superchip, a collaboration between NVIDIA and MediaTek. It combines a Blackwell GPU (with CUDA and fifth-gen Tensor Cores) and a 20-core Grace CPU built on Arm architecture. Translation? Speed, efficiency, and seamless data transfer packed into a single chip.
- **Massive Memory and Storage**\
  With 128GB of unified LPDDR5X memory, this system can handle even the largest datasets like a pro. Add up to 4TB of NVMe storage, and you’ve got room for all your projects, applications, and more.
- **Unreal Performance**\
  Project DIGITS delivers up to 1 petaflop of AI power (at FP4 precision). That means you can run massive language models with up to 200 billion parameters—perfect for natural language processing, computer vision, or whatever AI magic you’re working on.
- **Built to Scale**\
  Need even more firepower? You can link two DIGITS machines with NVIDIA’s ConnectX networking and crank things up to handle models with up to 405 billion parameters. Yeah, it’s that flexible.
- **Energy Efficient**\
  Don’t worry about special power setups. Despite all that raw power, this beast runs on a standard wall outlet. Just plug it in and go.

### Why It’s a Game-Changer

Project DIGITS comes preloaded with NVIDIA’s full AI software stack, so you can jump right into prototyping, fine-tuning, and deploying your models. Plus, the compact design makes it a perfect fit for your workspace—no data center required.

For $3,000, NVIDIA is putting supercomputer-level AI power in the hands of developers and enthusiasts. Whether you’re chasing breakthroughs or just want to see how far you can push AI, Project DIGITS has you covered.

To be honest, these two things that NVIDIA announced made me lose my head. I’m a developer, and with these changes, the world of tech and AI will change so much.

### Final Thoughts

NVIDIA’s announcements are a clear reminder of how fast technology evolves. The new 50 Series GPUs are going to redefine gaming, and Project DIGITS feels like a glimpse into the future of AI development. If this is where we are now, I can’t even imagine what’s next. One thing’s for sure—NVIDIA isn’t just keeping up with the times; they’re setting the pace.

### References

1.  [NVIDIA's Official Announcement on GeForce RTX 50 Series](https://nvidianews.nvidia.com/news/nvidia-blackwell-geforce-rtx-50-series-opens-new-world-of-ai-computer-graphics?utm_source=chatgpt.com)
2.  [TechRepublic's Coverage of NVIDIA's CES 2025 Keynote](https://www.techrepublic.com/article/nvidia-keynote-ces-2025/?utm_source=chatgpt.com)
3.  [Yahoo Finance Video on Project DIGITS](https://finance.yahoo.com/video/ces-2025-huang-unveils-nvidia-020000890.html?utm_source=chatgpt.com)
4.  [Tom's Hardware Report on NVIDIA's RTX 50 Series](https://www.tomshardware.com/pc-components/gpus/nvidia-announces-rtx-50-series-at-up-to-usd1-999?utm_source=chatgpt.com)
5.  [NVIDIA Blog Post on CES 2025 Announcements](https://blogs.nvidia.com/blog/ces-2025-jensen-huang/?utm_source=chatgpt.com)
6.  [Biggest Nvidia takeaways from Jensen Huang's CES 2025 keynote](https://apnews.com/article/fadab7fc10c1a3e306c0a16448559ad8?utm_source=chatgpt.com)
7.  [The Essential CPU and GPU Field Guide for 2025](https://www.wired.com/story/intel-amd-qualcomm-nvidia-new-cpus-and-gpus-ces-2025?utm_source=chatgpt.com)
8.  [Nvidia shares slump as investors underwhelmed after CEO Jensen Huang unveils new chips in Las Vegas](https://nypost.com/2025/01/07/business/nvidia-shares-jump-after-ceo-jensen-huang-unveils-new-chips/?utm_source=chatgpt.com)

### Video Announcement

---

# The Rapidly Changing World of Tech

- **URL**: https://www.rafay99.com/blog/from-silicon-to-software-tech-trends/
- **Published**: 2024-12-09
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess
- **Description**: Tech innovations are evolving rapidly, but bundling smaller updates into impactful major releases makes them more exciting and meaningful for users.

In the world of tech, everything is changing rapidly. Every single day, a new technology is developed or introduced. No matter what you do, you're always trying to keep up.

We’re constantly trying new things, exploring, and finding use cases for the latest tech. Sometimes, we even contribute to the technologies we love.

For instance, if you’re a web developer, you might be working with JavaScript and contributing to its community. Or, if you’re an Android developer, you could be having fun with Flutter, Dart, or even Kotlin.

It’s all good! The tools you use daily are the ones you give back to, whether by contributing to their development or supporting them through sponsorships. And that’s great—it’s entirely up to you.

## The Innovation Gap

However, in recent years, I’ve noticed something: an **innovation gap**.

What is this innovation gap? It’s a question that needs answering. Here’s how I see it: the innovation gap occurs when there isn’t enough substantial content or features to justify every single release.

In other words, the frequency of releases creates an illusion of constant innovation, but the changes themselves may not be groundbreaking.

## The Past vs. Now

Think about the past. Each new release of a technology was massive—new features, fresh ideas, improved UI—something that made users excited to upgrade. Every release felt significant and worth learning.

This applied to everything, from mobile device technology to software tools. For example:

- **Visual Studio Code**: When it was introduced, it changed how we viewed code editors.
- **Neovim’s Lua Support**: A massive improvement that reshaped how developers interacted with Neovim.

Now, let’s talk about **Machine Learning**.

If you’ve been following the news, OpenAI has released several models alongside new tiers and services. But the newer releases don’t feel as groundbreaking as earlier ones.

For example:

- The leap from GPT-2 to GPT-3 (and GPT-3.5) was massive. These models transformed how we interacted with AI, answered questions, generated code, and more.
- On the other hand, GPT-4 and GPT-4-turbo are good, but they don’t feel like they’ve made a similarly huge leap forward.

It feels like smaller changes are being packaged as something big, which makes switching to the newer versions less exciting.

## React’s Evolution: A Case Study

Take React as another example. React revolutionized how we build UIs and pushed JavaScript to the server. With each update, React made things better and better.

However, its approach to innovation has shifted. Smaller releases accumulate over time and eventually combine into a big release.

For instance:

- The move from class components to functional components with hooks was a significant paradigm shift.
- React 19 introduces a new compiler, breaking many older features, which feels massive only because it bundles several smaller changes together.

## A Better Approach: Svelte and Next.js

Now, look at how frameworks like **Svelte** and **Next.js** handle releases.

- **Svelte 5** was released with huge changes, making it exciting for users.
- Similarly, **Next.js 15** introduced a bundle of improvements, which felt like a fresh start.

I’ve never used Next.js before, but the changes in version 15 pushed me to try it. The features in both the new and old versions complement each other, making the framework fun and exciting to use.

## Final Thoughts

Are you seeing the pattern here? Smaller releases accumulate into one big release, but the hype around each small announcement feels unnecessary.

In my opinion, tech companies should avoid releasing minor updates frequently. Instead, focus on bundling them into one major release. If you're making core structural changes, then small updates are fine. But if it’s just adding features, wait until there’s enough content to justify a big update.

This approach keeps releases exciting and users engaged. That’s why I appreciate how Svelte and Next.js handle their versioning. It makes tech more fun to explore and use.

Until then, keep coding, nerds! ❤️

---

# Private Search Engine

- **URL**: https://www.rafay99.com/blog/private-search-engine/
- **Published**: 2024-11-25
- **Author**: Abdul Rafay 
- **Tags**: DevelopmentTools, DevOps
- **Description**: Ditching Google Search, Making something better

In today's world, privacy feels like a joke. No matter how hard you try, if you're tech-savvy but don’t fully understand what you’re doing, you’re pretty much doomed. Companies like Meta, Google, Microsoft, and others are constantly building profiles on your data to serve you ads. And that’s just the tip of the iceberg. With this sheer amount of data, they can manipulate your mood, your personality, and even your decisions.

That’s terrifying, isn’t it? Someone out there, tweaking how you think and feel? That’s not okay. So, where do we even begin to fight back? For me, it starts with search. I’ve always dreamed of building my own search engine. As a software engineer who loves tinkering with tech and software, it doesn’t feel like an impossible task. I mean, how hard could it really be, right?

But, hold on. I’ve never actually done this before. Building your own search engine sounds cool, but it has to be practical too. I don’t want to dive into a project that just eats up my time and energy without any real payoff. So, before I jump in, here are some burning questions I need to answer:

- What’s the cost of running a search engine? I’m not exactly rolling in cash, so even a few extra dollars can feel like a burden.
- Is it really private, or is that just a scam?
- How easy is it to set up and maintain? Could anyone do this on their own machine, or is it a tech nightmare?
- Can it stay up-to-date automatically? Or will I need to manually update it with the latest web pages and news (because, let’s be honest, that sounds exhausting)?

These are the questions that need answering before I start. If you’re curious too, stick around—we’re going to figure this out together.

### How Are We Going to Deploy This Private Search Engine?

To deploy our private search engine, we’re going to use an open-source project called [SearXNG](https://github.com/searxng/searxng). Funny thing is, I didn’t even know about this project at first. After some searching on YouTube, Reddit, and Google, I stumbled across it, and let me tell you—people are raving about it. There’s even a fantastic video by NetworkChuck. If you haven’t seen it yet, do yourself a favor and check it out. It’s a great introduction, and I absolutely loved what he did in that video.

Here’s the kicker about SearXNG: it works best on Linux or Mac. That’s right—most search engines rely on Linux as the base OS, and there’s no way around it. But if you’re on Windows like me, don’t worry! You can use WSL 2 (Windows Subsystem for Linux) or Docker to get things running. That’s exactly what I’ll be doing on my system because, honestly, I’m too lazy to reboot into Linux and disrupt my entire workflow. So, Docker + WSL 2 it is. Wish me luck!

If you haven’t installed Docker or WSL on your machine yet, no problem. Check out the official guides here:

- [Docker Installation Guide](https://docs.docker.com/get-docker/)
- [WSL Installation Guide](https://learn.microsoft.com/en-us/windows/wsl/install)

Here's a polished version of your text while keeping the casual tone intact:

---

Once you’ve installed WSL, head over to the Microsoft Store and install **Ubuntu**. If this is your first time setting up WSL, Ubuntu will automatically be installed on your system. Next, we’ll install Docker inside Ubuntu. Yes, I know—it’s a bit of a pain, but trust me, it’s worth it.

To install Docker on Ubuntu, just follow these steps:

### Enable Docker in Ubuntu

Run the following commands one by one:

```shell
# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
```

### Install Docker

Once the above steps are done, install Docker using this command:

```shell
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker-compose
```

Now that Docker is installed, we’re almost there!

### Setting Up SearXNG

1. Switch to the root user with the following command:

```shell
sudo su
```

Enter your password when prompted.

1. Navigate to the `/usr/local` directory:

```shell
cd /usr/local
```

1. Clone the **SearXNG Docker** project:

```shell
git clone https://github.com/searxng/searxng-docker.git
```

1. Enter the cloned project directory:

```shell
cd searxng-docker
```

1. If you plan to host this search engine on the internet, you’ll need to edit the `.env` file. This file is where you specify the domain you’ll be using and the email address for SSL encryption (via Let’s Encrypt). However, since I’ll be running this on my local machine, I’m skipping this step.

### Running the Docker Container

Finally, let’s get this search engine up and running! The Docker container will handle cloning, installing dependencies, and running the project in the background. To start it, run the following command:

```shell
sudo docker-compose up -d
```

Make sure you’re in the directory where the `docker-compose.yml` file is located; otherwise, this command won’t work.

To bring down the Docker container, simply run this command in the same folder:

```shell
sudo docker-compose down
```

This command will stop your Docker container.

And that’s it! Your private search engine should now be up and running. If everything worked as expected, you’re one step closer to reclaiming control over your digital privacy.

### Access the Search Engine

To access your search engine locally, just open your browser and type `localhost` into the address bar. Your search engine should be live and working like a champ, with no issues at all regarding its privacy features.

However, here’s the thing: when I was using WSL with Ubuntu, the Docker container ran fine, but I couldn’t access `localhost`. I searched and searched but couldn’t find a solution. Windows sucks. I followed the same process on my Linux machine, and guess what? It worked perfectly.

### Customization

Not a fan of the default look or feel? No problem! Customizing SearXNG is straightforward. Inside the `searxng` folder, there’s a file called `settings.yml`. This is where all the magic happens. Be careful not to touch the other files unless you know what you’re doing.

For a full list of customization options, check out the official [SearXNG documentation](https://docs.searxng.org/admin/settings/index.html). There are so many options that even I can’t explain them all here. Dive into the docs, and you’ll be good to go.

### Final Thoughts

After spending an hour or two setting this up, I’ve finally got my answers:

- **Is it private?** Yes, it’s the real deal. When I read about how this search engine works, I was blown away by the level of detail and care the developers put into it.
- **Does it cost money?** Nope! For me, it didn’t cost a dime, but it will use some of your PC’s performance. If you’ve got an extra machine, even better—zero cost and zero interruptions.
- **Does it update automatically?** Yes, it does. It handles indexing and keeps everything up-to-date with minimal effort on your part.
- **Can the average person set this up?** Honestly, with this blog post and NetworkChuck’s video as a guide, yes. It might take you a day to get it running, but it’s absolutely worth it in the end.

I’ll be running this on my Linux machine moving forward because, let’s face it, Windows just doesn’t cut it for projects like this. If you’re serious about privacy, switching to Linux will make your life so much easier.

Until next time—keep coding, nerds! ❤️

---

# There's ANOTHER new AI fork of VS Code??!

- **URL**: https://www.rafay99.com/blog/there-another-new-ai-fork-of-vs-code/
- **Published**: 2024-11-16
- **Author**: Abdul Rafay 
- **Tags**: DevelopmentTools
- **Description**: Windsurf: New AI code Editor

While, while, what do we have here? There’s a new AI code editor in town called [Windsurf](https://codeium.com/windsurf), brought to you by a company called Codeium. To be honest, I’ve been using Codeium AI as a VS Code extension, and with their stunning website, I was hopping off my chair and installed Windsurf the moment I learned about this new code editor on my machine.

But why do we need a new editor? Oh wait, it’s because Cursor already has 40,000 developers using their product, and that’s exactly why we need more competition, right?

So what are you waiting for? Go install it, and I’ll tell you everything about this editor. Because, for the sake of science and development, I’ve tried it, and I’m here to share everything with you all!

Before we dive deep into this new editor, let’s split this review into two parts:

1. The Good
2. The Bad

And believe me, the bad parts are way more fun, so let’s get started!

### The Good

Let’s kick things off with the good stuff and the features this AI code editor promises. According to the website, this editor aims to work alongside developers, creating a seamless flow between AI and human inputs. They call this collaboration _Flows_. I’m not making this up—that’s the wording straight from their site, which you can check out by [clicking here](https://codeium.com/windsurf).

They claim that the editor will index your codebase, and in the Composer, you simply enter the task. The AI then goes through the codebase and makes changes step by step. Pretty cool, right?

Another key feature is called _Cascade_. This one provides full context awareness, suggesting and running commands for developers. It also includes a "pick up where you left off" capability and handles multiple files seamlessly.

In other words, it’s like a smart text box that manages multiple files and performs operations across them. Sounds impressive!

### The Bad

Now, these features are cool and all, but here’s where things get a bit messy...

For this review, I cloned my Astro project from GitHub to see how it works in this new AI code editor. I opened the codebase in Windsurf and decided to test out the Cascade feature by asking it to guide me on how to run the project. You can check out the video below to see how it all played out:

In the above video, you can see me prompting Cascade to tell me how to run the
project. It started off by suggesting `npm`. Now here’s the thing: I use **nvm
(Node Version Manager)** for my Node setup, which is a shell-based install, not
a system-wide one. On the other hand, **Bun** is installed system-wide.

The AI first tried to use the system's Node.js, and unsurprisingly, it failed. There were a ton of warnings, and in the end, it just didn’t work. Next, it attempted to use Bun. It did work, but here’s the problem: it was **so slow**. It took more than 10 minutes to get this going.

And this is where I see a big issue. The AI can do some cool stuff, but it relies heavily on having the right environment set up on your system. Plus, the speed is a major letdown. Please, Codeium, I love your products—can you make it faster? Please!

When I tried running this project using `bun run dev`, it didn’t work. So, I had to reinstall all the dependencies with `bun install`. That part went fine, but it was a bit of a hassle.

### Final Thoughts

Look, I’m really trying hard to like this product, but I’ve got to be honest: the promises are great, but they’re just not fully delivered yet.

This is just the tip of the iceberg. I came across [Theo’s video](https://www.youtube.com/watch?v=FqbMXtxDZYc) on the same tool, and his experience wasn’t great either. He did even more testing than I did, and let’s just say he wasn’t impressed.

Now, there’s one thing I do like: the **workflow**. The concept is solid. The idea of a natural flow, making things smoother, and having a unified experience is fantastic. But it needs **a lot** of work.

As for me, I’ve installed this editor on my machine, and whether I use it or not will depend on my mood and the task at hand.

Because it took so long to get things working, I couldn’t complete other tests in time, like adding new features. But check out [Theo’s video](https://www.youtube.com/watch?v=FqbMXtxDZYc) for a deeper dive—he’s done way more testing and gives a true experience of using this tool.

If things improve, I’ll write another blog post and update this review accordingly.

Until then, peace out, nerds. 👓

---

# Why Should I Embrace AI Tools for Coding? Will They Help or Reduce My Efficiency?

- **URL**: https://www.rafay99.com/blog/embrace_ai_tools/
- **Published**: 2024-11-08
- **Author**: Abdul Rafay 
- **Tags**: AI, DevelopmentTools
- **Description**: Should you embrace these AI tools??

Not too long ago, as I was working on an Android application, I was scrolling through YouTube, looking for something interesting to watch. Then, YouTube recommended a video to me: _[Embrace GitHub Copilot, Cursor AI & ChatGPT as a Developer!](https://www.youtube.com/watch?v=3xu_QrZRYRw&t=174s)_. As a curious developer, I watched the entire video. It raised a question that I’ve been thinking about a lot: should I rely on AI tools to build applications, and if so, how much should I use them? What are the potential side effects?

I've already discussed similar questions in a previous blog post, _[My Love and Hate Relationship with GitHub Copilot](https://www.rafay99.com/blog/mylovehaterelationshipwithcopilot)_, where I concluded that it’s best to set boundaries on how much we rely on these tools. But this video only highlighted the benefits of using AI for development. For instance, it pointed out how these tools can generate boilerplate code effortlessly. Generating boilerplate code for a Flutter widget or an HTML page can be tedious, but with AI, you just need to provide a prompt like "create this widget with this title and metadata," and it gets done in seconds.

This feature can make life so much easier, especially for tasks that feel more like obstacles than creative work. I want to focus on creating meaningful UI and logic for my app to function, rather than dealing with repetitive code. Another key benefit mentioned in the video was how AI can help refactor code, making it easier to break down components into reusable pieces. This reusability improves maintainability, eases debugging, and facilitates adding new features.

These are all solid points from the video, but here’s my personal take on using AI tools in development.

## My Usage

Honestly, as a developer, I use these AI tools mainly for learning new technologies and improving UI design. I’m not a front-end developer, but I usually have a vision for what I want to build. I code it, but I know it’s not perfect. That’s when I turn to AI. Here’s an example of a prompt I often use:

> Imagine you are a designer and developer with five years of experience. With this expertise, you are tasked with improving a UI. Here is the code. Now, modify this UI to make it better.

**For Example**
I was working on the Tools section on my own website using Astro, React, and Framer Motion. This was the original code:

```typescript
import "devicon/devicon.min.css";
const techStack = authorConfig.techStack;

const SkillsShowcase: React.FC = () => {
  // Set initial tab as the first category in the tech stack
  const [activeTab, setActiveTab] = useState(Object.keys(techStack)[0]);

  return (
    <div
      style={{
        boxShadow:
          "0 2px 6px rgba(76, 80, 106, 0.25), 0 8px 24px rgba(76, 80, 106, 0.33), 0 16px 32px rgba(76, 80, 106, 0.33)",
      }}
      className="py-12 px-6 md:px-12 bg-[var(--accent-dark)] rounded-lg"
    >
      {/* Tab Navigation for Tech Stack Categories */}
      <div className="flex flex-wrap justify-center space-x-2 mb-8">
        {Object.keys(techStack).map((category) => (
          <button
            key={category}
            className={`py-2 px-4 font-semibold rounded-lg ${
              activeTab === category
                ? "bg-[var(--accent)] text-white"
                : "bg-transparent text-[var(--text-light)]"
            } transition duration-300 whitespace-nowrap`}
            onClick={() => setActiveTab(category)}
          >
            {category}
          </button>
        ))}
      </div>

      {/* Skills Table */}
      <div className="flex overflow-x-auto">
        {Object.entries(techStack).map(([category, skills]) =>
          activeTab === category ? (
            <motion.div
              key={category}
              initial={{ opacity: 0, y: 20 }}
              animate={{ opacity: 1, y: 0 }}
              exit={{ opacity: 0, y: 20 }}
              transition={{ duration: 0.3 }}
              className="flex items-center justify-start"
              style={{ whiteSpace: "nowrap" }}
            >
              {skills.map((skill) => (
                <i
                  key={skill}
                  className={`devicon-${skill}-plain colored text-6xl mx-2`}
                ></i>
              ))}
            </motion.div>
          ) : null
        )}
      </div>
    </div>
  );
};

```

And this is the modified code

```typescript
import "devicon/devicon.min.css";
const techStack = authorConfig.techStack;

const SkillsShowcase: React.FC = () => {
  const [activeTab, setActiveTab] = useState(Object.keys(techStack)[0]);

  return (
    <div
      className="py-12 px-6 md:px-12 bg-[var(--accent-dark)] rounded-lg shadow-lg"
      style={{
        boxShadow:
          "0 2px 6px rgba(76, 80, 106, 0.25), 0 8px 24px rgba(76, 80, 106, 0.33), 0 16px 32px rgba(76, 80, 106, 0.33)",
      }}
    >
      {/* Tab Navigation */}
      <div className="flex flex-wrap justify-center gap-4 mb-8">
        {Object.keys(techStack).map((category) => (
          <button
            key={category}
            onClick={() => setActiveTab(category)}
            className={`py-2 px-6 font-semibold rounded-full transition duration-300 text-sm md:text-base ${
              activeTab === category
                ? "bg-[var(--accent)] text-white shadow-md"
                : "bg-transparent text-[var(--text-light)] hover:bg-gray-700 hover:text-[var(--accent)]"
            }`}
          >
            {category}
          </button>
        ))}
      </div>

      {/* Skills Grid */}
      <motion.div
        initial={{ opacity: 0, y: 10 }}
        animate={{ opacity: 1, y: 0 }}
        exit={{ opacity: 0, y: 10 }}
        transition={{ duration: 0.3 }}
      >
        <div className="grid grid-cols-3 sm:grid-cols-4 md:grid-cols-5 lg:grid-cols-6 gap-6">
          {techStack[activeTab].map((skill) => (
            <motion.div
              key={skill}
              whileHover={{ scale: 1.1 }}
              className="flex flex-col items-center text-center"
            >
              <i className={`devicon-${skill}-plain colored text-5xl`}></i>
              <p className="mt-2 text-sm text-[var(--text-light)]">
                {skill.charAt(0).toUpperCase() + skill.slice(1)}
              </p>
            </motion.div>
          ))}
        </div>
      </motion.div>
    </div>
  );
};

```

Using this prompt, the AI suggests enhancements that usually address the issues in my design. However, I still tweak things afterward to better fit my vision—whether it’s changing fonts, icons, or colors to align with the overall style of the application.

## Hot Take

Here’s my perspective on AI usage after watching the video and reflecting on my own experiences: AI tools are valuable for learning, refactoring, and improving code structure, but they shouldn’t be overused for generating large chunks of code. Code generated by AI often lacks high quality, security, and precision. And if you’re a new developer without a solid foundation, relying heavily on AI can be harmful. It might weaken your ability to read documentation and hinder your debugging skills.

## Conclusion

In the end, AI tools like GitHub Copilot, ChatGPT, and Cursor AI can be incredibly powerful aids for developers. They can save time on repetitive tasks, help refactor code, and offer learning opportunities, especially for areas outside our expertise. However, it’s essential to use them mindfully. Over-relying on AI for code generation can lead to lower quality, less secure code, and it may even hinder important skills like reading documentation and debugging.

My advice? Embrace these tools as companions for learning, refactoring, and enhancing your work, but maintain control over your code by focusing on quality and understanding what you're building. AI can be a valuable ally—just be sure it complements, rather than replaces, your own development skills.

For more of my thoughts, check out my other post, _[My Love & Hate Relationship with Copilot](https://www.rafay99.com/blog/mylovehaterelationshipwithcopilot)_.

Until next time, stay curious and keep building 👓.

---

# Flutter Forked: A Game-Changer Ahead

- **URL**: https://www.rafay99.com/blog/flutter_fork_flock/
- **Published**: 2024-11-01
- **Author**: Abdul Rafay 
- **Tags**: MobileDevelopment
- **Description**: Flutter Fork is here: Flock

_The Flutter Foundation just made waves with its announcement to fork Flutter, and as both a developer and blogger deeply invested in the framework, I wanted to dig into what this means for the community and for the future of cross-platform development._

Flutter, an open-source UI toolkit loved for its ability to create natively compiled applications from a single codebase, has been growing in popularity since its release by Google in 2018. It’s powered countless apps on Android, iOS, the web, and more, and has been embraced by companies big and small. But like any large open-source project, Flutter has experienced some growing pains. That’s where the Flutter Foundation’s recent announcement comes in, and here’s why I think it’s a move worth celebrating—and discussing.

### Breaking Down the Reasons for Forking Flutter

The decision to fork an open-source project isn’t made lightly. It often means there are significant concerns with the direction, governance, or responsiveness of the original project. According to the Foundation’s announcement, the main motivations for this fork center on three key areas: governance, community-driven development, and innovation. Here’s my take on each:

1. **Decision-Making and Governance**\
   In open-source projects, governance affects everything, from prioritizing bug fixes to setting long-term goals. The Flutter Foundation observed that Google’s centralized control over Flutter’s roadmap sometimes led to slower responses on issues and community feedback. They noted a growing discontent among developers who felt sidelined in decision-making, and that’s something I can resonate with as well.

   By forking Flutter, the Foundation is committing to a more transparent, community-focused governance model, where the voices of developers are taken seriously and have an impact on the project’s future direction. This should allow faster, more flexible decision-making and prevent some of the bottlenecks we’ve seen with Flutter’s mainline updates.

2. **Community-Driven Development**\
   The heart of this fork is to create a development model that directly addresses the community’s needs. With the Foundation’s fork, developers should see improvements driven by real-world feedback. They’re emphasizing a more direct feedback loop, where community input will shape everything from feature prioritization to bug fixing.

   For developers like me, this could be a major boost. Community-driven development has the potential to make Flutter more practical and responsive for day-to-day use, leading to features that address real pain points and improve the developer experience significantly.

3. **Innovation and Flexibility in Cross-Platform UI**\
   Finally, this fork aims to accelerate innovation. Flutter’s biggest appeal is its versatility in building cross-platform applications, but as the Flutter Foundation pointed out, there’s been a lag in addressing feature requests and improving platform integrations. They aim to experiment with new features and enhancements that may have been stalled in Flutter’s main branch.

   This is an exciting prospect because the Foundation is talking about releasing more experimental features and quicker updates. They seem ready to take risks that may lead to a more dynamic toolkit, and this could mean Flutter will gain capabilities to support more advanced use cases, optimize performance, and improve platform integrations that are lagging.

### What to Expect from the New Flutter Fork

So, what’s in store? Here are some changes the Foundation has outlined, and what I think about them:

- **Faster Releases and Bug Fixes**\
  One of the biggest promises here is a faster release cadence. With community-driven development at its core, this fork should give us faster updates and more consistent bug fixes. While Google has a long release cycle, this fork aims to be agile, which could mean that common developer complaints and usability issues get resolved sooner rather than later. That’s a big win.
- **Better Documentation and Onboarding**\
  One criticism that comes up often with Flutter is its documentation, particularly for more complex topics. The Flutter Foundation seems to understand this, and they’re promising a streamlined setup process along with enhanced documentation. This should make the learning curve easier, especially for newcomers, and I’m hopeful that this focus on documentation will help developers at all levels become productive faster.
- **Open Governance and Community Insight**\
  The new governance model is a game changer. I’m particularly excited about this aspect because it’s an opportunity for the developer community to have a real voice. Transparency in decision-making, with input from the community, could help Flutter evolve in a way that aligns more closely with developer needs.

### What Does This Mean for the Flutter Community?

The potential benefits are clear, but there are a few risks. Forks can sometimes lead to fragmentation within a community. If developers are divided between the original Flutter and the new fork, it could result in duplicated efforts or compatibility issues. However, the Flutter Foundation has assured that compatibility with Google’s Flutter remains a priority, so existing projects shouldn’t face disruptions.

In fact, if they manage to retain compatibility, this fork could act as a more agile “testing ground” for new features. Developers could experiment with the fork and, if the features are successful, those could later be brought into Flutter’s mainline branch. This approach could lead to the best of both worlds: innovation in the fork with stability in the original Flutter.

### My Hot Take: Why I’m Excited About This Fork

Overall, I’m optimistic about the Flutter Foundation’s fork. As a developer, there’s nothing more frustrating than waiting for feature requests to be addressed or bugs to be fixed while seeing little response from the core team. This fork has the potential to make Flutter’s development process faster and more developer-centered, and that’s incredibly promising.

If the Flutter Foundation pulls this off, we might be looking at a Flutter ecosystem where developers have greater control over the toolkit they rely on. It’s a refreshing vision for what open-source projects can be: driven by community input, transparent, and responsive to real-world use cases.

In a sense, this fork might just be what Flutter needs to reach its full potential. By accelerating innovation and focusing on the developer experience, the Flutter Foundation is setting a precedent for how large open-source projects can be managed in a way that puts the community first.

### Final Thoughts

The Flutter Foundation’s fork is a significant event for the open-source UI community. It’s a chance for developers to be part of a more responsive, innovative environment and could mean a better, faster Flutter for everyone. I’ll be watching this development closely and am eager to see the community’s response. For now, I’m excited about the possibilities and hopeful that this move will bring about the enhancements we’ve been waiting for.

As a developer and Flutter enthusiast, I can’t wait to dive into this new version and see where it takes us!

Until then, peace out, nerds. 👓

You can checkout the original Blog Post By [Flock](https://flutterfoundation.dev/blog/posts/we-are-forking-flutter-this-is-why/)

---

# AI-Powered Coding: Can Machine Learning Write Better Code than Humans?

- **URL**: https://www.rafay99.com/blog/ai-coding-machine-learning/
- **Published**: 2024-10-28
- **Author**: Abdul Rafay 
- **Tags**: AI
- **Description**: The question is can AI code better then Human, that is the question that I'll be answering

I'm a developer, and with all this AI talk, I started to wonder: Can AI write better code than an experienced programmer? Sales terms and benchmarks show that AI can solve existing problems, but can it truly predict and solve real-life challenges?

The release of AI chatbots that can generate code is exciting. With millions of users worldwide, it’s amazing to see how quickly the world is changing through this technology. But it raises another question: Can AI write quality, secure code?

Writing code is one thing; writing code that meets standards and is secure is another. Achieving both in a codebase can be tough.

_Can AI really write better code than humans? Moreover, will it replace software engineers?_

The short answer, for those reading this blog, is _NO_. AI will not write clean, secure code. If you're interested, stay with me as we break down why AI isn’t producing good, clean code.

# Struggles of AI

Ai Struggles to write clean amd secure code due to multiple reasons and factors, The complexity of writing cleaning code.

## Contextual Understanding:

The reality of AI is that AI does not have deep Understanding of contenctual insight that human have, which means they may miss the nuances needed for high-quality, clean and secure code.

## Code Quality & Standaerds

Clean code involves readability, simplicity, and modularity, all of which are influenced by coding practices, style guides, and conventions specific to different languages or projects. While AI can mimic style patterns seen in its training data, it lacks the ability to consistently apply these standards creatively or adaptively, especially in complex, real-world applications.

## Security Challenges:

Writing secure code requires awareness of potential vulnerabilities (like SQL injection, cross-site scripting, etc.) and implementing secure design patterns. AI can learn some secure coding practices from its training data, but it may overlook less common vulnerabilities or fail to adapt to new security threats without retraining.

## Training Data Limitations:

AI models like large language models are trained on vast amounts of code, but this data includes both good and bad examples, so AI can inadvertently generate code with vulnerabilities or poor practices. The AI's "understanding" of code quality is only as good as the examples it has seen.

## Dynamic Requirements:

Real-world coding often involves changing requirements and a collaborative review process, both of which are critical for ensuring clean, secure code. AI lacks the ability to engage in this iterative, human-centric review process, which helps catch errors, optimize, and secure code.

# Will AI Replace Programmers?

AI won’t replace programmers. But AI is already helping developers to write code. AI-powered coding assistants like ChatGPT, Github, CoPilot, and OpenAI Codex are accessible tools that help embedded developers write better code faster. AI code generators can now quickly generate high-quality code snippets, identify issues and defects, and suggest improvements to code snippets.
Of course, it will take time before AI will be able to create actual, production-worthy code that spans more than a few lines.

Here’s how AI will impact software development in the near future.

## Generative AI Will Improve

It will become effective at automating tasks and helping developers understand their options. And it will then let the human decide how to optimize for circumstances beyond AI’s understanding.

## AI Will Become a Coding Partner

Software developers will use AI as a coding pair to write better software. This is already happening today and will continue to rise in popularity as AI learns to write more than a few lines of code at a time. Developers will include AI pair programmer tools within their IDEs. Similar to human paired programming, the AI tool will perform coding tasks based on prompts, and then the developer will review the code. In the past, this process was more labor intensive, but AI tools can perform certain parts of their SDLC faster than a human developer, freeing the developer to focus on more complex tasks.

## But Programmers Will Remain Important

The true value of a programmer is not knowing how to build it. The value is in knowing what to build.

It will take even longer before AI learns how to interpret the business value of each feature and advise you what to develop first. There will always be a role for the human programmer.

# What If AI Writes Reliable Code?

That’s a big if. Most humans can’t write reliable code. And AI is just an application that analyzes vast amounts of human-written code. So, it’s unlikely that AI will write reliable code.

Most programmers agree. In a recent survey by [CodeSignal](https://codesignal.com/report-developers-and-ai-coding-assistant-trends/), 1,000 developers worldwide were asked about their use of AI coding assistant tools. While 81% of developers said that they use AI-powered coding assistants, 55% of software engineers surveyed said that they had concerns about the quality of the AI-generated code.

So, AI isn’t the answer to improving code quality.

# Role of Human Software Engineers in the Future

As the AI wave surges forward, you might wonder about the fate of human software engineers. Fear not, for the future is bright and brimming with possibilities! While ChatGPT is a coding whiz, it still bows to the prowess of human developers in certain domains. The significance of coding goes beyond mere syntax and algorithms; it’s about the art of transforming ideas into functional masterpieces.

In this tech-powered future, human software engineers will rise as architects of innovation, crafting solutions beyond the scope of AI. They’ll champion creativity, adaptability, and problem-solving, deftly navigating the ever-changing landscape of technology. So, fear not, developers of humankind, for your role in the AI era is secure and vital.

# Conclusion:

Here’s the answer you’ve been looking for: No, AI does not write clean and secure code. There are reasons for this, as explained above. However, AI is here to stay, and it’s best to embrace this future. Use AI tools to improve software quality, but don’t rely on them too heavily. Over-dependence on these tools can erode your skills before you realize it. To read more on this, check out my other blog post: [My Love & Hate Relationship with Copilot](https://www.rafay99.com/blog/mylovehaterelationshipwithcopilot/).

---

# The Nightmare Feature: Implementing Search

- **URL**: https://www.rafay99.com/blog/search-on-static-site/
- **Published**: 2024-10-20
- **Author**: Abdul Rafay
- **Tags**: WebDevelopment
- **Description**: Implementing Search in Web Projects

During my time as a developer, one feature consistently stands out as particularly challenging to set up: search. What makes search tricky is that it varies not only from project to project but even across static sites. Thankfully, modern web development uses frameworks that streamline full-stack application development, and many of these projects are based on React or React-based frameworks.

Search is a critical feature for any website. It ensures that users can find the content they’re looking for. If the search functionality is ineffective, it becomes useless. But how do you set up a search feature that works well? Let’s dive into it.

## What is React?

Before we delve into the search implementation, let’s first understand React and JavaScript, and how they can help us create a search feature on a site.

React is a JavaScript library developed by Meta (formerly Facebook). It’s a UI library that enables developers to build dynamic and interactive user interfaces using JavaScript and Node.js. React simplifies the process of creating visually appealing websites with reusable components.

## Getting Started

Now that we have a basic understanding of React, let’s go over how to create a search feature. First, you’ll need some content on your site. For this example, I’m using Astro—a modern static site generator optimized for content-driven sites. I have a lot of content written in Markdown, and I build my website using the Astro framework.

Astro is a JavaScript framework like React, but it’s specifically designed to make content-driven websites easier and faster to build.

### Creating an Astro Project

To create an Astro project, enter the following command:

```bash
npm create astro@latest
```

This command will guide you through some setup questions. Answer them, and you’ll have a working Astro project. I recommend starting with the Blog template, as it provides many pre-configured features that simplify your development process. For more information, check out Astro's official [documentation](https://docs.astro.build/en/tutorial/1-setup/2/).

### Enabling React

Once you have your Astro site set up, the next step is to enable React. The reason we’re using React is that it allows us to create clean and customizable UI components, and with the help of packages like Fuzzy, we can implement a powerful search feature.

To enable React in your Astro project, run the following command:

```bash
npx astro add react
```

This will automatically integrate React into your Astro site. If you prefer manual setup, you can refer to this [guide](https://docs.astro.build/en/guides/integrations-guide/react/).

### Creating Components

Now, it’s time to create components for both your Astro and React projects. The file structure for my project looks like this:

```
src
├── components
│   ├── BaseHead.astro
│   ├── Footer.astro
│   ├── FormattedDate.astro
│   ├── Header.astro
│   ├── HeaderLink.astro
│   └── react
│       ├── SearchComponent.tsx
│       └── SearchComponentLogic.tsx
└── content
    ├── config.ts
    └── blog
        ├── first-post.md
        ├── markdown-style-guide.md
        ├── second-post.md
        ├── third-post.md
        └── using-mdx.mdx
```

In the structure above, I created two files: `SearchComponent.tsx` for the UI and `SearchComponentLogic.tsx` for the logic. This approach separates the search functionality into the user interface (UI) and the underlying logic, making the code more organized.

### Fuzzy Search

To make the search functionality work, we’ll use a package called [Fuzzy](https://www.npmjs.com/package/fuzzy). Fuzzy search allows for flexible and tolerant search functionality by matching user input with relevant content, even if the match isn’t exact.

## Application Logic

The search logic is straightforward. Astro has a content layer, and we can pass data from this layer throughout the project. Using this capability, we can build a robust search feature.

All the blog data will be passed into the React component (`SearchData`), and Fuzzy will index this data. When the user enters a query, Fuzzy will search through the indexed data and return the results. The React component will then display the matching results in a user-friendly manner.

### Why React?

This approach is highly customizable and provides superior performance compared to JavaScript functions that crawl through the entire site. React allows us to build a better UI while keeping the search fast and efficient.

For example, on my site, the search feature looks through multiple fields—author names, blog post content, titles, and even publication dates. This makes it highly adaptable to different needs.

## Code Breakdown

Let’s walk through the code that powers this search feature.

### Search UI Component

#### **Imports**

- **React**: The core library for building UI components in JavaScript.
- **useSearchablePosts**: A custom hook (explained later) that manages search logic, including state for the query and filtered posts.

#### **Post Interface**

```typescript
interface Post {
  id: string;
  slug: string;
  body: string;
  collection: string;
  data: {
    title: string;
    description: string;
    pubDate: Date;
    updatedDate?: Date;
    heroImage?: string;
  };
}
```

This interface defines the structure of a blog post, including metadata such as the title, description, and publication date.

#### **SearchablePostsProps Interface**

```typescript
interface SearchablePostsProps {
  posts: Post[];
}
```

This interface describes the props passed to the `SearchablePosts` component, which expects an array of `Post` objects.

#### **SearchablePostsUI Component**

```typescript
const SearchablePostsUI: React.FC<{
  query: string;
  filteredPosts: Post[];
  handleSearch: (e: React.ChangeEvent) => void;
}> = ({ query, filteredPosts, handleSearch }) => {
  // UI rendering logic here...
};
```

This component handles the user interface for the search feature. It displays a search input field and a list of filtered posts based on the user's query.

### Search Logic Component

The logic behind the search functionality is handled by a custom hook called `useSearchablePosts`. Here’s a brief overview:

#### **State Management**

```typescript
const [query, setQuery] = useState<string>("");
const [filteredPosts, setFilteredPosts] = useState([]);
```

These states track the user’s query and the list of posts that match the search.

#### **Search Handler**

```typescript
const handleSearch = (e: ChangeEvent) => {
  const searchQuery = e.target.value;
  setQuery(searchQuery);
  // Fuzzy search logic here...
};
```

This function is triggered whenever the user types in the search box, updating the search query and filtering the posts using Fuzzy search.

#### **Search Logic**

```typescript
const results = fuzzy.filter(searchQuery, posts, {
  extract: (el: Post) => el.data.title,
});
const matches = results.map((result) => result.original);
setFilteredPosts(matches);
```

The Fuzzy search library is used to match the user’s input with the post titles and return the relevant results.

### Custom Hook Return

```typescript
return { query, filteredPosts, handleSearch };
```

The hook returns the current query, filtered posts, and the search handler, which are used in the UI component.

Since you are using MDX, we can make your blog post more interactive by embedding code snippets and creating collapsible sections or even interactive components. Here's an idea of how you can make your GitHub project section more engaging and interactive:

## Search Feature Code

I've implemented the search functionality in an Astro project, and you can explore the full code on GitHub. Below is an interactive code snippet for the setup. You can collapse sections to focus on specific areas or expand them to dive deeper into the code logic.

## GitHub Project:

**[Check out the full project on GitHub](https://github.com/FutureInsightTech/SearchAstro)**

# Conclusion

By combining Astro and React, we’ve built a customizable, efficient, and scalable search feature that adapts to various needs. This approach leverages React’s component-based architecture and Fuzzy’s flexible search capabilities to deliver a fast and user-friendly experience.

---

# Is AI Just Hype or Something More?

- **URL**: https://www.rafay99.com/blog/ai-hype-or-scam/
- **Published**: 2024-09-30
- **Author**: Abdul Rafay
- **Tags**: AI
- **Description**: Unveiling the truth behind AI: is it a revolutionary force or just a glorified autocomplete?

We’ve all heard the buzz—AI is here, and it’s everywhere. With headlines dominated by AI developments and the endless hype, it’s hard not to wonder: is AI just another overhyped trend like crypto, or is there something more substantial behind it? In this blog, I’ll break down how the term "AI" is often overused, explore what it really means, and provide a clearer picture of where we actually stand with current AI technology.

this is another test for the conflict
Now I am checking from the laptop and let's see what is happening 

## What is AI?

In case you’re new to the conversation, let’s start with the basics. According to Google, AI is _"the simulation of human intelligence processes by machines, especially computer systems."_

But what does that actually mean? To put it simply, AI stands for Artificial Intelligence, which refers to making machines think and perform tasks in a way that resembles human behavior. Humans experience emotions, make decisions, and process complex thoughts. AI, in theory, is about giving machines the ability to replicate these processes. But is that what we really have today?

You might ask: if that’s AI, then what about ChatGPT and other AI bots? Are they not AI? Well, the answer is more complicated than it appears.

To really understand what’s happening, we need to break down some important terms:

1. Machine Learning
2. LLM (Large Language Model)
3. Autocomplete

Let’s dive into each of these to uncover the truth about AI today and whether it’s really a scam.

## What is Machine Learning?

Simply put, **Machine Learning (ML)** is the process of teaching a machine to understand content without explicit instructions. Based on the data it’s trained on, the machine performs tasks related to that information. However, anything beyond the scope of its training can lead to problems, as the machine won’t know how to handle it.

## What is an LLM (Large Language Model)?

LLM stands for **Large Language Model**, and it’s the foundation of many so-called AI systems. Here’s how it works: data in text form is converted into numbers so that a computer can process it. The machine then trains on this data, learning patterns and developing an understanding of the text. From there, the system can respond to inputs, understanding the context of the language it has been trained on. This ability to process and generate human-like text is what makes LLMs so powerful.

## What is Autocomplete?

**Autocomplete** is a simpler concept that you’ve likely encountered before. As you type, an autocomplete system predicts what you’re trying to say, offering suggestions based on patterns it has learned from previous data. Sometimes it works, and sometimes it doesn’t, depending on the context and complexity of what you’re writing.

## So, What Do These Have in Common?

The common thread between these technologies—machine learning, large language models, and autocomplete—is that they all rely on processing vast amounts of data to make predictions or generate responses. In essence, what we call "AI" today is really just a more advanced form of autocomplete powered by massive datasets and LLMs.

## Is AI a Scam?

Now, let’s address the big question: is AI a scam? My answer is more nuanced than a simple yes or no. The current version of AI is not a scam, but the way it’s portrayed by the media and marketing has definitely inflated its true capabilities.

Yes, these tools make our lives easier and more efficient, but they also have limitations. Current AI systems struggle with understanding complex problems, often give incorrect or incomplete answers, and can fail when faced with unfamiliar contexts.

In short, what we have today isn’t "true" AI in the sense of machines fully replicating human thought and understanding. It’s more like a supercharged version of autocorrect. True AI, in my opinion, will only be achieved when machines can fully understand the context of a conversation and provide accurate, meaningful responses every time.

## Conclusion

So, is AI overhyped? In some ways, yes. While it’s a powerful tool, the current technology isn’t as advanced as the marketing might have you believe. AI today is essentially a highly sophisticated version of autocomplete, and while that’s impressive, it’s not yet the AI of our dreams.

But what do you think? Share your thoughts in the comments below.
Until next time, peace out, nerds! ❤️

---

# Deploy Your Application: A Complete Journey

- **URL**: https://www.rafay99.com/blog/deploy-your-application-the-journey/
- **Published**: 2024-09-19
- **Author**: Abdul Rafay
- **Tags**: DevOps, WebDevelopment
- **Description**: Learn the step-by-step journey of deploying web apps, from server setup to seamless cloud scaling!

For many web developers, deploying an application for the first time can seem like an intimidating step. There’s much more to the process than just writing code, and choosing the right deployment path can be overwhelming. In this guide, we'll walk through the journey of deploying a web application, starting with hosting on a Virtual Private Server (VPS) and moving toward simpler, more automated deployment options like Platform-as-a-Service (PaaS).

This journey will teach you how to get your web apps online efficiently, preparing you for future challenges as your projects grow in complexity.

# Step 1: Hosting on a VPS

When starting out, hosting your web application on a **Virtual Private Server (VPS)** is a great way to learn about managing servers. A VPS gives you control over the server environment, allowing you to build up essential skills that will help you later in your development career.

### **Why VPS?**

- Full control over server settings and configurations.
- A great learning opportunity for web developers to get hands-on experience with servers.

**Key Concepts to Learn:**

- **SSH (Secure Shell)**: This allows you to remotely connect to your VPS and control it through the terminal. You'll use SSH to run commands, manage files, and install software.
  - **Example**: SSH into your VPS to deploy your app or fix issues directly from your machine.
- **Basic Terminal Commands**: Get familiar with terminal commands like `ls` (list directory), `cd` (change directory), and `cp` (copy files). This will help you navigate and manage the files on your server.
- **Running Your App on a Server**: Once your web app is on the server, you'll need to install its dependencies (e.g., using `npm` for Node.js apps) and run the app using a process manager like `pm2`, which ensures the app stays online, even if your server restarts.
  - **Example**: Using `pm2` to run a Node.js application continuously.

Hosting on a VPS is a foundational skill, and although it requires manual setup, it gives you a solid understanding of what happens behind the scenes when you deploy an application.

## Step 2: Managing Dependencies and Configuring Your App

After you’ve set up your VPS, it’s time to manage the dependencies your application needs to run.

**Key Steps:**

- **Installing Dependencies**: Whether your app uses JavaScript (`npm`, `yarn`), Python (`pip`), or another language, you need to install the necessary libraries or frameworks it depends on.
  - **Example**: Running `npm install` to download the packages your Node.js app needs.
- **Environment Variables**: Many web apps need configuration values like API keys or database URLs. Rather than hardcoding these into your app, you should use environment variables to keep sensitive data secure.
  - **Example**: Setting up a `.env` file and using a library like `dotenv` to manage environment variables.

By learning how to manage dependencies and configurations, you'll be able to run your application smoothly in any environment.

## Step 3: Setting Up HTTPS with a Reverse Proxy

As a web developer, ensuring that your users can securely access your application is essential. One of the first steps to doing this is setting up HTTPS, which encrypts the data between your users and your server.

**Key Tasks:**

- **Reverse Proxy (Nginx)**: You can use a reverse proxy like Nginx to handle incoming web requests and forward them to your application server. Nginx also helps with things like serving static files or load balancing.
  - **Example**: Configuring Nginx to forward traffic from port 80 (HTTP) or 443 (HTTPS) to your app running on another port.
- **SSL/TLS Certificates**: You'll need an SSL certificate to enable HTTPS. Services like Let's Encrypt offer free SSL certificates and automated tools (like `certbot`) to keep them updated.
  - **Example**: Using Let's Encrypt to generate an SSL certificate and enable HTTPS on your site.

With HTTPS in place, your users will trust that their data is secure, and you’ll avoid browser warnings that could drive visitors away.

## Step 4: Scaling Your Application

As your application grows, you might face performance challenges, especially if more users start visiting your site. Scaling ensures your app can handle increased traffic.

**For Web Developers:**

- **Horizontal Scaling**: If you need more power, you can add more servers (or instances of your app) to share the load. This is known as horizontal scaling. You can configure Nginx to distribute traffic between multiple servers.
  - **Example**: Setting up Nginx to load balance traffic between two instances of your app.
- **Database Scaling**: If your app uses a database, you may need to consider ways to make it handle more traffic. This could include using read replicas (additional database servers to handle more read requests) or caching frequently used data.
  - **Example**: Adding a read replica for your PostgreSQL database to reduce the load on the primary database server.

Even as a web developer, knowing how to scale your application can help you build sites that grow alongside your user base.

## Step 5: Automation with Containerization (Docker)

As your projects become more complex, setting up every server manually can become time-consuming. This is where **containerization** comes in.

**Why Web Developers Should Use Docker:**

- **Consistency**: Docker ensures that your app will run the same way, regardless of where it’s deployed—on your local machine, on a VPS, or on a cloud platform.
  - **Example**: Using Docker to create a container that includes your entire web app and its dependencies.
- **Simplified Deployment**: Once you’ve set up Docker for your project, deploying it to another environment (like production) is as simple as running a few commands.
  - **Example**: Running your web app in a Docker container on a VPS.

For web developers, Docker simplifies deployment, making it easier to maintain consistent environments and avoid issues like "it works on my machine."

# Simplifying Deployment with Platform-as-a-Service (PaaS)

For many web developers, managing a VPS can be a lot of work. This is where **Platform-as-a-Service (PaaS)** options come into play. PaaS platforms like **Vercel**, **Railway**, or **Heroku** take care of the infrastructure, allowing you to focus solely on your code.

**Key Benefits for Web Developers:**

- **Ease of Use**: With PaaS, you can deploy your app with just a few clicks or a single command. These platforms handle everything from scaling to security and even provide features like auto-deployment when you push code to GitHub.
  - **Example**: Deploying a React app on Vercel with automatic scaling and HTTPS built-in.
- **Focus on Code**: PaaS solutions handle all the server management for you, meaning you can spend more time writing code and less time worrying about infrastructure.
  - **Example**: Using Heroku to quickly deploy a Node.js API without configuring a VPS or server.

For web developers, PaaS solutions offer an easier and faster way to get apps online, making them ideal for smaller projects or when you just want to focus on building features.

# Conclusion

Deploying an application can be a complex process, but as a web developer, understanding the basics will allow you to handle every aspect of getting your app live. Starting with VPS hosting gives you a strong foundation in server management, and using Docker or PaaS can streamline and simplify the process. With time, patience, and hands-on experience, you’ll become proficient at deploying applications and maintaining them as they grow.

By mastering these steps, you’ll be able to deploy faster, scale easier, and build better applications—all without needing to dive deep into DevOps.

Until then, peace out, nerds. ❤️

---

# SnapRescue: Protect & Rollback Your System

- **URL**: https://www.rafay99.com/blog/snaprescue/
- **Published**: 2024-09-18
- **Author**: Abdul Rafay
- **Tags**: DevOps
- **Description**: SnapRescue: Your system’s safety net! Snap, roll back, and relax with this easy-to-use script that keeps your snapshots in check.

In Linux, system stability is crucial, and recovering from issues like misconfigurations or broken updates can be quite stressful. That's where **SnapRescue** comes in. SnapRescue is a user-friendly Bash script designed to streamline system backup and recovery using **Snapper** snapshots. This post will walk you through how it works, explain each part of the script, and show you how to get started with it.

## **Why Use SnapRescue?**

Imagine you're installing some updates or tweaking system files, and suddenly, your system breaks. A tool like **SnapRescue** helps safeguard your setup by automatically taking regular snapshots of your system. If anything goes wrong, you can simply roll back to the last working state.

## **How Does SnapRescue Work?**

At the core of SnapRescue is the **Snapper** utility, which allows for easy snapshot management on Btrfs file systems. SnapRescue automates the process of configuring Snapper, taking snapshots, and setting up rollback options. It also helps ensure that essential dependencies and configurations are correctly set up.

### **Step-by-Step Breakdown of the Script**

### 1. **Pre-Checks**

The script starts by checking if your file system is **Btrfs** and if you're running an **Arch-based** system. If either of these conditions isn't met, the script exits early to avoid unnecessary errors.

```bash
filesystem=$(findmnt -n -o FSTYPE /)
if [[ "$filesystem" != "btrfs" ]]; then
    echo "File system is not Btrfs. Exiting script."
    exit 1
fi
```

### 2. **Dependency Installation**

The script ensures that essential tools like **snapper**, **grub-btrfs**, and others are installed on your system. If not, it automatically installs them via Pacman.

```bash
required_packages=(snapper snap-pac grub-btrfs inotify-tools git)
sudo pacman -S "${missing_packages[@]}" --needed --noconfirm
```

If the **snapper-rollback** package isn't available from Pacman, it's cloned from the AUR and installed.

### 3. **Snapshot Setup and Configuration**

After cleaning up any old snapshots, the script creates a Snapper configuration for your root partition, setting up timelines for daily, weekly, and monthly snapshots. It ensures that the `.snapshots` directory isn't mounted or in use and allows for easy rollback in case of future issues.

```bash
sudo snapper -c root create-config /
sudo sed -i 's/^[[:space:]]*ALLOW_GROUPS[[:space:]]*=.*/ALLOW_GROUPS="wheel"/' /etc/snapper/configs/root
```

### 4. **Mounting, Hooks, and Grub Updates**

To make the recovery process as smooth as possible, the script configures Grub to display available Snapper snapshots during boot. It also moves necessary hooks and install scripts to appropriate locations.

```bash
sudo cp -r switchsnaprotorw /etc/initcpio/hooks/
sudo cp -r switchsnaprotorw /etc/initcpio/install/
sudo mkinitcpio -P
```

### 5. **Driver Detection and Setup**

The script auto-detects Btrfs partitions or allows you to manually specify them. It then integrates the selected partition into the Snapper rollback configuration.

```bash
driver=$(lsblk -f | grep btrfs | awk '{print $1}')
echo "dev = /dev/$driver" | sudo tee -a /etc/snapper-rollback.conf
```

### 6. **Service Activation**

Once everything is configured, the script enables Snapper's **timeline** and **cleanup** services to ensure snapshots are taken and managed efficiently.

```bash
sudo systemctl enable --now snapper-timeline.timer
sudo systemctl enable --now snapper-cleanup.timer
```

### 7. **Completion and Reboot**

At the end, SnapRescue prompts the user to reboot to finalize the changes or reboot later, depending on preference.

```bash
read -p "Do you want to reboot now? (y/n): " choice
```

## **How to Install SnapRescue**

### **One-Line Installation Command**

To install and execute SnapRescue on your system, run the following command:

```bash
curl -fsSL https://rafay99.com/snaprescue.sh | sh
```

This command will automatically download and run the SnapRescue script, ensuring your system is set up with Snapper snapshots.

---

By the end of this process, your system will be safeguarded by Snapper, allowing you to confidently make changes to your system knowing you can always roll back to a previous snapshot.

## SnapRescue GitHub Project

If you'd like to try out SnapRescue yourself or contribute to its development, the full source code is available on GitHub. The repository includes detailed instructions for setting up and using SnapRescue with Snapper to protect your Linux system through automated snapshots and easy rollbacks.

You can find the project here: [SnapRescue GitHub Repository](https://github.com/rafay99-epic/SnapRescue).

Feel free to explore, report issues, or contribute to the project. Your feedback and contributions are always welcome!

## **Co-Developer**

I'd like to extend my gratitude to [@sharjeelmazhar](https://github.com/sharjeelmazhar) for their invaluable contributions to the SnapRescue project. Their dedication and expertise have significantly enhanced the functionality and usability of the script.

# **Conclusion**

With SnapRescue, you have an efficient and automated tool for handling system snapshots and ensuring a smooth recovery process. Whether you're an advanced user or just starting out, this script simplifies system maintenance and provides peace of mind.

Until then, peace out, nerds. ❤️

---

# Web Assembly in Flutter

- **URL**: https://www.rafay99.com/blog/web-assembly-in-flutter/
- **Published**: 2024-09-05
- **Author**: Abdul Rafay
- **Tags**: MobileDevelopment, WebDevelopment
- **Description**: Flutter for web: web assembly

Imagine a world where your web applications run as smoothly as desktop programs, handling complex tasks like gaming, video editing, or heavy data processing without breaking a sweat. Sounds too good to be true? Well, welcome to the era of Web Assembly (WASM)! This groundbreaking technology is transforming how web apps perform, allowing them to execute high-performance code nearly as fast as native applications. And now, with Flutter’s latest updates, we’re getting closer to bridging that gap even further. But before you get too excited, there's a lot to unpack here—especially if you're diving into Flutter for the web. Let’s get into it.

# What is Web Assembly (WASM) & How Does It Work?

Web Assembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.

In simple words, Web Assembly (WASM) is a technology that allows websites to run high-performance code, almost as fast as programs installed on your computer. It helps web applications work more efficiently by letting them use code written in different languages, which is then converted into a special format that web browsers can understand and execute quickly. This makes web apps faster and more powerful, especially for complex tasks like games, video editing, and data processing.

# Flutter + WASM

Before we begin, you must know WASM is not a rendering engine for Flutter in the way that HTML or CanvasKit renderers are. Instead, WASM is a compilation target for code that needs to run efficiently in the web environment.

## Role of Web Assembly (WASM) in Flutter Web

As discussed, WASM is a compilation target for Flutter Web. It is a binary instruction format that allows Flutter Web to run almost at native speed in web browsers. It is mainly used to compile web apps with performance-critical features so that they run faster in the browser.

Because WASM is not a renderer itself, your web app will use the default web renderer or the one you specify.

PS: Now, the Flutter team has changed the `--web-renderer` is equal auto to `canvaskit`, which means if you don’t specify a web renderer, it will automatically use CanvasKit. Earlier, it used to default to the HTML renderer when the app ran in a mobile browser, and CanvasKit when it ran in a desktop browser. ([Issue Link](https://github.com/flutter/flutter/issues/149826))

# How to Use WASM with Flutter?

Now, the only question that remains is: how can we use WASM in Flutter? However, there is a problem as usual. Most Flutter packages do not support WASM, which is crucial for Flutter. If you are using `dart.js` or `dart.html`, these packages are not available for WASM in Flutter. It won’t compile your Dart code for WASM either. So, only code from Dart libraries will be compiled.

To use WASM with Flutter, you need to upgrade your Flutter SDK to version 3.22 or higher. As of now, the latest Flutter version is 3.24.2, and this version does support WASM for Flutter. Once you have the Flutter SDK, you can use it by building your project with this command:

```dart
flutter build web --wasm
```

# Pros and Cons of Using WASM in Flutter

Here are some pros and cons of using WASM in your project:

## Pros

When using WASM with Flutter, you may notice improvements, especially in performance:

- Faster Execution: Parts of your app that are computationally intensive, such as complex calculations, animations, or data processing tasks, will run much faster due to WASM near-native execution speed.
- Smooth Animations: With WASM, animations and transitions can become smoother, especially in graphics-intensive applications. You might also notice smoother scrolling.
- Reduced Load Times: The initial load time for the web app might be faster because WASM modules are compact and optimized for efficient execution.

## Cons

While WASM can help with performance and scrolling issues, there are still some general disadvantages:

- WASM does not include a built-in garbage collector, which means languages that rely heavily on garbage collection (like JavaScript or Dart) need additional handling for memory management when compiled to WASM.
- Not all packages are supported for WASM yet.
- WASM modules can increase the overall memory footprint of the application, which may impact performance on devices with limited resources.

There are still several issues with Flutter + WASM.

# Conclusion

Web Assembly is not just a performance booster for Flutter; it's a pivotal technology that unlocks new potential for web applications, making them faster, more secure, and highly efficient. By embracing WASM, Flutter developers can stay ahead of the curve, delivering exceptional web experiences that rival native applications.

I am still not convinced that Flutter for Web is mature enough to build a whole web application. Sure, with this addition, Flutter has come a long way, but there’s still a long road ahead. One day, I believe Flutter for Web will be awesome, and I’ll be here to tell you that "Flutter for Web is here."

Until then, peace out, nerds. ❤️

---

#  Flutter: A Full Stack Developer's Perspective

- **URL**: https://www.rafay99.com/blog/flutter-mobile-web-desktop-experience/
- **Published**: 2024-07-25
- **Author**: Abdul Rafay
- **Tags**: MobileDevelopment
- **Description**: The Reality of flutter for web and applications

Flutter is great. I love Flutter. As a full stack Flutter developer, I find it awesome and highly effective for developing Android and iOS applications. With its clean UI, simple code, and OOP structure, you can create amazing applications. Flutter also boasts a wide range of packages for different state management needs, making it a superior choice for building Android or iOS applications.

However, Flutter's motto of "write once and cover all platforms" includes mobile, web, and desktop applications. I've used Flutter for all these purposes, and here's a spoiler: Flutter for web and desktop applications isn't great.

It can work, but it's not worth it. Let's break down what makes Flutter for web and desktop applications so problematic.

## Problems

Here are some of the problems I faced while developing Flutter web applications:

### Not Enough Packages

While there are some packages for Flutter web and desktop, many common packages aren't available. For example, push notifications and picking images from your computer are lacking.

There are workarounds, but they often don't work across both web and mobile platforms. Since Dart code compiles for the target platform, using web-specific packages means the code won't compile for mobile devices. This necessitates different checks for each platform, which complicates and degrades code readability.

### Too Much JavaScript

When you write in Dart, the code translates to the native platform—Kotlin for Android, Swift for iOS, and HTML, CSS, and JavaScript for the web. This sounds good, but it isn't simple. At runtime, JavaScript is injected, which can improve performance for small applications but not for full-stack applications.

#### Personal Experience

I built my blog website using Flutter, Firebase, and many packages. The local host was fast, but deployment led to slow application parts. Despite my efforts, the load time didn't improve due to excessive JavaScript. For example, I used Lottie animations with Firebase-loaded content, but the site was still slow.

Moreover, slow loading can be a significant issue, especially if the internet connection is poor. This affects my website's functionality, as it serves as a showcase of my work. Therefore, excessive JavaScript can hinder the user experience.

## Pros

Now, let's discuss the positives of Flutter mobile application.

### Amazing Developer Experience

Flutter offers one of the best developer experiences with features like hot reloading, application restart, OOP structure support, and amazing packages for Android and iOS development. Solid state management options like GetX, Riverpod, and Provider make development efficient and enjoyable.

Each state management solution serves different project sizes, and mastering one can benefit you in the long run. You can even develop applications without state management, making things more flexible and enjoyable.

### Package Support

The community offers numerous packages that enhance the development experience. For instance, connectivity_plus checks internet connections, and various packages handle login options like Google Sign-In, Apple Sign-In, and GitHub Sign-In. For animations, Flutter has built-in Tween packages, and you can use page transition packages with minimal code and customization.

Flutter excels in developing Android and iOS applications.

### Backend Technology

A robust backend is crucial for application functionality. Various backend options include:

1. Firebase
2. Supabase
3. Pocketbase

Each backend offers full cloud support, with their own pros and cons. Firebase is the largest, Supabase is new but promising, and Pocketbase is self-hosted. I've used all these options, and they are fantastic. Each has a Flutter SDK, allowing you to connect your backend to the frontend in minutes, simplifying development.

### Update Code on the Fly

With packages like Storebird, you can update your application on the fly, bypassing the Google Play Store. This makes life easier, as you can push updates directly, ensuring users have the latest application experience.

## Conclusion

In summary, Flutter is incredible for mobile application development, offering a robust SDK, stunning animations, clean code, and mobile optimization. However, for web applications, it's not yet up to par. Even with web assembly in Flutter 3.22, it still isn't fast enough for seamless web development. Perhaps the new static site generator will improve Flutter's web performance, but we'll have to wait and see.

Judge technology based on its current state, not future promises. With the introduction of Flutter's static site generator, we'll see how things evolve.

Until then, peace out, nerds. 👓

---

# My Love & Hate Relationship with Copilot

- **URL**: https://www.rafay99.com/blog/mylovehaterelationshipwithcopilot/
- **Published**: 2024-07-24
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess
- **Description**: Explores the nuanced relationship with GitHub copilot, discussing both its benefits and drawbacks.

In this world, there are always two sides of a coin: one is good, and one might be bad. You can also say the pros and cons of some things, and for that, it's coding AI tools. I have a love and hate relationship with GitHub Copilot.

For those unfamiliar with Copilot, here’s a quick introduction: Copilot is a tool that attempts to understand your problem and then searches GitHub for matching solutions and suggests them to you. For many, this tool is something they love as they can create the solution faster, as they can just wait for a suggestion to be recommended and apply it as fast they can and then move on with their life.

## The Hook

The story begins not so long ago. When it was released, I was like, okay, it’s going to be like code completion or something, but I was not sure about the whole chat feature and much more, and then I used it. At that time, I was learning Flutter and I already had a website. My domain was Machine Learning, but I was trying to switch from Machine Learning to Application Development. Moreover, I want to be a Software Engineer. I started using Copilot as a free trial, and in the beginning, I loved it. I wanted to create a Flutter application with a web view so that I can have a mobile and web both at the same time, but I learned a lot from this. Starting out with Flutter and having a teacher on your side was awesome.

## The Permanent Switch

Then the free trial came to an end, and then I started to build a lot of applications without using Copilot, but at that time, it felt like something was missing. And then after some time, I just bought Copilot. I started using it again in daily life as well, in every project. And sure, I was enjoying it. Just facing any issue or error, just ask Copilot, and you have a solution. I was making sure the coding that I was writing was good and readable, plus, I understood the code that I wrote.

## Problem

But you see, everything is not sunshine and rainbows, and something might look good, but it’s not. One day, my Copilot was not working, and I was panicking, finding out what is happening and checking my connection, and then it hit me. I have lost my ability to do any task without an AI tool.

At that time, I would say, yes, I was using it too much. And as much as I love it, it’s not good for me. And that’s where the title comes into play, the Perfect Love and Hate relationship with GitHub Copilot.

## Removes the engineer from Software Engineering

One of the problems with Copilot is that it diminishes the ability to solve real-life problems. In place of analyzing problems and finding a good solution, we just pass the problem to the AI, which is not correct and right. With time, this will change your mindset and remove your ability to think outside the box, and that is not for a Software Engineer.

For example, you are working on a project, and your first instinct is to pass this error or problem to Copilot, and that's what I did for a while. Instead of searching the web and finding the solution, when answers are given to you easily, you will never remember how to solve this problem. And in the near future, if you come across those same issues, then your reply is AI as well. Now you have learned nothing.

This is just one problem. There is another problem when you give an error to Copilot. Then there might be a chance that the solution might be very simple, but Copilot will provide a complex solution. Here is a live issue: for my Flutter Project, I want to detect two different languages. One was HTML and the other was Markdown. Copilot wanted to use regex, which is alright, but the issue with this approach is that regex will cause a lot of performance issues, and you are in this loop. This code is working and this code is not working. You are stuck in a loop in which you are losing time and resources.

## Stop Learning

As software engineers, continuous learning is essential. We often learn by problem-solving, addressing issues, and devising solutions. However, over-reliance on AI in our development process can hinder this learning. We may apply code without fully understanding it, which can be detrimental in the long run. Just because you used an AI to solve a bug doesn’t mean you should rely on it every time a similar issue arises.

This can be a significant issue, especially for new developers. It’s crucial that we’re able to “feel” the code we’re working on. Programming is not just about understanding code; it’s about connecting the pieces in the larger puzzle to build a solution, and it takes time to understand this, and it’s really important in the beginning of the career and also why learning programming takes time.

## More efficient

All this talk about makes me think about a question, and that is, with these tools, are we more productive, or have we become more lazy?

The answer to this question is very simple. I don’t believe that we necessarily become more effective by using AI. Often, we might find ourselves stuck in a loop, waiting for new suggestions repeatedly. In such situations, we could likely solve the problem faster, and perhaps even better, by using our own brains instead.

We often associate efficient programming with the ability to produce large amounts of code quickly. However, this isn’t necessarily true. A single line of code can sometimes be more efficient and easier to work with than ten lines of code.

AI is effective at generating boilerplate but often falls short in providing quality solutions.

## The End

I’ve critiqued Copilot for a while, but it’s worth mentioning that it’s not necessarily bad to use it, provided you choose the appropriate time. I still use Copilot, but only when I’m working on simpler tasks that it can easily handle, like generating boilerplate code. However, I only enable it occasionally. I’ve noticed that it’s crucial not to rely heavily on such tools, as doing so can lead to negative habits, like waiting for a suggestion and hitting enter repeatedly to find a solution.

AI can pose a significant challenge for new developers. It’s tempting to let AI dictate the path to a solution, rather than using it as one of many potential paths. This often leads to developers accepting the code returned by AI without truly understanding it. However, understanding the code is essential for new developers.

---

# The Truth About No Code Tools

- **URL**: https://www.rafay99.com/blog/no-code-tools/
- **Published**: 2024-07-24
- **Author**: Abdul Rafay
- **Tags**: ThoughtsProcess
- **Description**: Explores the nuanced relationship with GitHub copilot, discussing both its benefits and drawbacks.

In recent years, no-code tools have surged in popularity, promising quick and easy application development without the need for extensive coding knowledge. These platforms are enticing, especially for small projects or non-technical users. However, as someone who has ventured deep into the realm of no-code and low-code development, I've come to realize that they are far from ideal for large-scale projects. Here’s why:

## Complexity and Customization Limitations

No-code platforms shine when dealing with straightforward, cookie-cutter applications. But when it comes to complex and highly customized projects, they fall short.

**Personal Experience:**
I encountered a project on Upwork involving an Android application called TextLink, developed using Flutter for both Android and iOS. The app owner wanted a custom widget, which should have been a straightforward task. However, while the no-code tool FlutterFlow did offer an option for custom widgets, it simply did not work as expected. This limitation is a glaring example of how no-code platforms can struggle with non-standard requirements.

## Code Quality and Maintainability Issues

One of the most significant drawbacks of no-code tools is the quality of the generated code. Often, these tools produce bloated and inefficient code, filled with unnecessary boilerplate. This can severely impact the readability and performance of the application.

- **Personal Experience:**
  - When I downloaded the code from FlutterFlow, I found it laden with excessive boilerplate code. This not only made the codebase hard to read and maintain but also slowed down the application significantly. Such inefficiencies can be a nightmare for developers tasked with maintaining or extending the application in the future.

## Scalability Challenges

Large projects require a solid foundation that can support future growth and scalability. No-code platforms often lack the robustness needed for scaling applications efficiently.

- **Personal Experience:**
  - In my experience with the TextLink project, I advised the client that fixing the issues with the no-code generated application might take a considerable amount of time. I suggested rebuilding the application from scratch, emphasizing that coding the application manually would adhere to best practices, ensuring a scalable and maintainable codebase.

## Long-Term Viability and Vision

Building an application with a clear vision and structured approach is crucial for its long-term success. Developers and teams usually follow a set of standards and best practices to ensure the application is robust and maintainable.

- **Personal Experience:**
  - When working on the TextLink project, it became evident that no-code tools often compromise on these standards. The resulting codebase from FlutterFlow was not only inefficient but also lacked the structure and coherence that a manually coded application would have. This can lead to significant technical debt and potential long-term damage to the product.

## Conclusion

No-code tools can be incredibly useful for quick prototypes or simple applications. However, for large-scale, complex projects, they introduce more problems than they solve. The limitations in customization, poor code quality, scalability issues, and long-term viability concerns make them a poor choice for serious, large-scale application development.

If you’re considering using no-code tools for a significant project, think twice. The initial convenience may be tempting, but the long-term repercussions could outweigh the benefits. For substantial projects, investing in traditional coding practices with a skilled development team is the safer, more sustainable approach.

## Share your thoughts

Have you had any experiences with no-code tools in large projects? What challenges did you face, and how did you overcome them? Let’s discuss in the comments below!

---

# Secure Linux The 3 Biggest Security Mistakes Linux Users Make

- **URL**: https://www.rafay99.com/blog/secure-linux/
- **Published**: 2023-07-19
- **Author**: Abdul Rafay
- **Tags**: DevOps, Linux
- **Description**: Security is a Journey not a destination

After using a Linux system for a while, I've noticed that there are some common mistakes people make that can compromise the security of their Linux installations. In this blog post, I will address the three most significant security mistakes that Linux users often make. These mistakes can be exploited by hackers, making them essential points to consider for basic security layers.

# Base Security Layer

The base security layer is the first line of defense against attackers and consists of three components: Network Security Layer, Operating System Security Layer, and Application Security Layer.

## Network Level

Managing a firewall on a system can be a daunting task, but it is crucial for maintaining security. In this section, we will discuss the two most common types of firewalls in Linux: **_ufw_** and **_fail2ban_**.

### UFW (Uncomplicated Firewall)

UFW is easy to set up and understand. It efficiently blocks and allows network traffic.

#### Installing UFW

To install UFW on major Linux distributions, use the following commands:

- Debian/Ubuntu

```bash
sudo apt-get install ufw
```

- Fedora

```bash
sudo dnf install ufw
```

- Arch

```bash
sudo pacman -S ufw
```

#### Recommended UFW Rules

Here are some effective UFW rules to secure your system:

```bash
sudo ufw limit 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
```

### Fail2Ban

Fail2Ban is an excellent intrusion prevention utility present in almost all Linux servers. It blocks IP addresses attempting to brute force your server and releases the block after a certain time.

#### Installing Fail2Ban

To install Fail2Ban on major Linux distributions, use the following commands:

- Debian/Ubuntu

```bash
sudo apt-get install fail2ban
```

- Fedora

```bash
sudo dnf install fail2ban
```

- Arch

```bash
sudo pacman -S fail2ban
```

#### Configuring Fail2Ban

Fail2Ban requires configuration to be effective. Here's a sample configuration that you can use on your servers and computers:

Create or edit the file: `/etc/fail2ban/jail.local`

```conf
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1
bantime = 3600
findtime = 600
maxretry = 5

[sshd]
enabled = true
```

#### Enabling Fail2Ban

To enable Fail2Ban, run the following commands:

```bash
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
```

## Operating System Level - Adding Repositories

Adding untrusted repositories can lead to serious security issues. It's crucial to only add repositories that are trustworthy and safe.

### Prioritizing Repositories

On Debian-based systems, you can set priority preferences for repositories. Example: **_volian.pref_**

```ini
Package: *
Pin: origin deb.volian.org
Pin-Priority: 100
```

- Set specific packages to only install with the Package: - Line
- Pin: Origin is the address of the repo
- Pin-Priority is generally 100 which means it will update packages NOT in base repos.
  - 1 = do not auto-update
  - 100 = update if not in other repos
  - over 100 = overwrite base repos

(Note: Arch Linux does not have built-in repository priorities in Pacman)

## Application Level - Not using AppArmor or SELinux

Many Linux distributions come with AppArmor or SELinux pre-installed, but some, like Arch Linux, may not. These tools are essential for sandboxing and limiting application access, even when they are elevated to higher privileges.

However, simply installing these tools in permissive modes is not enough to provide full protection. Users need to configure and customize application profiles to ensure proper security.

To learn more about using AppArmor or SELinux, refer to the respective documentation:

- [AppArmor Documentation](https://gitlab.com/apparmor/apparmor/-/wikis/Documentation)
- [SELinux Documentation](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/index)

# Conclusion

Securing your Linux system is essential to protect it from potential threats. By following best practices at the base security layer, prioritizing repositories, and using tools like AppArmor or SELinux, you can significantly enhance your system's security. Remember to stay informed about the latest security measures and keep your system up-to-date to stay ahead of potential attackers.

With that, we will see you next time.❤️❤️

---

# Optimize Your Fedora: 5 Essential Post-Installation Steps

- **URL**: https://www.rafay99.com/blog/optimize-fedora-experience/
- **Published**: 2023-06-30
- **Author**: Abdul Rafay 
- **Tags**: Linux
- **Description**: Top 5 things when freshed installed Fedora

So you've installed Fedora on your system, and I hope you're enjoying it. However, out of the box, there are a few things that could be improved. In this blog post, we will go through the top five things to do after installing Fedora on your system.

# Top 5:

Here are the top 5 things I would do when I install Fedora on my system, and I will be throwing in a bonus one as well.

## Update your system

Even if you used the latest ISO to install Fedora, there will still be some updates available. It's a good idea to update your system using these steps:

1. Open the Terminal.
2. Enter the following command:

```bash
sudo dnf update -y
```

## Enable RPM Fusion Repository

Fedora, out of the box, does not include non-free software. So, you need to enable the RPM Fusion Repository to access these additional packages. Follow these steps:

1. Open the Terminal.
2. Enter the following commands:
   - To enable the Free repository:

```bash
sudo dnf install \
     https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
```

- To enable the Nonfree repository:

```bash
sudo dnf install \
     https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
```

- Install one command line tool:

```bash
sudo dnf group update core -y
```

## Change dnf.conf file

Out of the box, Fedora uses DNF as the package manager, but it can be slow. To give it a speed boost, you can change some options in the dnf.conf file. Follow these steps:

1. Open the Terminal.
2. Navigate to the dnf folder:

```bash
cd /etc/dnf/
```

1. Edit the dnf.conf file:

```bash
sudo nano dnf.conf
```

1. Add the following lines of code to the conf file:

```bash
fastestmirror=True
max_parallel_downloads=10
defaultyes=True
keepcache=True
```

1. Press Ctrl+X on your keyboard to exit and press Enter to exit the editor.
2. Update your system once more:

```bash
sudo dnf update -y
```

**This time the update will take some time, so please wait.**

## Adding Flatpaks support

Flatpaks are a great way to find and install applications without any compatibility issues. To enable Flatpak support, follow these steps:

1. Open the Terminal.
2. Enter the following commands:

```bash
sudo dnf install flatpak
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
```

Once these commands are entered, Flatpak will be enabled and installed on your system. You can now install applications using Flatpak. Visit the [Flathub website](https://flathub.org/) to search for applications and find installation commands.

## Enable Multimedia Codecs

Starting from Fedora 38, the Fedora team decided not to include Multimedia Codecs by default. To install these codecs, follow these steps:

1. Open the Terminal.
2. Enter the following commands:
   - Switch to the FFmpeg codec:

```bash
 sudo dnf swap ffmpeg-free ffmpeg --allowerasing
```

- Install additional codecs:

```bash
sudo dnf groupupdate multimedia --setop="install_weak_deps=False" --exclude=PackageKit-gstreamer-plugin
sudo dnf groupupdate sound-and-video
```

**For a full custom installation of multimedia codecs, stay tuned for an upcoming blog post. You can also refer to the official documentation in the references section of this blog post.**

## Bonus: Change your Host Name

By default, the system name is set to "fedora," and if you prefer a different name, you can change it easily. For example, to change the system name to "Prometheus," follow these steps:

1. Open the Terminal.
2. Enter the command:

```bash
sudo hostnamectl set-hostname "Prometheus"
```

1. Reboot or restart your system for the changes to take effect.

# Conclusion:

In conclusion, by updating your system, enabling the RPM Fusion Repository, optimizing the dnf.conf file, adding Flatpak support, enabling Multimedia Codecs, and customizing your hostname, you can enhance your Fedora experience, expand software availability, improve system performance, and personalize your setup. Enjoy the benefits of a more optimized and feature-rich Fedora system!

With that, we will see you next time.❤️❤️

---

# Nvidia Driver: Fedora Linux

- **URL**: https://www.rafay99.com/blog/nvidia-driver-fedora/
- **Published**: 2023-06-29
- **Author**: Abdul Rafay 
- **Tags**: Linux
- **Description**: Nvidia Drivers on Fedora

In the world of graphics-intensive tasks and gaming, having the right drivers installed is crucial for optimal performance and compatibility. If you are a Fedora user seeking to harness the power of Nvidia graphics cards, you've come to the right place. This comprehensive guide will walk you through the step-by-step process of installing Nvidia drivers on your Fedora system.

By following this guide, you'll be able to unlock the full potential of your Nvidia graphics card, ensuring smooth visuals, improved stability, and access to advanced features. Whether you're a seasoned Fedora user or new to the Linux ecosystem, this guide will provide clear instructions and valuable insights to simplify the driver installation process.

We'll cover the necessary preparations, package management techniques, and troubleshooting tips to help you overcome any potential challenges. With the right drivers in place, you'll experience enhanced graphics performance, increased compatibility with modern applications, and the ability to explore the latest advancements in graphics technology.

Let's embark on this journey together and equip your Fedora system with the Nvidia drivers it deserves. Get ready to elevate your visual experience and unlock the full potential of your Nvidia graphics card on Fedora.

If you are running Arch Linux and want to install Nvidia Drivers on your system, you can check out my other blog post by clicking [here](/nvidia-driver-arch-linux/).

# Prerequisites

Before we begin, there are a couple of things that need to be done, and all of them are stated below:

1. Fedora should be installed.
2. Internet connection is required.
3. The system should be up to date.

So now you have installed Fedora on your system, and your system is updated. If not, you can update your system by following these steps:

1. Open the Terminal.
2. Enter the following command:

```bash
sudo dnf update -y
```

Once this command is entered, your system will begin to update, and all the necessary packages will be installed on your system.

An internet connection is a must; without it, you cannot install anything on your system.

# Install Drivers

To install the Nvidia driver, there are three things that you need to do on your system:

1. Enable RPM Fusion Repository.
2. Check which Nvidia Card you have.
3. Install Nvidia Drivers.

## Enable RPM Fusion Repository

To enable the RPM Fusion repository, follow these steps:

1. Open the Terminal.
2. Enter the following commands:

   2.1. **To enable the Free repository:**

```bash
sudo dnf install \
   https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
```

2.2. **To enable the Nonfree repository:**

```bash
sudo dnf install \
   https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
```

2.3. **Install one command line tool:**

```bash
sudo dnf group update core -y
```

1. **Update the system:**

```bash
sudo dnf update -y
```

## Check Nvidia Card

Now that you have enabled RPM Fusion, it's time to check your Nvidia driver. Follow these steps:

1. Open the Terminal.
2. Check your Nvidia card:
   - NVIDIA has several driver series, each of which has different hardware support. To determine which driver you need to install, you'll first need to find your graphics card model.
   - If you don't know it, open a Terminal (Applications > System Tools > Terminal) and type:

```bash
/sbin/lspci | grep -e VGA
```

- If your NVIDIA card is found, use the following command:

```bash
/sbin/lspci | grep -e 3D
```

- You can also check the [supported chips](https://download.nvidia.com/XFree86/Linux-x86_64/495.44/README/supportedchips.html) section and see which series is recommended for your card, then install the appropriate driver series.

## Install Nvidia Driver

Now that you know which card you are using, you can install Nvidia drivers on your system. Check your model's year, and based on that information, follow the steps below to install the drivers on your system.

### Current GeForce/Quadro/Tesla

- Supported on the current stable Xorg server release.
- This driver is suitable for any GPU found in 2014 and later.

⚠️ The 510+ driver is available by default on Fedora 34+ and later and has dropped support for some older Kepler GPUs.

```bash
sudo dnf install akmod-nvidia
sudo dnf install xorg-x11-drv-nvidia-cuda #optional
```

### Legacy GeForce 600/700

- Supported on the current stable Xorg server release.
- This driver is suitable for any NVIDIA Kepler GPU found between 2012 and 2014.

```bash
sudo dnf install xorg-x11-drv-nvidia-470xx akmod-nvidia-470xx
sudo dnf install xorg-x11-drv-nvidia-470xx-cuda #optional for CUDA up to 11.4 support
```

### Legacy GeForce 400/500

- Supported on the current stable Xorg server release. EOL by NVIDIA at the end of 2022. Still available on a "best effort basis" (newer kernels may break, will be discontinued at any time if not actively maintained).
- This driver is suitable for any NVIDIA Fermi GPU found between 2010 and 2012.

```bash
sudo dnf install xorg-x11-drv-nvidia-390xx akmod-nvidia-390xx
sudo dnf install xorg-x11-drv-nvidia-390xx-cuda #optional for CUDA up to 9.2 support
```

### Legacy GeForce 8/9/200/300

- Supported on the current stable Xorg server release. EOL by NVIDIA at the end of 2019. Still available on a "best effort basis" (newer kernels may break, will be discontinued at any time if not actively maintained).

```bash
sudo dnf install xorg-x11-drv-nvidia-340xx akmod-nvidia-340xx
sudo dnf install xorg-x11-drv-nvidia-340xx-cuda #optional for CUDA up to 6.5 support
```

⚠️ This driver doesn't support "pre-optimus" devices, so if you have a means to only use the NVIDIA device in BIOS, use the following commands:

```bash
sudo dnf copr enable kwizart/kernel-longterm-6.1
sudo dnf install akmods gcc kernel-longterm kernel-longterm-devel
sudo dnf install xorg-x11-drv-nvidia-340xx akmod-nvidia-340xx
```

### Legacy GeForce 6/7

Supported up to Fedora 27 - EOL, no more Nvidia updates.

### Legacy GeForce 5 (FX series)

Supported up to Fedora 20 - EOL, no more Nvidia updates.

### Legacy GeForce 2 through GeForce 4

Supported up to Fedora 14 - EOL, no more Nvidia updates.

# Conclusion:

In conclusion, installing Nvidia drivers on your Fedora system is essential for optimizing the performance and compatibility of your Nvidia graphics card. This guide has provided clear instructions on enabling the RPM Fusion repository, identifying your Nvidia card, and installing the appropriate drivers. By following these steps, you can enhance graphics performance, stability, and access advanced features. Keep your drivers up to date and refer to this guide for troubleshooting. Enjoy the improved visual experience and happy computing!

With that, we will see you next time.❤️❤️

---