DEV Community: Ali Haroon

From Broken Auth Template to Production-Grade Project Management API — Finished with GitHub Copilot

Ali Haroon — Tue, 26 May 2026 10:46:52 +0000

GitHub Copilot Finish-Up-A-Thon Challenge submission — May 21–June 7, 2026.

🔗 Project Source

Repository: github.com/AliHaroon111/Project-Management-Backend
Challenge Branch: copilot-challenge-submission

Every developer has that one folder. The one with a half-built project that got shelved mid-way, full of potential but never shipped. Mine was a Node.js authentication boilerplate — 12 files, a working register endpoint, and 8 silent bugs that made the entire password-reset flow fail without a single error message.

This challenge gave me the perfect reason to open it back up. What I shipped after 4 days with GitHub Copilot is something I'm genuinely proud of.

The Before: An Honest Assessment

Before writing a single line of new code, I ran a full audit on what I actually had.

My initial codebase: 12 files, auth-only, 8 bugs, no task management, no error handling, ~55% complete.

Here is what I found:

What was working (sort of):

User registration and login — but login only accepted email, ignoring the username field it was receiving
JWT middleware — but with a dead { header } import from express-validator sitting at the top
Email verification flow — but the verification URL in every email was pointing to /api/v1/users/verify-email/ which didn't exist
Forgot password — completely broken because forgotPasswordMailgenContent was imported in auth.controllers.js but never actually imported from mail.js

What was silently broken:

The most dangerous bug was in resetForgotPassword. The token lookup was doing:

crypto.createHash("sha-256") // ← wrong

The correct algorithm name in Node.js crypto is "sha256" — no hyphen. This meant every single password reset attempt would silently fail to find the user in the database and return "Token is invalid or expired" — even for a valid token that was seconds old. A user would never know why.

Eight bugs total. None of them throwing loud errors. All of them breaking real user flows.

Phase 1: The Git Branching Wall — My First Real Fear

I need to be honest about something before I talk about code.

When I saw the challenge requirement — "work must be done on a separate branch"
— my first reaction was anxiety, not excitement.

Branches. Merging. Checkout. These words had always looked intimidating to me.
I had been using Git for months but only ever on main. One branch.
Push and pray. The mental model of parallel branches, switching between them,
and then merging them back together genuinely confused me. I had avoided it
completely.

The challenge didn't give me that option.

So I sat down, read the docs properly for the first time, and actually understood
what a branch is — it's just a pointer to a commit. A safe copy of your work
where you can build freely without touching the original. That's it.
The terminology had made it sound far more complicated than it actually was.

git checkout -b copilot-challenge-submission
git push origin copilot-challenge-submission

Two commands. Branch created, pushed to GitHub.
The thing I had been afraid of for months took about 90 seconds.

The branch on GitHub

This is one of those lessons that only clicks when you have a real reason
to do it. The challenge forced my hand and I am genuinely grateful for that.
I now understand branching, I understand why teams use it, and I understand
how to merge back to main when the work is done. A wall I had been walking
around for months turned out to be a door I just hadn't tried to open.

I kept the original broken code on main intentionally — as honest
documentation of where I started. The entire transformation lives on
copilot-challenge-submission. Anyone can compare the two branches on GitHub
and see exactly what changed.

Phase 2: Setting Up the Right Way

The challenge required work on a dedicated branch, which aligned perfectly with good Git hygiene. I created copilot-challenge-submission from main to keep the original skeleton untouched and build the finished version on top.

Branch created, Copilot sidebar active in VS Code. Ready to go.

One important early step: adding ADMIN_SECRET to the .env file. The original codebase accepted a role field on registration with zero protection — anyone could register as "admin" by just passing "role": "admin" in the body. Copilot helped me add a secret-key guard:

