DEV Community: MSG.AI

The Hardest Part of Building a Chrome Extension Is Not the Code

MSG.AI — Sat, 29 Aug 2026 00:33:11 +0000

The first working version of a Chrome extension can be surprisingly quick to build.

A manifest defines the extension. A content script adds something to a page. A background worker coordinates events. A small interface exposes settings. Once the button appears and performs an action, the project feels close to completion.

That feeling is misleading.

While building MSG.AI for WhatsApp Web, I learned that the difficult work begins after the prototype succeeds. The hardest problems are compatibility, product boundaries, trust, and maintenance—not the first implementation.

A prototype only proves that the happy path exists

The first demo usually happens in one browser, one language, one account, and one page state.

Real users introduce everything the demo did not include:

Different WhatsApp interface languages
Narrow windows and unusual zoom levels
Slow networks and interrupted uploads
Accounts with different features enabled
Messages containing quotes, reactions, media, or unusual formatting
Tabs that reload halfway through a task
Browser extensions that modify the same page

A feature that works once is evidence that the idea is possible. It is not evidence that the feature is reliable.

The gap between those two statements contains most of the engineering work.

The platform can change without telling you

A third-party extension does not control the application it extends.

WhatsApp Web can update its page structure, rendering behavior, or internal modules independently. A selector that has worked for months may suddenly stop matching. An injected control may appear in the wrong place. A message operation may need additional validation after a platform change.

Traditional application code depends on APIs with documented contracts. A browser integration often depends partly on behavior observed from the current page.

That changes the maintenance model. You need monitoring, fallbacks, and a willingness to stop safely when the page no longer matches expectations.

Shipping the extension is not the end of integration work. It is the beginning of an ongoing negotiation with a moving surface.

Reliability sometimes means doing less

When an extension cannot confidently identify the active conversation or sending state, continuing is dangerous.

For a cosmetic feature, a misplaced button is annoying. For a messaging feature, acting on the wrong chat can have business consequences.

The reliable choice is often to stop, explain the problem, and ask the user to retry after the page is in a known state.

This can feel like a poor user experience because the software refuses to complete the task. But visible refusal is better than invisible misbehavior.

I have become more interested in safe failure than in demonstrations where automation always appears to succeed.

Product scope is harder than feature implementation

Once an extension is connected to a communication tool, the list of possible features becomes almost unlimited.

Translation suggests AI replies. AI replies suggest knowledge bases. Customer lists suggest CRM synchronization. Media attachments suggest cloud storage. Task history suggests analytics. Each addition appears adjacent to something already built.

The technical argument for expansion is usually convincing. The product argument may not be.

Every new feature competes for space in a small interface. It creates settings, support questions, privacy explanations, and new states that interact with existing features.

The hard question is not “Can this be implemented?” It is “Does this still belong in the same tool?”

For MSG.AI, I try to keep the boundary around work that benefits from happening inside WhatsApp Web: understanding a message, drafting a response, reusing approved material, controlling a customer messaging task, and exporting selected information.

That boundary is imperfect, but having one is more important than making it sound comprehensive.

Privacy language must match the actual data flow

Browser extensions operate close to personal and business data. Users deserve a precise explanation of what happens to it.

It is easy to say “your data stays local.” The accurate version needs more detail.

Task state and settings can remain in browser storage. Ordinary WhatsApp sending does not need to route messages through an extension vendor's server. But an AI translation requires the relevant text to be processed by a model provider when the user requests it. A Google Drive media workflow requires OAuth authorization.

These distinctions affect architecture, documentation, and interface copy.

Trust is damaged when marketing language is broader than the implementation. The privacy statement should describe the system that exists, not the feeling the product wants to create.

Distribution creates a second product

Publishing to the Chrome Web Store introduces another set of work.

Permissions need to be understandable. Store screenshots need to reflect the real interface. Descriptions need to avoid claims the product cannot guarantee. Updates must be packaged and reviewed. Support channels must exist for users who encounter a platform change before the developer does.

The extension itself is one product. The installation, onboarding, documentation, licensing, updates, and support experience form another.

A technically good tool can still fail if users do not understand why it requests a permission or what to do after installation.

Support reveals the real interface

Developers see the architecture they designed. Users see the moment where the product stopped helping.

A support question such as “nothing happened” may hide several different causes: WhatsApp Web was not open, the number was invalid, the page was still loading, an account limit was reached, or the platform interface changed.

