When a custom tool makes sense
Most small businesses do not need custom software. A good website and the apps that already exist cover the job. A custom tool earns its place when you or your staff repeat the same manual steps every day, when two systems you rely on do not talk to each other, or when you have an idea for a product you want to sell.
I build these tools myself, from the first sketch to the store listing. I am based in Seekonk, Massachusetts, and work with businesses across the United States and Canada.
What I build
Chrome extensions. Tools that live in the browser and work on the pages your team already uses: checking, formatting, filling in, copying between tabs or adding a panel to a site you cannot change. I build on Manifest V3, the current version of Chrome's extension platform.
Wix apps. Functionality added to a Wix or Wix Studio site that the standard editor does not offer: a dashboard page for your staff, a custom widget, backend logic or a connection to another system. An app can stay private to your own sites or be listed in the Wix App Market for any Wix user.
Full-stack web applications. Browser-based tools with their own database, logins and admin screens, such as a quoting tool, a customer portal or an internal tracker.
AI-integrated tools. Software that uses a language model for one defined task, such as drafting, summarizing, classifying or auditing content, with a person reviewing the result.
Chrome extension, Wix app or web app: how to tell
The right kind of tool depends on where the work happens and who uses it.
The work happens on websites you do not control. A supplier portal, a social network, a search results page, a client's site. That points to a Chrome extension, because an extension can read and change the page in front of the user.
The work happens on your own Wix site or in its dashboard. That points to a Wix app. Wix apps can add dashboard pages, site widgets and backend logic, and can connect to Wix business tools such as eCommerce and Bookings.
Several people need to sign in and share the same data, or customers need to use the tool without installing anything. That points to a web application with its own database and logins.
The tool must work on a phone as well as a computer. A web application is the usual answer, because it opens in any browser.
You want to sell it. The store sets the form: the Chrome Web Store for extensions, the Wix App Market for Wix apps.
Some tools are two of these together, such as an extension that sends data to a web application. I say so at the scoping stage, because it changes the size of the job.
What scoping looks like
Scoping is a short written document, agreed before any code. It answers these questions.
What is the one job the tool does, in a sentence or two?
Who uses it, how often, and on which sites or screens?
What data does it read, what does it store, and where?
Which permissions or connections to other systems does that require?
What is in the first version, and what is on the list for later?
How will it be distributed: public listing, unlisted, private to a team, or installed on one site?
What does finished look like, and who signs off on it?
If an existing app already does the job, this is the point where I tell you. The proposal is free.
From idea to launch
Define the job. I write down with you what the tool does in a few sentences, who uses it and what "done" looks like.
Scope the first version. One core task done well. Extra features go on a list for later.
Prototype. You get a working version early to use on your own computer, so feedback is about real behavior and not a drawing.
Build and test. I finish the features, handle errors, and test on real pages and real data.
Privacy and permissions. The tool requests only the access it needs and keeps data on your device wherever it can.
Store listing and review. I prepare the description, screenshots and permission explanations, submit, and answer any reviewer questions.
Launch and updates. After release I fix bugs, ship updates and keep the tool working as browsers and platforms change.
How store review and permissions shape the design
Anything published on the Chrome Web Store is reviewed by Google before it goes live, and every update goes through the same review as a new item. Google says most reviews are completed within a few days and that some take longer. Broad site access, sensitive permissions, a large amount of code and code that is hard to read all lengthen review. Obfuscated code is not allowed at all. These rules are known in advance, so I design around them from the first day.
Narrowest permissions. Chrome Web Store policy requires an extension to request the narrowest permissions needed for its features, and forbids asking for access to cover features that do not exist yet.
Access on click where possible. The activeTab permission gives an extension temporary access to the current tab only when the user invokes it, and shows no warning at install. Where it does the job, I use it in place of access to every site.
Optional permissions. Access needed by one feature can be requested when the user turns that feature on, with an explanation at that moment.
A single purpose. Store policy requires an extension to have one purpose that is narrow and easy to understand. Unrelated features belong in a separate product.
All logic in the package. Under Manifest V3 an extension cannot load and run code hosted elsewhere. It can still call a web service for data, which is how an extension works with a server or an AI model.
Privacy disclosures. The listing has to state the single purpose, justify each permission, declare any remote code, disclose what data is collected and link a privacy policy. Google's Limited Use policy restricts user data to providing or improving that single purpose and bars selling it or using it for personalized ads.
An extension does not have to be public. The Chrome Web Store offers public, unlisted and private visibility, and a private item can be limited to named testers or a group. Wix apps follow a similar path: an app listed in the Wix App Market is reviewed before it goes live, and a private app is shared by install link and skips the public listing. I cannot guarantee that a store will approve a submission or how long it will take. That decision belongs to Google or Wix.
Adding AI features responsibly
A language model is useful for a narrow task with a person checking the result. It is a poor fit for anything that must be exact every time. When a tool uses AI, I build it this way.
One defined task, such as drafting a title, summarizing a page or sorting items into categories.
Content is sent to the model only when the user asks, and only the content that task needs. In Meta Monster, audits run in the browser and page content goes to a server only when you click the AI rewrite button.
AI output is shown as a suggestion that a person accepts, edits or rejects. It is never published or sent on its own.
The key for the AI service stays on a server, not inside the extension or page code where anyone could read it.
What is sent, and where it goes, is stated in the privacy disclosure.
The tool still does its main job when the AI service is slow or unavailable.
What maintenance after launch covers
Software that touches other people's platforms needs looking after. Maintenance is the work of keeping a finished tool working.
Fixing bugs that real use turns up
Updating the tool when a website it works on changes its layout
Keeping up with platform changes. Chrome's move from Manifest V2 to Manifest V3 is an example of a change that required extensions to be updated.
Keeping up with store policy changes and answering any notice from a store
Preparing and submitting each update for review
Updating connections to outside services, including AI models, when those services change
Products I built and maintain
These are my own products, and they are the best evidence of how I build.
Meta Monster is a Chrome extension that audits the page you are looking at for SEO and AI search readiness. It is free to install. Audits run in your browser on the live page, so you see results as you move from page to page.
LinkStyle Pro is a Chrome extension that formats LinkedIn posts. It collects no data and runs locally in your browser.
The Outdoor and Holiday Lighting Company template is a Wix Studio site template with 86 CMS-driven pages. More on that under Wix Studio templates.
One person, start to finish
The person who scopes the tool is the person who builds it, submits it and maintains it. If the tool supports a website I also build or manage, such as a custom site, it is all handled by one person.
Tell me what you want it to do
A short description is enough to start. Call or text 508-244-0403, email joshua@websitedesignma.com, or use the contact page. I reply within 24 hours and the proposal is free.