How I Built a Premium Developer Tools Website Using Only a Local LLM (Gemma 4:12B + Ollama + VS Code)

Praveen Maurya — Thu, 25 Jun 2026 19:19:16 +0000

Over the past few weeks, I’ve been experimenting with local language models. Like a lot of developers, I’ve used cloud AI assistants quite a bit, but I kept asking myself one simple question:

Can a local LLM actually help me build a real, production-ready project?

So I decided to find out for myself.

I challenged myself to build an entire developer tools website using only a local AI model running on my own machine. No cloud assistant. No external API. Just my laptop, VS Code, Ollama, and Gemma 4:12B.

The result is SafeDevTools — a collection of browser-based developer utilities with a modern glassmorphic interface, strong SEO foundations, and a privacy-first architecture. You can check it out here: https://safedevtools.com

The site includes tools like:

JSON formatter
JWT parser
Base64 encoder/decoder
Hash generator
CSV to JSON Converter
URL encoder/decoder
Timestamp converter
JSON <-> YAML converter

Honestly, the biggest surprise wasn’t the model itself.

It was how much of a difference a well-written Copilot Skill made.

The Stack

I kept the stack intentionally simple:

VS Code Copilot Agent
Ollama
Gemma 4:12B
HTML
CSS
Vanilla JavaScript

Everything running on Macbook M4 Pro 24GB RAM

That’s it.

No React.

No Angular.

No backend.

No build tools.

No server-side rendering.

And that simplicity mattered more than I expected. It meant the local model could focus on generating clean frontend code instead of getting distracted by framework complexity or project scaffolding.

Running everything on a MacBook M4 Pro with 24GB RAM was also a big advantage. It gave me enough headroom to work comfortably with a local model while keeping the entire workflow fast, private, and fully under my control.

The Biggest Problem

At the beginning, Gemma’s output was a bit all over the place.

Sometimes the layout looked great.

Sometimes the HTML structure changed for no obvious reason.

Some tools used different colors.

Some pages forgot SEO metadata.

Others skipped accessibility or responsive behavior.

The code worked, but it didn’t feel like one project. It felt like a bunch of separate pages written by different people.

That’s fine for a quick prototype, but it doesn’t really work when you’re trying to build something bigger and more consistent.

The Turning Point: Writing a Copilot Skill

Instead of writing longer prompts every time, I created a detailed VS Code Copilot Skill.

That changed everything.

Rather than telling the model what to build each time, I taught it how every tool should be built.

The skill defines things like:

Project architecture
Folder structure
UI design system
Color palette
Glassmorphism styling
SEO requirements
Accessibility standards
Performance expectations
JavaScript architecture
Privacy messaging
Advertisement placeholders
Responsive layouts
Error handling

So every new tool starts from the same standards.

Once that skill was in place, the consistency improved a lot. The pages started to feel like they belonged to the same product instead of being stitched together from random outputs.

That was the real breakthrough.

Instead of constantly correcting the model, I was giving it a reusable engineering blueprint.

Why Local AI Worked Surprisingly Well

Gemma 4:12B isn’t the biggest model out there.

But once the skill encoded the project’s standards, the model didn’t have to invent everything from scratch anymore. It just followed the blueprint.

That made a huge difference.

It reduced weird output, improved consistency, and produced much cleaner code than I was getting from loose, ad-hoc prompts.

If I had to sum up what I learned in one sentence, it would be this:

Smaller models become much more useful when you give them better instructions instead of just bigger prompts.

That really stuck with me.

A Privacy-First Website

One of the main goals for SafeDevTools was making sure every tool runs entirely inside the browser.

Whether you’re:

decoding a JWT
formatting JSON
generating Hash
encoding Base64
converting csv to json
converting timestamps
converting json <-> yaml
encoding or decoding URLs

your input data never leaves your computer.

There are:

no API calls
no uploads
no server-side processing

Everything happens locally using browser APIs and JavaScript.

That was important to me because a lot of developer tools deal with sensitive data. Sometimes you’re pasting tokens, logs, config files, or snippets you really don’t want sent anywhere. With SafeDevTools, that concern just goes away.

It also makes the site feel fast and lightweight, which is always a nice bonus.

Why I Chose Glassmorphism

I didn’t want another plain developer tools website.

A lot of utility sites are useful, but they look a little dated or too functional. I wanted SafeDevTools to feel more like a premium desktop app than a basic web page.

So I leaned into a glassmorphic design style with:

dark slate backgrounds
layered glass surfaces
subtle blur effects
smooth hover animations
modern typography
carefully chosen accent colors

The goal was to make the site feel polished without making it flashy for the sake of it.

And I think that matters more than people admit. Good developer experience isn’t only about whether a tool works. It’s also about whether you actually enjoy using it.

When a tool looks and feels premium, it changes the whole experience.

Simplicity Wins

Every tool is completely self-contained.

Each one lives in its own folder with only three files:

tool-name/

├── index.html
├── style.css
└── script.js

That structure keeps things clean and easy to maintain.

The root project stays minimal too, with just the homepage and the global project files. Nothing feels bloated, and adding a new tool doesn’t turn into a messy refactor every time.

That simplicity ended up being one of the best decisions I made. It makes the project easier to scale, easier to debug, and easier to hand off to the model without confusing it.

What I Learned

The biggest lesson from this project wasn’t really about AI.

It was about software engineering.

AI gives much better results when you give it clear architecture, coding standards, and reusable constraints. That sounds obvious, but I think a lot of people still treat prompts like magic spells instead of treating them like part of the engineering process.

The Copilot Skill became more valuable than any single prompt because it captured the project’s decisions in one place.

Instead of repeating myself over and over, I encoded my preferences once and reused them across every new feature.

That made the whole workflow feel calmer, faster, and much more predictable.

Final Thoughts

Local LLMs are often compared to much larger cloud models, and I get why. But after building this project, I think that comparison misses the point.

A well-instructed local model can be a really solid development partner for structured engineering work.

With the right architecture, reusable skills, and clear project standards, even a 12B parameter model can help build polished, production-ready applications.

For me, this experiment was never about replacing cloud AI.

It was about proving that thoughtful software engineering, combined with local AI, can produce something genuinely useful.

And honestly, seeing SafeDevTools come together — fully offline, privacy-first, and polished enough to feel premium — was more satisfying than I expected.

If you want to see the result, here it is again: https://safedevtools.com

DEV Community: Praveen Maurya