Good error reporting is therefore part of product design, not a debugging convenience.

The error should tell the user what failed, what has already happened, and what action is safe to try next. For a multi-recipient task, it should also preserve enough state to avoid sending the same message twice after recovery.

These details rarely appear in launch screenshots. They determine whether someone trusts the tool after the first failure.

The code is still important—just not sufficient

None of this means engineering quality matters less.

Clear context boundaries, persistent task state, idempotent page injection, narrow permissions, and observable message flows make the rest of the product possible. The point is that code solves only the problems that have been framed correctly.

The longer I work on MSG.AI, the more the project feels like a series of judgment calls expressed through software:

What should be automatic?
What must remain reviewable?
What belongs in the browser?
What data needs to leave it?
When should the extension refuse to continue?
Which feature is not worth its maintenance cost?

Those questions do not have permanent answers. The browser changes, the platform changes, and user expectations change.

Writing the first version proved that the extension could exist. Maintaining its boundaries is what turns it into a product.

Project page: MSG.AI.

Are More AI Features Always Better? The “Smart” Ideas I Removed

MSG.AI — Sat, 29 Aug 2026 00:27:15 +0000

When AI features became easy to add, my product backlog grew very quickly.

Automatically translate every incoming message. Generate replies before the user asks. Detect customer intent. Choose a saved script. Send a follow-up when a conversation becomes quiet. Summarize every chat. Score every lead.

Each idea sounded reasonable in isolation. Together, they would have turned a small WhatsApp Web utility into a system constantly reading, predicting, and interrupting.

I removed or narrowed several of those ideas. The experience changed how I evaluate “smart” product features.

Automatic translation sounded better than on-demand translation

The first idea was simple: whenever a new message appears, translate it immediately.

That removes a click, which is normally a good thing. It also means processing every message, including messages the user already understands, one-word acknowledgements, emojis, addresses, product codes, and conversations that are not currently relevant.

Automatic translation creates cost, visual noise, and a larger data-processing surface. It can also make the original message harder to scan because every bubble suddenly contains twice as much text.

The narrower design worked better: place a translation action beside the message and remember the preferred language for the conversation. The user asks when translation is useful; the interface stays quiet when it is not.

One click remained. A large amount of unnecessary processing disappeared.

Pre-generated replies created false urgency

Another idea was to generate a suggested reply as soon as a customer message arrived.

This looked efficient in a prototype. In practice, it subtly changed the relationship between the user and the tool. A waiting suggestion made the user feel that the next step was to approve or edit the AI's answer, even when the better next step was to ask a colleague, check inventory, or leave the conversation unanswered for a moment.

The AI was not just saving writing time. It was setting the agenda.

I changed the flow so reply generation begins only after the user requests it. That small decision preserves a useful boundary: the person decides that a reply is appropriate, then the model helps draft it.

Intent detection was less useful than better organization

Automatically labeling a message as “pricing,” “shipping,” or “support” feels intelligent. It can also become another classification system that needs correction and maintenance.

For a small tool, the more immediate problem was often simpler: users could not find the reliable answer they had already written.

A searchable script library solved more of that problem than automatic intent detection. Users could save approved replies, organize them, and insert them when relevant. AI could then help adapt the wording without becoming the source of truth for prices or policies.

This feature looked less advanced. It was easier to trust.

Fully automatic sending failed the reversibility test

The most obvious “smart” feature was also the one I rejected most strongly: let AI read the conversation, decide on an answer, and send it without review.

The problem is not only model accuracy. It is reversibility.

An awkward draft can be edited. A wrong translation can be discarded. A message sent to a real customer cannot be unsent in any reliable business sense. Even if the interface offers a delete option, the recipient may already have read it or acted on it.

The higher the cost of reversal, the more important human confirmation becomes.

MSG.AI therefore produces editable drafts. The user remains responsible for the final message and the final click.

AI features have hidden interface costs

Developers often estimate an AI feature by its API call and prompt. The user pays additional costs that are harder to measure:

Another button to understand
Another loading state to wait for
Another result to verify
Another setting to configure
Another failure mode to interpret
Another category of data processing to explain

A feature can save thirty seconds of typing and add forty seconds of checking.

This is especially true in multilingual business communication. A fluent-looking answer feels finished even when it contains a subtle factual mistake. The better the writing quality becomes, the more deliberate the verification process needs to be.