// anyone can register, but claiming admin requires the secret key
let assignedRole = "member";
if (role === "admin" || role === "project_admin") {
    if (adminSecret !== process.env.ADMIN_SECRET) {
        throw new ApiError(403, "Invalid admin secret key");
    }
    assignedRole = role;
}

Small change. Massive security difference.

Phase 3: Fixing the Bugs with Copilot

I opened each broken file and used Copilot Chat (sidebar) to describe what I was seeing. The workflow was:

Open the file in VS Code
Describe the symptom to Copilot: "This function always returns 'token invalid' even for fresh tokens — why?"
Copilot would identify the issue and suggest the fix
I reviewed, understood, and accepted

Copilot identifying the sha-256 hash algorithm bug. The fix is one character — removing the hyphen — but finding it without AI would have taken much longer.

Here is the full bug list, fixed in one focused session:

#	Bug	File	Impact
1	`sha-256` → `sha256` in crypto hash	`auth.controllers.js`	Password reset always failed
2	`forgotPasswordMailgenContent` not imported	`auth.controllers.js`	ReferenceError in production
3	`action` and `outro` outside `body` in email template	`mail.js`	Forgot-password email had no button
4	HTTP status `489` (not real)	`auth.controllers.js`	Invalid response code
5	Login only searched by email, ignored username	`auth.controllers.js`	Username login silently failed
6	Route typo `/resend-emil-verification`	`auth.routes.js`	Endpoint unreachable
7	Dead `{ header }` import	`auth.middleware.js`	Lint noise, dead code
8	Verify email URL had `/users/` not `/auth/`	`auth.controllers.js`	Every verification email 404'd

After fixing all 8: npm run dev → register → check Mailtrap → click verify link → 200 OK. First time that flow had ever actually worked end to end.

A Note on Honesty: When Copilot Wasn't Enough

GitHub Copilot was my primary tool throughout this sprint —
but I want to be transparent about something.

Copilot has usage limits. There were moments, especially during
the longer building sessions on Day 3 and Day 4, where I hit
those limits mid-flow. A schema half-written. A controller
function halfway through. The suggestion stream would slow down
or stop responding the way it had been.

In those moments, I did what any developer would do —
I used what was available. I turned to other LLMs (Claude and
ChatGPT at different points) to keep the momentum going,
asked similar questions, got the code, reviewed it the same way
I reviewed Copilot's output, and kept building.

I am mentioning this because I think honesty matters more than
a clean narrative. The challenge is called a "Finish-Up-A-Thon"
— the goal is to finish the project. The AI tools I used were
assistants, not authors. Every line of generated code went
through my eyes, my understanding, and my decision to accept,
modify, or reject it.

What I can say with confidence: GitHub Copilot inside VS Code —
the inline suggestions, the Chat sidebar, the Ctrl+I inline
chat — handled the majority of the heavy lifting.
The workflow of describing what I wanted in plain English and
getting working code back in seconds is genuinely transformative
for a developer at my stage.

The bug-finding session on Day 1 was almost entirely Copilot.
The activity logger pattern — Copilot. The RBAC middleware —
Copilot. The Swagger JSDoc annotations across 40+ routes —
Copilot with some Claude assistance when the limit hit.

I learned from all of it. That is what matters.

Phase 4: Building What Was Always Missing

With a stable auth foundation, I shifted to building the actual project management system. This is where Copilot went from debugging tool to genuine pair programmer.

The Data Models

I navigated to src/models/ and used Copilot Inline Chat (Ctrl+I) to scaffold each new schema. My prompt style was always specific about relationships:

"Create a Mongoose schema for a Project model. It should have name, description, status (enum: active/on_hold/completed/cancelled), a createdBy ObjectId ref to User, and a members array where each member has a user ObjectId ref and a role string. Add compound indexes for createdBy and members.user."

Four new models created:

src/models/
├── project.models.js    ← Project with embedded members[]
├── task.models.js       ← Updated: added priority, dueDate, project ref
├── comment.models.js    ← Comments on tasks
└── activity.models.js   ← Audit log for every action

