Commands, settings, and keybindings
Palette commands, status bar items, and settings that run your CLI or API without leaving the editor.
The Problem
Your Developers Keep Leaving the Editor to Use Your Tools
It shows up as tab switching, long setup docs, and support questions about config files. Your tool works, but it lives one window away from where people write code.
01 · Tab switching
Developers leave the editor to check your dashboard.
A sidebar tree view shows that data next to their code.
02 · Slow windows
A heavy extension slows every window it loads in.
Activation events and a bundled build keep startup light.
03 · Setup docs
New hires follow a long wiki page to configure tools.
One command sets up their environment the same way for everyone.
04 · Editor forks
Cursor and VSCodium users can't find your extension.
We publish to Open VSX as well as Microsoft's Marketplace.
A developer opens the editor, then a browser tab to check the build, then a terminal to run your CLI with flags nobody remembers. New hires spend their first day on a wiki page of setup steps. Your config format has no highlighting, so typos only show up when a deploy fails. Someone forked an open-source extension two years ago, and now it slows every window and nobody wants to touch it. Each of these costs a few minutes, many times a day, across the whole team.
We start with the steps your developers repeat, then bring the useful ones into VS Code as commands, sidebar views, and editor checks. The extension loads only when it's needed, talks to your API or CLI, and ships through the Marketplace and Open VSX. Your team stays in the editor instead of hunting for the right tab.
Loads only when needed
Activation events keep the extension idle until its commands or files appear.
One build, more editors
Published to Open VSX too, so Cursor and VSCodium users can install it.
Tested in a real editor
Automated tests run inside an Extension Development Host before every release.
Our VS Code Extension Development Process
From Workflow Review to Marketplace Listing in Five Clear Steps
You approve the commands, views, and data the extension touches before code starts, then try it on your own repositories before anything is published.
We watch how your developers use your tool today and list the steps worth bringing into the editor. You get a scoped feature list and a fixed quote. If shared settings or an existing extension already covers it, we'll tell you before we quote.
What's Included
What You Get From a VSCode Extension Developer
Everything VSCode extension development covers: commands, views, language support, AI tools, tests, and publishing, planned around how your developers already work.
Compare Options
DeveloperLook vs Forking an Extension vs In-House Team
Forking an open-source extension is the fastest start, and your own team knows the product best. Here is where each one holds up for a VS Code extension.
| Feature | DeveloperLookBest fit | Fork an extension | In-house team |
|---|---|---|---|
| Up-front planning | Features picked from your team's workflow | Inherits someone else's design | Picked from the backlog |
| Fit to your product | Built around your API or CLI | Partial, after rework | |
| Extension API experience | Commands, views, LSP, and AI tools | Whatever the original covered | Learned on the job |
| Startup performance | Lazy activation and a bundled build | Varies by original code | Often learned late |
| Cross-platform testing | Windows, macOS, Linux, and remote | Rarely documented | Usually one platform |
| Time to first version | 2 to 4 weeks | A few days | Competes with roadmap work |
| Open VSX publishing | Included with every plan | Sometimes included | Often skipped |
| Code ownership | Your repo and publisher ID | Original license applies |
DeveloperLook
Fork an extension
- Up-front planning
- DeveloperLook: Features picked from your team's workflowFork an extension: Inherits someone else's design
- Fit to your product
- DeveloperLook: Built around your API or CLIFork an extension: Partial, after rework
- Extension API experience
- DeveloperLook: Commands, views, LSP, and AI toolsFork an extension: Whatever the original covered
- Startup performance
- DeveloperLook: Lazy activation and a bundled buildFork an extension: Varies by original code
- Cross-platform testing
- DeveloperLook: Windows, macOS, Linux, and remoteFork an extension: Rarely documented
- Time to first version
- DeveloperLook: 2 to 4 weeksFork an extension: A few days
- Open VSX publishing
- DeveloperLook: Included with every planFork an extension: Sometimes included
- Code ownership
- DeveloperLook: Your repo and publisher IDFork an extension: Original license applies
Projects We've Built
Web Apps for Technical Teams We Have Built
Web apps for technical teams that we designed and built. None is a VS Code extension, but each has the dashboards and APIs an extension brings into the editor.
Logify Project Risk and Control Management Web App
- Logistics & Transportation
- Construction
- Dashboard
NextEdge Startup Web Design & Development
- Startups
- Technology
- Business
Herile IT Agency Web Design & Development
- Agency
- Website
Herile HR and Project Management Platform Website
- Business
- Dashboard
- SaaS Platform
What Our Clients Say
What Clients Say After Launch
Feedback from teams we have built websites, apps, and integrations for.
We had a pretty specific idea of what we wanted our website to become, but I wasn’t sure how easily we could explain all of it to a development team. There were quite a few moving parts, and we were working toward a deadline, so I expected a few things to get lost along the way. That never really happened. They understood what we were trying to achieve, kept us updated throughout the process, and got everything ready within the agreed timeline. The final site feels much easier to navigate, works beautifully on mobile, and is noticeably smoother for our customers. It was a huge relief seeing the original idea actually turn into the website we had in mind.
The mobile experience is probably my favourite part of the new site. We had spent a lot of time making sure the desktop version looked right, and the team kept pushing us to think about how everything would actually feel on a phone too. They were right. The navigation is clean, the interactions feel natural, and everything we’ve tested so far works exactly as it should. They also went through the links, forms, integrations, and other details more than once before launch, which I really appreciated. And even after going live, we could still reach out when something came up. The whole process felt friendly, organised, and surprisingly straightforward.
What I appreciate most is that the website is actually easy for us to manage now. We can update content ourselves instead of sending a developer a message every time we need to change something small. They also paid attention to the technical SEO side, which mattered to us because we didn’t want a new website to create problems for the traffic we already had. I’ve probably asked more questions than I should have since launch, but every question has been handled patiently and without any fuss. The team is easy to work with, they explain things clearly, and when we need something changed, they focus on getting it done rather than making the process complicated.
1,250+
Projects shipped
10+
Years of experience
Top 3%
Upwork Top Rated Plus
5 stars
Average review score
Want results like these?
Tell us what you are building. You get a reply within 24 hours on business days, then a written estimate.
Work Culture
Why Developer-Tool Teams Trust Us With Their Extension
An extension runs inside your users' most personal tool, the editor. These habits keep it fast, honest about data, and easy to maintain.
Startup time measured
We check how long the extension adds to editor startup before each release. Developers uninstall slow extensions, so speed protects your install count.
Telemetry follows the user
Any usage data we collect follows VS Code's own telemetry setting and is listed in the README. Developers notice hidden tracking quickly.
Tested on three systems
Every release runs on Windows, macOS, and Linux before it ships. Path and shell differences get caught by us, not by your users.
A README that installs
We write the listing so a developer knows in one screen what the extension does and how to start. A clear listing turns visits into installs.
Fixed scope, written down
Every command, view, and integration gets its own line and price in the proposal. Extra ideas are quoted before anyone starts on them, so the total stays put.
Your code and publisher ID
The repository and the publisher account belong to you from the first commit. You can ship updates without us whenever you like.
Overview
What does VSCode extension development include for a product team?
DeveloperLook does VSCode extension development for developer-tool companies and platform teams. We build commands, sidebar views, language servers, and AI tools in TypeScript, test them in a real editor, and publish to the Marketplace and Open VSX. Projects start from $900, take 2 to 12 weeks, and the code stays yours.
DEVELOPERLOOK
Project facts · VS Code Extension Development
- Service
- VS Code extension development (commands, views, language servers, AI tools, publishing)
- Typical timeline
- 2 to 4 weeks for command extensions, 6 to 12 weeks for language servers
- Platforms
- VS Code desktop and web, plus Open VSX editors such as Cursor and VSCodium
- Built with
- TypeScript, VS Code Extension API, LSP, esbuild, vsce, and ovsx
- Experience
- 10+ years of development experience and 1,250+ shipped projects
- Post-launch support
- 30, 60, or 90 days, depending on plan
- Communication
- Calls in US, UK, and AU business hours
- Starting price
- From $900 USD, fixed scope after a free workflow review
Reviewed 22 Oct 2026 by Saimul Islam
Good fit
Developer-tool companies with an API
Your users live in VS Code all day, and they keep switching to your web dashboard to check builds, logs, or deployments.
Platform teams with internal tooling
Your platform team wrote an internal CLI and a long setup page, and new hires still lose a day getting a working environment.
Products with their own config language
Your product has its own config format or query language, and users want highlighting, completions, and errors as they type.
AI tool and MCP server builders
You built an AI agent or MCP server, and you want developers to add it to VS Code and use it from the chat.
Agencies serving developer-tool clients
Your agency sells developer tooling and needs VSCode extensions development capacity without hiring a full-time TypeScript specialist.
Not a fit
Shared settings only
Your team only needs shared settings, snippets, or a list of recommended extensions. A checked-in .vscode folder covers that without a custom extension.
Browser, not the editor
Your users spend their day in a web browser, not a code editor. Our Chrome Extension Development Services page covers that kind of tool.
Alerts in team chat
You want build alerts and quick commands where your team talks, not where it codes. Our Slack App Development Services page fits better.
JetBrains IDEs only
Your developers all use JetBrains IDEs. VS Code extensions don't run there, so you would need a separate IntelliJ plugin, which this page doesn't cover.
Not sure we're the right fit?
Book a free call or message us. We'll tell you honestly whether we're the right team.
Pricing
Transparent Starting Prices for VS Code Extension Development
These are starting points in USD. Your final price depends on your feature count, language server needs, and where you publish, and you get a fixed proposal after a free workflow review.
For teams that want their CLI, snippets, or quick actions inside VS Code.
$900one-time, USD
- Free workflow review and feature list
- Up to 5 commands with settings
- Status bar item and keybindings
- Marketplace and Open VSX, or private VSIX
- Automated tests in a real editor
- 30 days of post-launch support
Recommended
For developer tools that need their product's data and actions next to the code.
$2,600one-time, USD
- Everything in Command Extension
- Sidebar tree view and webview panel
- Sign-in to your product's API
- Web extension check for vscode.dev
- Release automation with GitHub Actions
- 60 days of post-launch support
For products with their own language, config format, or AI agent.
$5,900one-time, USD
- Everything in Product Extension
- Language server with completions and errors
- Language model tools for the chat agent
- MCP server registered by the extension
- Windows, macOS, and Linux release testing
- 90 days of post-launch support
For Agencies
White-Label VS Code Extensions for Agencies and Studios
You own the client relationship. We supply the extension engineering: feature design, TypeScript code, tests, and Marketplace and Open VSX publishing, delivered under your agency's name in your client's own publisher account.
How the partnership works
White label: your client only ever sees your brand
- Your client
- You, the agency
- DeveloperLook
Share the tool brief
Send the client's API or CLI docs and the workflows their developers repeat.
- Client needs
- You share the details
- Details received
We scope and staff
You receive a feature list, a fixed price, and a named engineer that same week.
- Scope and plan
- Proposal to resell
- Your quoteYOUR LOGO
Build and hand off
We build, test, and publish, then pass over the repository under your brand.
- Done by our team
- Your brand on it
- Handed to your clientDone
Partner with DeveloperLookDelivered under your brand
Stay client-facing
You run the roadmap with your client while we build the extension.
Predictable delivery
Fixed scope per feature, with release dates you can share.
Senior TypeScript engineers
Engineers who know the Extension API, LSP, and publishing rules.
Flexible capacity
Add editor tooling to your offer without hiring a specialist.
The Right Technology for Your Project
Technology Stack
The editor APIs, languages, build tools, and publishing tools we use to ship VS Code extensions that start fast and stay maintainable.
- VS Code Extension API
- Language Server Protocol
- Webview API
- Language Model Tools
- MCP
TypeScript
JavaScript
Node.js
React
- esbuild
- Mocha
- GitHub Actions
- GitHub
- Visual Studio Marketplace
- Open VSX
- vsce
- Private VSIX
FAQ
Frequently Asked Questions
Straight answers on extension cost, timelines, building and publishing, and AI features in VS Code.
Saimul IslamFounder & CEO, DeveloperLookStill have questions?
Send a message or book a call with the team.
VSCode extension development starts at $900 for a command extension with up to 5 commands and publishing. Product extensions with sidebar views and sign-in to your API are $2,600, and language server or AI tool extensions start at $5,900. You get a fixed quote after a free workflow review.
A command extension usually takes 2 to 4 weeks, including publishing. Extensions with webviews or API sign-in take 4 to 8 weeks, and language servers 6 to 12 weeks. A verified publisher badge comes later, because Microsoft asks for 6 months of Marketplace history and a domain at least 6 months old.
You make a VSCode extension by running Microsoft's generator (yo code) and choosing the TypeScript template. The package.json manifest declares commands and when the extension loads, and the code registers what each command does. Pressing F5 opens an Extension Development Host where you try it before packaging.
You package it as a VSIX file with the vsce tool, then install it with code --install-extension or publish it. Private VSIX installs don't update on their own. Teams that ship often publish to the Marketplace instead and use the extensions.allowed setting to control which extensions run.
You build it once and publish it to Open VSX as well as the Visual Studio Marketplace. Cursor and VSCodium install third-party extensions from Open VSX, because Microsoft keeps its Marketplace for its own products. Open VSX needs an Eclipse account, a signed publisher agreement, and the ovsx command line tool.
You develop VSCode extension features for AI agents with the Language Model Tools API or an MCP server. The tools API lets the chat agent call your tool from the extension host, and the extension can also register your MCP server. Microsoft's docs now mark chat participants as deprecated, so we don't build new ones.
Yes, VSCode plugin development and extension development are the same work, because VS Code calls its plugins extensions. Both use the same Extension API, the same package.json manifest, and the same Marketplace. We say extension on your listing because that's the word developers see inside the editor.
You need a publisher ID, which can't be changed later, and a way for the vsce tool to sign in. Microsoft's docs say global personal access tokens retire on December 1, 2026, so we set up Microsoft Entra ID or GitHub Actions publishing. Listings also can't use SVG icons, and README images must load over https.
Only if it's built as a web extension, which runs in a browser worker. Developing VSCode extensions for the browser rules out Node.js modules and child processes, and extensions that add terminals or debuggers stay desktop only. If vscode.dev matters to your users, we plan for it from the first design.
You own both. The code sits in your Git repository, and the extension is published under your publisher ID and your Open VSX namespace. Plans include 30 to 90 days of support, and we hand over the build and release scripts so your team can ship updates on its own.
Saimul IslamFounder & CEO, DeveloperLookStill have questions?
Send a message or book a call with the team.
Free 30-min callGoogle Meet
Book a call
Book a free 30-minute call
In 30 minutes on Google Meet we walk you through how we would build it, how long it takes and what it costs. Then you get a written estimate.
Calendar not showing? Book on cal.com or send a brief.