I now use three tests before adding AI

I evaluate new ideas with three questions.

1. Is the model reducing creation work or making a business decision?

Drafting, rewriting, translating, and summarizing are creation tasks. Setting a price, promising a date, choosing a recipient, or deciding whether consent exists are business decisions.

AI can assist with both, but the second category requires much stronger controls and often should remain outside the feature entirely.

2. Can the user inspect the input and output?

A useful AI feature should make its context understandable. If the user cannot tell what conversation, saved knowledge, or language setting influenced the result, correcting a mistake becomes guesswork.

Visible context and editable output are more valuable than a mysterious confidence score.

3. What happens when the feature is wrong?

If the result can be discarded with no consequence, experimentation is inexpensive. If it changes a customer record or sends a message, the design needs confirmation, logging, and a safe failure state.

The question is not whether the model will ever be wrong. It will. The question is whether the product contains that error before it becomes an external action.

Removing intelligence can make a product feel smarter

After simplifying these features, MSG.AI did fewer things automatically.

It also became easier to understand. Translation appeared when requested. AI replies began with an explicit action and ended as drafts. Saved scripts held stable business information. Bulk tasks required recipient review.

The product felt calmer because it stopped competing with the user's judgment.

That is the paradox I keep returning to: the smartest product is not necessarily the one that predicts and automates the most. It may be the one that knows when to wait.

AI is most useful when it removes effort without removing agency.

Project page: MSG.AI.

After Building Bulk Messaging, I Became More Cautious About It

MSG.AI — Sat, 29 Aug 2026 00:19:30 +0000

Bulk messaging sounds like a straightforward productivity feature: write once, send to many people, and save a large amount of repetitive work.

That was how I saw it when I first built the workflow for MSG.AI. Once I had a working queue, configurable delays, progress tracking, and pause-and-resume controls, however, my view changed. The technical problem was manageable. The harder problem was deciding when the feature should be used at all.

The more reliable the tool became, the more important it felt to talk about restraint.

There are legitimate reasons to message a group of customers

Bulk messaging is often discussed as if it were synonymous with cold outreach. In real customer operations, that is not always true.

A business may need to tell existing customers about a delivery delay. A salesperson may need to share updated documents with people who requested them at a trade show. A support team may need to notify affected customers about a service interruption. A supplier may need to communicate a holiday schedule to active buyers.

These messages can be useful, timely, and expected.

The repetitive part is operational. Opening dozens of chats, pasting the same update, checking names, attaching the right file, and remembering who has already received it creates room for mistakes. A task queue can reduce that mechanical work.

But solving the mechanical problem does not answer the more important question: should this person receive the message?

Consent cannot be implemented as a sending interval

Developers like problems that can be represented as settings.

If sending too quickly creates risk, add a delay. If identical timing looks unnatural, randomize the interval. If a task is too large, split it into batches. If the user makes a mistake, add a preview screen.

Those controls are useful, but they do not create consent.

A five-minute delay between unwanted messages still produces unwanted messages. Random timing does not turn an unknown phone number into an existing customer. A preview can reveal an incorrect recipient list, but it cannot determine whether every recipient expects to hear from the sender.

This distinction became one of the most important product lessons for me: operational safeguards and permission are different layers.

The software can help someone send carefully. The sender remains responsible for deciding whether the communication is appropriate and lawful.

“Avoiding a ban” is the wrong primary goal

Questions about bulk messaging frequently begin with account restrictions: How many messages can I send? What delay is safe? How do I avoid being banned?

Those questions are understandable, but they frame the problem backward.

If the main objective is to find the maximum amount of unwanted outreach a platform will tolerate, no setting can make the workflow healthy. Platform limits change, recipient behavior varies, and account history matters. There is no universal number that guarantees safety.

A better set of questions is:

Does the recipient already know the sender?
Is the message connected to an existing request, order, or relationship?
Is the content useful to this specific audience?
Can the recipient easily ask not to receive future updates?
Would the message still feel reasonable if it were sent manually?

If those questions produce uncomfortable answers, slowing down the task is not the solution.

Good controls should make mistakes visible before sending

Once I stopped treating speed as the main product benefit, the design priorities changed.

The recipient review became more important than the import button. A small test send became more important than maximum throughput. Per-recipient results became more important than a large “completed” number.

The controls I now consider essential are deliberately ordinary:

Review the final recipient list before starting.
Preview personalized variables instead of assuming they are correct.
Send a small test before a larger task.
Allow the task to be paused or stopped immediately.
Record success and failure for each recipient.
Keep already-sent recipients visible when resuming.

None of these controls looks particularly impressive in a product demo. Together, they reduce the likelihood that one small mistake becomes hundreds of messages.

Personalization is not the same as relevance

Replacing {name} with a contact's first name is easy. It is also often described as personalization.

But a message does not become relevant simply because it begins with “Hi Maria.”

Real relevance comes from segmentation: customers waiting for a shipment should receive a shipment update; people who requested a catalog should receive the catalog; inactive leads should not automatically be treated like active buyers.

The best customer list is usually not the largest list. It is the smallest group for whom the message makes clear sense.

This is another place where a tool should avoid pretending to know more than it does. MSG.AI can import recipients and substitute variables. It cannot infer the entire history and expectation behind every relationship. The person preparing the task must provide that judgment.

Responsible messaging is also better product strategy

There is a practical business reason to discourage careless use: low-quality sending damages every part of the product ecosystem.

Recipients become less willing to open business messages. Accounts face more restrictions. Support requests become dominated by users asking why aggressive campaigns failed. The product gets associated with spam rather than useful customer communication.

Optimizing only for the number of messages sent may produce impressive short-term metrics, but it creates poor long-term incentives.

I would rather measure whether a task was controlled, expected, and useful than whether it reached the largest possible list.

What building this feature changed for me

Before implementing bulk messaging, I thought mainly about eliminating repetitive clicks. After implementing it, I thought much more about the consequences of eliminating those clicks.

Automation multiplies both good decisions and bad ones. When the underlying communication is valuable, it saves time. When the underlying decision is careless, it scales the mistake.

That is why I no longer describe bulk messaging as a simple “send more” feature. In MSG.AI, I want it to be a controlled workflow for communicating with people who already expect to hear from a business.

The distinction may sound less exciting than unlimited outreach. It is also the difference between a productivity tool and a spam tool.

More about the project: MSG.AI.

Why I Built a Browser Extension for WhatsApp Web

MSG.AI — Sat, 29 Aug 2026 00:13:11 +0000

I did not start building MSG.AI because I had discovered a grand new AI opportunity. It began with a much smaller problem—one that kept repeating every day.

A message arrives in another language. You copy it into a translation tool, read the result, write a reply, translate that reply, and paste it back into WhatsApp. When a customer asks a familiar question, you search through a document or an old chat for the answer you used last time.

Each step takes only a few seconds. None of them looks important enough to justify a new product. But when someone handles dozens of international conversations a day, those small interruptions fragment the entire workflow.

That was the starting point for MSG.AI.

Why a browser extension instead of another support platform?

My first instinct was to build a standalone web application with its own inbox, contacts, translation tools, and customer management features.

I abandoned that direction fairly quickly.

People were already working inside WhatsApp. Asking them to adopt another inbox meant another login, another data sync, and another interface to keep open. The product might have looked more complete, but it would also have introduced the exact kind of context switching I was trying to remove.

A browser extension offered a simpler approach: leave the conversation where it already lives and add the missing tools around it.

Customers remain in the existing chat list. Messages still go through the current WhatsApp Web session. The extension handles supporting tasks such as translation, reusable replies, controlled messaging tasks, and exports.

I think of it as adding a small workbench next to the desk people already use—not asking them to move into a new office.

Bulk messaging came first, but translation became more important

The earliest version focused mostly on sending customer updates in batches.

There are legitimate reasons to notify a group of existing customers: order updates, delivery notices, holiday schedules, missing documents, or trade-show invitations. Opening every conversation and pasting the same information is slow, and it is easy to miss someone.

So I built a task queue, configurable intervals, progress tracking, and pause-and-resume controls.

But after watching the workflow more closely, I realized that bulk messaging was occasional. Translation happened every day.

The product gradually shifted toward in-chat translation: read a translated version next to an incoming message, then review the translation of a draft before sending it. The goal was not to make communication fully automatic. It was simply to avoid leaving the conversation whenever a message needed to be understood.

That changed how I think about a “core feature.” It is not always the most impressive feature in a demo. Sometimes it is the small button a user reaches for without thinking, many times a day.

AI replies should stop before the send button

Adding an AI reply feature was technically straightforward. The harder decision was where the automation should end.