The Activity Logger — My Favourite Part

The most elegant piece of the system is the logActivity() utility. It gets called after every meaningful action across every controller — but it's designed to never crash the main request even if it fails:

export const logActivity = async (action, entity, entityId, userId, metadata = {}) => {
    try {
        await ActivityLog.create({ action, entity, entityId, performedBy: userId, metadata });
    } catch (err) {
        // Silently swallow — logging must never break a real request
        console.error("Activity log failed silently:", err.message);
    }
};

Now every create, update, delete, login, and comment is recorded. Admins can query GET /api/v1/activity and see a full audit trail. Members see only their own activity.

I described this pattern to Copilot and it immediately suggested the try/catch wrapper with the silent swallow — a pattern I had read about but never implemented myself.

Task Management: More Than a Todo List

The original constants.js had TaskStatusEnum defined (todo, In_progress, done) but no task model, no routes, and no controllers. The constants were written but the feature was never built.

I added TaskPriorityEnum to match:

export const TaskPriorityEnum = {
    LOW: "low",
    MEDIUM: "medium",
    HIGH: "high",
    URGENT: "urgent",
};

Then built the full task system on top — with one GET /tasks endpoint that does everything:

GET /api/v1/tasks?search=login&priority=urgent&overdue=true&sortBy=dueDate&order=asc&page=1&limit=10

That single endpoint handles full-text search across title and description, filter by status/priority/assignee/project, overdue detection, sorting, and pagination — all composable together.

The Tool I Had Never Seen Before: Swagger

I want to be upfront about something — before this challenge,
I had never used Swagger in my life.

I had heard the word. I had seen screenshots of it in tutorials.
But I had never actually sat down, configured it, and had it
generate live documentation from my own code.

When I first ran npm run dev after wiring up swagger-ui-express
and opened http://localhost:8000/api/v1/docs — I genuinely did
not expect what I saw. Every single route, laid out visually.
Request bodies with example values. A padlock icon showing which
routes needed authentication. A "Try it out" button that let me
test my own API without opening Postman.

I spent probably 20 minutes just clicking through it before I
remembered I had more features to build.

My first time seeing Swagger UI on my own project.
Every route documented, explorable directly in the browser.

The learning curve was real though. My first Swagger setup
showed "No parameters" on every POST route — because I had
forgotten that Swagger needs JSDoc @swagger comments above
each route to know what the request body looks like.
The routes existed and worked perfectly, but Swagger had no
idea what data they expected.

Here is what an empty POST route looks like in Swagger vs
a documented one:

// ❌ Before — Swagger shows "No parameters"
router.route("/projects").post(createProject);

// ✅ After — Swagger shows a full interactive form
/**
 * @swagger
 * /api/v1/projects:
 *   post:
 *     summary: Create a new project
 *     tags: [Projects]
 *     security:
 *       - bearerAuth: []
 *     requestBody:
 *       required: true
 *       content:
 *         application/json:
 *           schema:
 *             type: object
 *             required:
 *               - name
 *             properties:
 *               name:
 *                 type: string
 *                 example: My Awesome App
 *               status:
 *                 type: string
 *                 enum: [active, on_hold, completed, cancelled]
 *                 example: active
 */
router.route("/projects").post(createProject);

Once I understood the pattern, documenting every route became
satisfying rather than tedious. You write the comment once,
and Swagger generates a fully interactive UI from it.
Any developer who clones the repo can open /api/v1/docs,
authorize with their JWT token, and test every single endpoint
without reading a single line of code.

That is what "production-grade API documentation" actually means.
I understood the concept before this project.
Now I understand why it matters.

POST /tasks with all fields filled — title, priority urgent,
due date set. One click to Execute. This is what
"Try it out" looks like in practice.

Phase 5: The Features That Make It Shine

Projects with Member Access Control

