Chrome extensions, built when the browser is genuinely the right place for the tool.
I build Chrome extensions for businesses that need a function to live where the work already happens. One of mine is live on the Chrome Web Store and another is public on GitHub, source and build included, so there is something to check before you commission anything.
An extension earns its place when the alternative is asking somebody to leave what they are doing, open a tab, sign in, and come back. That round trip is the cost. The extension removes it.
That is the whole test. If a task is frequent, browser-based and currently manual, an extension is probably right. If it is occasional, or belongs in an application, I will say so before you spend anything.
I do not build extensions as marketing objects. They are small pieces of software that sit in somebody’s toolbar and get judged every day, which is a harder standard than a landing page.
Two things you can check before hiring me
SoftGlaze Screen Recorder is live on the Chrome Web Store. It passed Google’s review, it installs, and you can try it in about a minute. View the listing →
ProjectPulse is the one whose source is public. The repository ships extension-source, extension-build and extension-premium, so you can read how an extension of mine is actually written and packaged. Read the source →
Those two prove different things, and I would rather separate them than blur them together.
The Web Store listing shows I ship and get through review. The repository shows the standard of the code. The recorder’s own source is not public, and ProjectPulse is not on the store, so I am not going to imply that one covers the other. Extensions are also a smaller part of my work than WordPress or WooCommerce, which is worth saying plainly rather than implying a specialism I do not have.
- a task that repeats every day
- a function that belongs beside the work
- a workflow that needs a second tab
- a small automation with a clear owner
- an internal tool a team will keep using
The kinds of extension worth commissioning
Most useful extensions fall into a few shapes. These are the ones I take on, and each is scoped to a specific job rather than a feature list.
Typically that means:
Every one of them starts from a task somebody already does by hand.
Why the browser is often the right surface
Plenty of businesses build the dashboard, the app and the back end, then ask people to travel to them. For work already happening in a browser tab, that travel is pure overhead.
The cost of a round trip
Leaving the flow, opening a tab, signing in and returning is a small tax, but it is charged every single time. Multiply it by daily use and it stops being small.
What an extension removes
When the browser is where the work already happens, an extension can:
- cut a repeated task to one click
- keep the tool beside the work
- remove the sign-in round trip
- make an occasional action habitual
What I do, and what I do not
I build Chrome extensions. I do not build for Safari or Firefox, and I do not maintain cross-browser parity.
If yours needs to ship on three browsers with matching features, I am the wrong choice, and I will tell you in the first conversation rather than the third invoice.
I also will not build an extension where a bookmark, a keyboard shortcut or fifty lines of script would do. Selling software nobody needs is an easy way to earn once and lose the relationship.
What I will do is this:
scope it against the actual task, hand over the repository and the store listing, and tell you honestly whether it deserves to exist at all.
> What I ask before quoting
- ? What task is this replacing, and how often?
- ? Who uses it, and on what?
- ? What happens today without it?
- ? Why the browser rather than the application?
- ? Who maintains it after handover?
- ? Is it worth the store review and the upkeep that follows?
What I hold every extension to
An extension is judged in a toolbar every day, so the bar is different from a page somebody visits once. useful, quiet and dependable.
It solves a real task
Not a demonstration of what the API can do. Something a person currently does by hand.
It belongs in the browser
If it would be better as a script, a shortcut or a page, it should be one of those instead.
It stays out of the way
No permission it does not need, and no interface where one button would do.
It stays light
An extension that slows the browser gets uninstalled, whatever else it does.
It is obvious
If something used daily needs instructions, the interaction is wrong, not the user.
You own it
Repository, build, store listing and documentation transfer to you, the same as every project here.
The situations where an extension actually pays
People usually raise an extension when one of these is true. The honest answer is not always yes.
Frequent, manual, already happening in a tab. This is the clearest case there is.
The capability exists, but reaching it costs a round trip every single time.
Not a system. A narrow tool that removes one specific piece of friction.
Worth doing only where the underlying product is already used regularly.
This is where the answer is usually no, and I would rather say so early.
What you are actually buying
Not an extension. A task that stops costing what it used to.
A good extension does not add a feature. It moves an existing function to where the work already is.
What comes with it:
- source you can read and own
- a build you can publish yourself
- the store listing in your name
- documentation written as it was built
- no permission beyond what it needs
- an honest answer on whether to build
- no lock-in of any kind
How an extension project works
Extensions live close to real behaviour, so the scoping matters more than the code.
1. Understand the task
I watch, or have described to me, what people actually do now, including the parts annoying enough that they have already invented a workaround.
2. Decide whether it should exist
A real stage with a real no. If a shortcut solves it, I say so before either of us spends money.
3. Shape the interaction
One clear job, the smallest interface that does it, and the least permission that job requires.
4. Build it
Written to be handed over: readable source, a repeatable build, and no dependency you cannot remove later.
5. Publish and hand over
Store submission, review, listing, then repository and credentials transferred to you.
6. Change it when the work changes
Optional, never a condition. Workflows move, and an extension that does not move with them gets uninstalled.
“Good browser tools are shaped around what people already do, not around what the API allows.”
Who this suits
An extension project here is a good fit if you:
- have a browser task that repeats daily
- want a narrow tool, not a system
- need the source and listing in your name
- would rather be told no than sold a build
- are happy with Chrome only
- accept it needs occasional upkeep
It is a poor fit if you need cross-browser parity, a large feature surface, or a launch date earlier than the store review can realistically allow.
Why bring this to SoftGlaze
Because you can read my extension source before deciding, which is not something most people offering this work can say.
You get the same terms as every other project here: one developer, direct contact, code you own outright, and a straight answer about whether the thing is worth building at all.
An extension is a small commitment to make and a long one to keep. I would rather scope it honestly at the start than hand you something that quietly stops being used.
If a browser task is costing your team time, let’s look at whether an extension is the right fix.
Tell me what the task is and how often it happens. If an extension is the wrong answer, I will say so and point you at the right one.