One option was to read each new message, generate an answer, and send it automatically. That makes for a compelling demonstration, but it is uncomfortable in a real customer conversation.

Prices, delivery dates, payment terms, and after-sales commitments have actual business consequences. An AI model may write a confident sentence without knowing whether the person using it is allowed to make that promise.

I chose a more conservative design. MSG.AI can use the current conversation and business information deliberately saved by the user to produce a draft. The draft goes into the editor, where a person can review and change it before deciding whether to send.

It is less magical than full automation, but it is closer to how real work gets done.

The useful role for AI here is not to impersonate a salesperson. It is to reduce the number of times that salesperson has to begin with an empty text box.

Faster bulk sending is not necessarily better

After building the bulk-messaging workflow, I became less interested in promoting speed or volume as product benefits.

Bulk communication is not automatically spam. Order notifications and service updates can be useful and expected. But the moment recipient consent is ignored, the same feature turns into an abuse tool.

The extension can introduce delays, show the final recipient list before sending, and allow a task to be paused. Those controls help a person operate more carefully. They cannot create consent, guarantee that an account will never be restricted, or turn an unwanted message into a welcome one.

A tool can improve operational control. It cannot make the ethical and legal decision for its user.

That is why I want MSG.AI to serve communication with people who already expect to hear from a business—not the collection and blasting of unknown phone numbers.

“Local-first” needs a precise definition

Messaging tools inevitably touch sensitive information, so another important design question was which data truly needed to leave the browser.

Messaging tasks, recipient lists, and activity records are primarily stored locally. Sending an ordinary WhatsApp message does not require routing that message through an MSG.AI server first.

But local storage should not be misrepresented as “everything works completely offline.” When a user actively requests an AI translation or reply, the context required to produce that result must be processed by the selected model service. Accessing media from Google Drive also requires explicit authorization.

Explaining those boundaries clearly feels more useful than adding a vague “privacy protected” badge to a landing page.

The hardest part is not implementing the features

The code behind a browser extension is not mysterious. The more difficult part is depending on a web interface that keeps changing.

When WhatsApp Web changes its page structure, an integration that worked yesterday may need to be adapted. Different languages, window sizes, network failures, and account states create a long list of edge cases.

There is also a product-design cost to every feature. Developers are naturally tempted to ship something simply because it is technically possible. That is how a small utility turns into a crowded sidebar nobody wants to learn.

While building MSG.AI, I keep returning to three questions:

Does this problem happen repeatedly in real work?
Does it need to be solved inside WhatsApp Web?
Will the feature save more effort than the complexity it introduces?

If I cannot answer at least two of those questions clearly, the feature probably should not be added yet.

A small tool does not need to reinvent the workflow

MSG.AI is still an independent Chrome extension. It is not affiliated with WhatsApp or Meta, and it is not a replacement for a full CRM or an official customer-support platform.

Its purpose is narrower: for people who already spend much of their day communicating with international customers in WhatsApp Web, can we reduce tab switching, repeated writing, and manual organization without removing the human decision before a message is sent?

I do not know how large the product will eventually become. But building it has reinforced one idea for me: a useful tool does not always need to invent a completely new way of working.

Sometimes removing a few points of friction from an existing workflow is enough.

You can learn more about the project at MSG.AI.

How a WhatsApp Web Extension Interacts With the Chat Interface

MSG.AI — Sat, 29 Aug 2026 00:12:48 +0000

When people see a browser extension add translation controls, a side panel, or a sending workflow to WhatsApp Web, a common question is: how does the extension actually interact with the page?

The short answer is that a modern Chrome extension is split across several execution environments. No single script should be responsible for the interface, persistent state, task scheduling, and access to the page at the same time.

This article explains the architecture at a practical level without depending on private implementation details that may change whenever WhatsApp Web changes.

A browser extension does not run as one program

The simplest mental model is to divide the extension into four parts:

The extension interface
A background service worker
A content script attached to WhatsApp Web
A small bridge running in the page's own JavaScript context

Each part has a different job and a different level of access.

The extension interface is what the user sees: forms, task history, translation settings, saved scripts, and media selection. It should focus on interaction rather than long-running work.

The background service worker coordinates tasks and stores state. It can receive a request from the interface, keep track of progress, and send commands to the correct WhatsApp Web tab.

The content script lives alongside the webpage. It can inspect the rendered document, inject controls, and communicate with the extension runtime. Chrome isolates it from the page's own JavaScript environment for security.