POST   /api/v1/projects               ← create (creator auto-becomes project_admin)
GET    /api/v1/projects               ← list projects I created + am member of
GET    /api/v1/projects/:id           ← project detail + all its tasks
PATCH  /api/v1/projects/:id           ← update (project_admin or owner)
DELETE /api/v1/projects/:id           ← delete (owner only, unlinks tasks)
POST   /api/v1/projects/:id/members   ← add member with role
DELETE /api/v1/projects/:id/members/:userId  ← remove member

Non-members get a clean 403 when trying to access a project they don't belong to. The PROJECT_ADMIN role that was defined in the original constants.js but never enforced now actually does something.

Task Comments

Three routes, one model, makes the whole system feel collaborative:

POST   /api/v1/tasks/:taskId/comments          ← add comment
GET    /api/v1/tasks/:taskId/comments          ← paginated list
DELETE /api/v1/tasks/:taskId/comments/:id      ← delete own comment (or admin)

Deleting a task cascade-deletes all its comments. getTaskById now includes a commentsCount field.

Dashboard Stats

GET /api/v1/tasks/stats

Returns:

{
  "stats": {
    "total": 24,
    "byStatus": { "todo": 10, "In_progress": 9, "done": 5 },
    "byPriority": { "urgent": 3, "high": 7, "medium": 11, "low": 3 },
    "myTasks": 6,
    "overdueTasks": 2,
    "recentTasks": [...]
  }
}

One endpoint. Everything a frontend dashboard needs.

The Final API Surface

Auth — /api/v1/auth

Method	Endpoint	Auth
POST	`/register`	—
POST	`/login`	—
POST	`/logout`	JWT
GET	`/current-user`	JWT
GET	`/verify-email/:token`	—
POST	`/resend-email-verification`	JWT
POST	`/refresh-token`	—
POST	`/forgot-password`	—
POST	`/reset-password/:token`	—
POST	`/change-password`	JWT
PATCH	`/update-avatar`	JWT
PATCH	`/update-profile`	JWT

Tasks — /api/v1/tasks · Projects — /api/v1/projects · Activity — /api/v1/activity

Production Signals Added

Signal	Implementation
Security headers	`helmet()` — 11 headers set automatically
Rate limiting	`express-rate-limit` — 10 req/15 min on auth endpoints
Request logging	`morgan` — dev mode and combined production format
Global error handler	4-param Express middleware — no stack traces to clients
404 handler	Custom JSON response for unknown routes
Input validation	`express-validator` on all auth routes
File upload validation	multer with type filter (JPEG/PNG/WebP) + 2MB limit
API documentation	Swagger UI + swagger-jsdoc, OpenAPI 3.0
Audit logging	Every meaningful action logged with metadata
RBAC	`verifyRole()` middleware enforced at route level

Postman Proof

User registration returning 201 with the created user object (sensitive fields excluded).

User registration For Admin user returning 201 with the created user object (sensitive fields excluded).

Login returning access token, refresh token, and user object. Tokens auto-saved to Postman environment via test script.

Dashboard stats endpoint — aggregated counts by status and priority.

Activity feed showing audit trail of all actions.

RBAC working correctly — member role correctly blocked from deleting tasks.

What GitHub Copilot Actually Did

I want to be specific because "I used Copilot" is easy to say.

Copilot found bugs I would have stared at for hours. The sha-256 vs sha256 issue — I had been running the reset flow and getting "token expired" responses. I described the symptom to Copilot Chat and it immediately asked "is the hash algorithm name correct in Node.js crypto?" — and that was it. Five seconds.

Copilot taught me patterns I knew existed but hadn't implemented. The silent-swallow try/catch in logActivity(). The $or MongoDB query for login by email or username. The validateBeforeSave: false pattern in Mongoose saves. I knew all of these things conceptually. Copilot showed me the exact idiomatic way to write them.

