Skip to content
Abdulkader Safi

Service

VS Code Extension Development

VS Code Extension Development

Your developers leave the editor a hundred times a day to check a dashboard, run a script, or look up a convention. An extension brings it to them.

Your developers leave the editor constantly. To check a dashboard. To run the same script with slightly different arguments. To look up the internal convention nobody wrote down. To paste something into a tool, read the result, and paste it back.

Every one of those context switches costs more than the task did. An extension brings the thing to them instead.

What I build

Internal developer tooling. Your team's scripts, checks, and conventions, wired into the editor as commands and diagnostics. Nobody memorises a runbook.

API integrations. Surface your internal service, issue tracker, deployment status, or design tokens in a panel next to the code, so the answer is where the question is.

Rich webview panels. Real interfaces inside the editor, with charts, history, and state, not a text output in a terminal tab.

Language and diagnostic tooling. Inline warnings for your own rules, quick fixes, and code actions that encode what your senior engineers keep saying in review.

What I've shipped

I've built and run VS Code extensions, including a quick image-edit tool that handles format conversion, resize, crop, and compression without leaving the editor. I also maintain a Svelte 5 extension starter with Tailwind, esbuild, and webview messaging already wired, which is the boring scaffolding that eats the first week of most extension projects.

I've also had a plugin accepted into a public marketplace on another platform after independent code and security review, which is the discipline that matters when something ships to other people's machines.

Worth knowing: I've moved my own daily editing to Neovim and Zed. I still build VS Code extensions, and I'm honest that I'm building for an editor I no longer live in full time. For most extension work that changes nothing. If your project depends on deep instincts about VS Code's day-to-day feel, factor it in.

How it works

  1. A call. You show me where your team leaves the editor. Free, 30 minutes.
  2. Scope. What it does, what it doesn't, what it costs. In writing, before you commit.
  3. Build. Something installable by around week two.
  4. Handover. Source, docs, and a build you can publish or ship privately.

What you get

The code is yours, documented well enough that another developer can maintain it without me.

Ready to start?

Tell me what your developers keep leaving the editor to do. If an extension isn't the right answer, or one already exists, I'll say so on the call and charge you nothing.

Reach me by email, on LinkedIn, or fill in the form on this page.

What you get

Deliverables

  • Working VS Code extension, packaged and tested
  • Clean, documented TypeScript source you fully own
  • Build and release pipeline
  • Marketplace publishing support, or a private VSIX for internal distribution
  • User documentation for your team
  • Handover walkthrough

Why work with me

The scaffolding is already solved

I maintain a Svelte 5 extension starter with Tailwind, esbuild, and webview messaging wired up. That is the boring week most extension projects lose at the start.

Marketplace-grade discipline

I have had a plugin accepted into a public marketplace after independent code and security review. That standard applies to anything shipping to your team's machines.

Full-stack, so integrations are routine

Surfacing your internal API in a panel means auth, caching, and rate limits. Six years of Laravel and .NET means that half is not the hard part.

You own it outright

Full source, documentation, and build pipeline. Nothing licensed back to you, nothing dependent on my availability later.

FAQ

Frequently asked questions

How much does it cost to build a custom VS Code extension?

VS Code extension projects start at $3,000. A focused command that automates one internal task sits near the lower end, while an extension with a rich webview panel, live API integration, and custom diagnostics costs more. Scope and price are agreed in writing before you commit anything, and the first 30-minute call is free so we can establish whether an extension is the right answer at all.

Can we keep the extension private to our company?

Yes, and most internal tooling should be. I package the extension as a VSIX file that your team installs directly, or you distribute it through a private registry, with nothing ever touching the public Marketplace. If you do want it published publicly under your own name, I handle that submission instead. The choice does not change the price.

Can the extension talk to our internal APIs and services?

Yes, and it is one of the most valuable things an extension does. It can surface your deployment status, issue tracker, internal service data, or design tokens in a panel beside the code, so your developers stop switching to a browser to answer a question. The work involves handling authentication safely, caching so the editor stays fast, and failing quietly when the network is unavailable rather than blocking the editor.

Can an extension enforce our team's coding conventions?

Yes. Custom diagnostics can surface inline warnings for your own rules, and code actions can offer one-click fixes, which effectively encodes what your senior engineers keep repeating in code review. This works well for conventions that a general-purpose linter cannot express because they are specific to your architecture or domain. It moves the knowledge from people's heads into the editor.

Do you still use VS Code yourself?

Not as my daily editor, and I would rather say so plainly. I have moved my own work to Neovim and Zed, though I still build VS Code extensions and maintain a Svelte 5 extension starter for them. For the large majority of extension work this changes nothing, because the API and the build pipeline are the substance. If your project depends on deep instincts about the editor's day-to-day feel, factor that in when you decide.

Who owns the extension when it's finished?

You do, completely. You receive the full TypeScript source, the documentation, and the build pipeline, and nothing is licensed back to you. The code is documented well enough that another developer can maintain it without me, because an extension only one person understands is a liability rather than an asset.

Tell me about the project

Pre-tagged to this service, so the enquiry arrives with the context already attached.

I reply within one business day. If it is not a fit I will say so and point you somewhere else.

I reply within one business day.

By submitting, you agree to the privacy policy.

Other services

  1. Freelance Web Developer
  2. Mobile Application Development
  3. Obsidian Plugin Development