The page bridge exists because isolation is sometimes a limitation. A content script can see the DOM, but it does not automatically share the same JavaScript objects as WhatsApp Web. When deeper page integration is required, a carefully scoped bridge can exchange explicit messages between the isolated extension world and the page world.

Why not put everything in the content script?

It is tempting to keep the entire feature in one file because the content script is already attached to WhatsApp Web.

That approach becomes fragile quickly.

The script would have to render the interface, observe the page, manage tasks, store data, process media, handle retries, and survive navigation changes. When one part fails, it becomes difficult to determine whether the problem came from the UI, the task state, or the page integration.

Separating responsibilities creates clearer failure boundaries:

The interface validates user input and displays state.
The background worker owns task progression.
The content script owns visual integration with the current page.
The page bridge performs only the operations that require page-context access.

This separation does add message passing, but that complexity is easier to reason about than a single script with hidden dependencies everywhere.

The side panel and the chat page are separate surfaces

MSG.AI adds a workspace next to WhatsApp Web instead of replacing the page.

The panel is useful for operations that need space: reviewing recipient lists, editing reusable scripts, viewing task progress, or choosing media. Small actions, such as translating one message, are more natural next to the message itself.

That creates two interface surfaces that must remain synchronized.

For example, changing a target language in the panel should affect the translation action beside the current conversation. Pausing a task should update both the background state and the progress shown in the panel. If the user reloads WhatsApp Web, the interface should restore from persistent state instead of inventing a new task.

The lesson is that DOM injection is only the visible part of the work. State coordination is usually harder.

Page changes are the main source of fragility

WhatsApp Web is a living application. It changes without following the release cycle of a third-party extension.

CSS class names can change. Buttons may move. The composer can be rebuilt. A message bubble may render differently for media, quoted replies, reactions, or different account features.

An extension that depends on one long CSS selector will eventually break.

More resilient integrations use several signals:

Semantic attributes such as roles and labels when available
Stable structural relationships rather than exact class names
Mutation observers to detect interface changes
Idempotent injection so the same button is not added twice
Narrow fallbacks for known layout variants
Feature detection instead of assuming every account has the same UI

None of these techniques makes the integration permanent. They make failure easier to detect and repair.

Communication between contexts should be explicit

Once several extension contexts are involved, message design matters.

Commands should describe intent rather than expose implementation details. PAUSE_TASK is easier to maintain than a command that tells another context which timer variable to modify. Responses should include a clear success state and a useful error rather than assuming silence means completion.

A typical flow might look like this:

The user creates a messaging task in the panel.
The panel validates the data and sends the task to the background worker.
The worker persists the task and selects the next recipient.
The worker asks the content script in the WhatsApp tab to perform one action.
The content script exchanges a narrowly defined request with the page bridge.
The result travels back to the worker, which updates progress and schedules the next item.

This looks verbose compared with calling one function. The benefit is that each boundary is observable. When a task fails, the extension can identify where it stopped.

Local storage is useful, but it is not a database server

Chrome's extension storage is well suited to settings, drafts, task metadata, and moderate history.

It is less suited to unbounded chat archives or large media files. Those need size limits, cleanup strategies, or an explicitly authorized external destination such as Google Drive.

The storage model should also distinguish between recoverable state and disposable cache. A user should not lose a paused task because a translation cache was cleared. Similarly, old cached results should not remain forever simply because the task history is important.

Data boundaries become easier to explain when the internal model already separates these categories.

The page integration should fail safely

A web integration will eventually encounter a page version it does not understand.

The worst response is to continue as if nothing changed. A sending tool that selects the wrong chat is more dangerous than one that stops and reports an incompatibility.

Safe failure means validating the active conversation, checking that the intended input is present, confirming the result of an operation, and stopping when an assumption no longer holds.

In other words, uncertainty should reduce automation rather than increase it.

What this architecture taught me

Building a WhatsApp Web extension is less about inserting a button and more about negotiating boundaries: between the browser and the page, between temporary UI and persistent state, and between automation and user control.

The architecture is not interesting because it is unusually complex. It is interesting because the complexity appears exactly where separate systems meet.

Keeping those seams explicit has made MSG.AI easier to debug and safer to evolve—even though no third-party integration with a changing web app can ever be completely maintenance-free.

Project page: MSG.AI.