Copilot accelerated schema and boilerplate generation. Every new model, every new controller — I described what I wanted in plain English and got working code back in seconds. I reviewed every suggestion before accepting. I rejected probably 20% and adjusted another 30%. But starting from something working is dramatically faster than starting from blank.

Copilot didn't write the architecture. The decision to use an embedded members[] array in Project rather than a separate collection — that was mine. The fire-and-forget logger pattern — I described it to Copilot and it implemented it. The overdue filter composing with other query params — my design, Copilot's implementation. This felt like genuine pair programming.

What I Learned

Finishing is harder than starting. Starting a project is exciting — you make fast decisions and the wins come quickly. Finishing means auditing what you have, being honest about what's broken, and fixing unglamorous bugs before adding new features. The 8-bug fix session on Day 1 was the most important thing I did.

The "silent failure" is the worst kind of bug. Six of my eight bugs produced no error — they just returned wrong data or hit a route that didn't exist. Without end-to-end testing, you'd never find them. With Copilot, describing the symptom was enough to surface the cause.

AI pair programming works best when you lead. The best outputs came when I was specific: "This function needs to search by email OR username using MongoDB's \$or operator — modify the findOne call" produced better results than "fix my login function." Copilot responds to context and intent. The more precisely I described what I wanted, the less reviewing and editing I had to do.

Git branching went from intimidating to obvious. I had avoided branches
for months because the terminology looked complex. The challenge requirement
forced me to actually do it — and it took two commands. Sometimes the only
way to stop fearing a tool is to have no choice but to use it.

Why Open-Weight Models Like Gemma 4 Are the Future of Secure Backend Architecture

Ali Haroon — Sun, 24 May 2026 04:20:09 +0000

Why Open-Weight Models Like Gemma 4 Are the Future of Secure Backend Architecture

How Google's free, offline AI is breaking barriers for millions of developers — especially in Pakistan

The Problem Nobody Talks About

Imagine you are a talented developer in Lahore, Karachi, or a small town in rural Punjab. You have the skills. You have the ambition. You have ideas that could build the next great product.

But you face a wall that developers in San Francisco or London simply do not.

Your internet package ran out three days before your deadline. The cloud API bill arrived and it is more than your weekly grocery budget. The connection drops mid-session and you lose your entire conversation with the AI assistant😒. You simply cannot afford $20 per month for a ChatGPT subscription on top of everything else.

This is the daily reality for tens of millions of developers across South Asia, Africa, and the developing world. AI is supposed to be the great equalizer — the technology that lets a solo developer compete with a Silicon Valley team. But when AI lives behind a paywall or requires a fast, stable internet connection, it becomes yet another advantage for those who are already advantaged.

Until now.

What Is Gemma 4?

Gemma 4 is Google's latest family of open-weight AI models, released in April 2026. Think of it as a free, private, and highly capable AI assistant that lives entirely on your own laptop — no cloud, no subscription, no internet required.

Unlike ChatGPT or Google's own Gemini API — which process your data on remote servers and charge you per request — Gemma 4 is fundamentally different. Google has released the model weights under the Apache 2.0 open-source license, which means the core intelligence of the model is yours to download, run, modify, and even build products on top of, completely free.

It comes in four sizes designed for different hardware:

E2B — Runs on phones and edge devices. Requires only 2–4 GB of memory.
E4B — The standard laptop model. Balanced speed and intelligence. Requires 4–8 GB.
26B — A high-efficiency desktop model using a Mixture of Experts architecture. Requires 16 GB+.
31B — The powerhouse. Deep reasoning and complex coding. Requires 24 GB+.

Every single one of them runs 100% offline.

Why Is Gemma 4 Completely Free?

This question deserves a real answer, because when something powerful is free, people assume there is a catch. With Gemma 4, the economics are genuinely different.

The business model of services like ChatGPT is straightforward: they run massive data centers full of expensive GPUs, process your messages on their servers, and charge you for that compute.

With Gemma 4, Google releases the model weights publicly and you run it on your own hardware. Google has no server costs for your usage, because you are the server. That is why they can offer it for free. The Apache 2.0 license even allows commercial use — you can build and sell products powered by Gemma 4 without any legal restrictions.

What you need to run it:

RAM: At least 8 GB, with 16 GB recommended
Storage: 5–10 GB of free disk space for the model files
Processor: Any modern CPU — Apple M-series, Intel i5/i7, or AMD Ryzen all work fine
GPU: Optional, but makes responses significantly faster

Most laptops sold in the last four years meet these requirements. A mid-range Ryzen 5 machine — the kind you can find in Lahore's electronics markets — can run the E4B model comfortably.

Why Gemma 4 Will Remain Free😃

One of the biggest concerns developers have with modern AI platforms is long-term accessibility. Many popular AI systems initially attract users with free access but later move advanced capabilities behind expensive subscriptions or paid APIs.

However, Gemma 4 follows a fundamentally different philosophy.

Google released Gemma 4 under the permissive Apache 2.0 open-source license, which gives developers permanent legal rights to use, modify, and distribute the model. This license is irrevocable, meaning users who download the model can continue using it freely for both personal and commercial projects. Once the model exists on a user's device, it cannot suddenly be locked behind a paywall.

This creates a major difference between open-weight AI and closed cloud AI systems.

When developers use cloud-only AI platforms, the provider controls:

access,
pricing,
usage limits,
and subscriptions.

But with Gemma 4, developers actually own the downloaded model files locally on their machine. Since the AI can run completely offline, Google has no technical control over how frequently users run the model or what projects they build with it.

This is especially important for:

students,
startups,
independent developers,
educational institutions,
and developers in countries with economic limitations.

A student in Pakistan can install Gemma 4 on a laptop and continue learning AI development without worrying about monthly subscriptions, API quotas, or increasing token costs.

Even commercial use is allowed. Developers can build applications, automate workflows, create AI tools, or launch startups using Gemma 4 without paying royalties or licensing fees.

Of course, Google still offers paid cloud infrastructure services for organizations that want managed hosting through platforms like Google Cloud Vertex AI. But the core Gemma 4 model itself remains free for anyone who chooses to run it locally.

This open model approach is one of the strongest reasons why Gemma 4 represents more than just another AI release — it represents a long-term shift toward accessible and developer-owned artificial intelligence.

A Game-Changer for Pakistan — and Every Developing Nation

Let us be specific. Let us talk about Pakistan.

Pakistan has over 300,000 IT graduates per year and a rapidly growing freelance economy. Pakistani developers are talented, creative, and hungry to build. But the AI tools that define modern development — tools that are becoming as essential as a code editor — have been largely out of reach for economic and infrastructure reasons.

Gemma 4 changes this in a profound way.

The Internet Problem

Pakistan's internet is improving, but it remains expensive relative to income. A 100 Mbps fiber connection might cost PKR 3,000–5,000 per month — a significant expense for a junior developer. Mobile data packages are even more restricted.

Cloud-based AI makes this worse. Every API call consumes bandwidth. A productive day of coding with an AI assistant can easily consume hundreds of megabytes of data. With capped packages, this is simply not sustainable.

Gemma 4 uses zero data after the initial download. Download the model once on a good connection — at a university, a cafe, or a friend's place. Then use it forever. On a plane. In a village with no cell signal. During load-shedding with a UPS. The AI keeps working.

The Cost Problem

The economics of commercial AI APIs are brutal for developers in lower-income countries. OpenAI's GPT-4o costs $5–15 per million tokens. At production scale, this can run into thousands of dollars per month. ChatGPT Plus costs $20/month just for personal use — nearly half a week's salary for many junior Pakistani developers.

With Gemma 4, the cost of running AI in your application is exactly zero beyond your electricity bill. A developer in Multan can build the same AI-powered product as a developer in Mountain View. The playing field, for the first time, is genuinely level.

The Privacy Problem

When you send code or client data to a foreign cloud API, that data leaves your country. For Pakistani startups handling user information, this raises legitimate legal and ethical questions about data sovereignty.

With Gemma 4, your data never leaves your device. Your prompts, your code, your client information — none of it is ever transmitted anywhere. This is not just a privacy feature. It is a data sovereignty feature.

**
What This Means for Developers: The Technical Benefits**

Beyond connectivity and cost, Gemma 4 offers technical capabilities that make it genuinely powerful for backend development.

Zero-Cost Backend AI Integration

The traditional architecture for an AI-powered backend: your server receives a request, calls the OpenAI or Gemini API, waits for a response, and returns it. You pay for every single call.

With Gemma 4, you host the model on your own server. Your server receives a request, calls the local Gemma 4 instance, and gets a response. The cost per call: nothing. For a Pakistani startup with limited runway, this can mean the difference between a viable product and one that burns through its budget before finding users.

Massive Context Window

The E2B and E4B models support a 128,000 token context window. The 26B and 31B models support 256,000 tokens. You can feed an entire codebase, a full documentation set, or a lengthy technical specification into a single conversation.

For Pakistani freelancers who are often handed large, undocumented legacy codebases by international clients, this is transformative. Drop the entire codebase into Gemma 4 and ask it to explain the architecture, identify issues, or suggest refactoring strategies.

Function Calling and Agent Capabilities

Gemma 4 supports native function calling — meaning it can output structured JSON to interact with your APIs, databases, or external services. You can build AI agents that actually do things rather than just talk about them. All of this runs locally, with no external calls and no costs.

Thinking Mode for Hard Problems

Gemma 4 includes a Thinking Mode that forces the model to reason through a problem step by step before giving a final answer. Instead of getting a confident-but-wrong response, you get a transparent reasoning chain you can follow and critique. This is especially valuable for debugging complex issues or working through architectural decisions.

Multimodality: Vision and Audio

All Gemma 4 models support image input. The smaller models also support audio. Practical uses: screenshot a UI bug and ask Gemma 4 to identify the CSS causing it. Take a photo of a whiteboard architecture diagram and ask it to generate the corresponding code. Record a client meeting and have it extract the technical requirements.

How to Get Started

Getting Gemma 4 running on your machine takes about ten minutes.

Option 1: Ollama (Best for Developers)

Ollama is a free, open-source tool that manages local AI models. Download it from ollama.com, then run this in your terminal:

ollama run gemma4:e4b

Ollama downloads the model and launches an interactive chat interface. Ollama also exposes a local REST API, so you can call Gemma 4 from your backend exactly like you would call the OpenAI API — but for free, on your own machine.

Option 2: LM Studio (Best for Beginners)

LM Studio provides a graphical interface — no terminal required. Download it from lmstudio.ai, search for Gemma 4, pick your model size, and start chatting. It also includes a local API server for backend integration.

Conclusion: The Democratization of AI

The history of technology has a recurring pattern. Powerful tools start as expensive, centralized services accessible only to well-funded companies in wealthy countries. Then they get open-sourced and distributed to everyone.

We are watching that pattern play out with AI right now.

Gemma 4 is not just a good model. It is a signal that the era of AI as a paid cloud utility — one that systematically excludes developers from lower-income countries — is coming to an end.

For a developer in Pakistan, running Gemma 4 means you can compete. You can build AI-powered products without a cloud budget. You can work without a reliable internet connection. You can keep your client's data private and secure. You can experiment freely without worrying about API bills.

Google did not just release a model. They released a piece of infrastructure — as fundamental and free as a web server — that every developer on earth can now build on.

That is a massive achievement, and it deserves to be celebrated🥳.

Try it today: download Ollama from ollama.com or LM Studio from lmstudio.ai, and run your first local AI model in under ten minutes.