DEV Community: Hit Subscribe

Is 1Password Secure? A Complete 2025 Risk Assessment

Guillermo Salazar — Thu, 25 Sep 2025 14:37:00 +0000

Long gone are the days when you could keep passwords written in a notebook. Have you counted how many passwords you need to juggle? Think bank accounts, your car payment, a few streaming services, and more email addresses than you care to remember.

But the count doesn’t end there. You also have a professional life, complete with multiple email addresses, an intranet, and your preferred HR platform.

On average, experts have indicated that Americans have to juggle a whopping 150+ passwords.

Have you tried keeping track of all of them with pen and paper, let alone keeping them unique and secure? Enter the subject of today’s review: 1Password.

What Is 1Password?

1Password is a password manager, letting you conveniently and securely store your digital assets. Along with multi-factor authentication, password managers have become staples in today’s world.

In this day and age, a password manager is a digital safe box in which we trust our login information, digital copies of important documents, and your cloud provider's root keys, among other things.

Professional users store their company’s information, their team's passwords, and external agencies. Individuals will share everything from their passwords to medical records, credit card numbers, and bank accounts, emptying their entire digital footprint. Why wouldn’t you? It’s convenient, quick, and secure. Right? Keep reading; we’ll find out.

Platform Support and Features of 1Password

If storing all that information with varying degrees of security, encryption, and protection isn’t enough, password managers need to integrate themselves into the final user’s day-to-day digital life.

1Password excels at adapting to the user’s ecosystem with excellent out-of-the-box offerings, including cross-device syncs, autofills, vaults for organizing information, and more, all in a modern and clean UI.

1Password has clients for all major operating systems: macOS, Linux, and Windows, as well as browser extensions for Firefox, Safari, Chrome (which, of course, includes Chromium-based browsers like Brave), and Edge.

Since your digital ecosystem extends to your pocket, it also has official apps for Android and iOS. Bulletproof? Stay tuned.

Is 1Password Secure?

1Password offers digital security through a set of key distinctive pillars through the “1Password security model.” Some of its unique points include:

AES-256-bit Encryption

AES-256-bit encryption, which ensures that your data (think of it as a digital vault) is encrypted on your local device and remains secure until it’s transmitted. Data is secured and obscured at rest and in transit.

Two-key Derivation

1Password uses not only the account password but also a secret key. Both are needed to access the account. They claim that not even their employees can see the data without both, and none of them are accessible by 1Password themselves.

Metadata Encryption

Beyond the passwords and users, 1Password encrypts metadata (URLs, titles, texts) so that a malicious actor wouldn’t know the difference between credit card details and the latest dinner recipes.

Alongside those points, 1Password also advertises a bug bounty program, as well as transparent and frequent security audits conducted by recognized members of the cybersecurity community.

Let’s Talk Compliance

As one of the key players in the password manager industry, 1Password is up to date with the latest compliance standards, including SOC 2, GDPR, and ISO. All checked. Your CTO must be happy. But it’s not the end of the story.

Certifications don’t necessarily mean safety. All you need is a user installing the wrong version on one of the 1,000 geographically distributed nodes. Yes, you’re ‘compliant,’ but you might be leaking data without noticing.

According to this report, more than 75% of SaaS applications pose high or moderate risks to businesses.

As security professionals and compliance officers know, this is typically what organizations get wrong and where Spin.AI’s platform shines: it verifies actual versions and permissions across your entire SaaS footprint.

Versioning & Updates

Security isn’t a static concern. That’d make things too easy. Even solid applications like 1Password can be subject to the dangers that come from rushed software and hijacked updates. Yesterday’s fortress is now a weak point in your organization.

Take Cyberhaven’s incident (December 2024): A trusted name in cybersecurity had its browser extension exploited by an attack campaign targeting Chrome extension developers. Cyberhaven wasn’t the only victim.

The security community also reported on the RedDirection campaign, a comprehensive network of 18 well-known apps available in both the Chrome and Edge extension stores, which were targeted to hijack and redirect users’ traffic.

What Does This Mean for 1Password Users?

What does this all mean for 1Password’s users like you or me? Every time there’s an update, browser extensions update automatically across all browsers and clients. The convenience of the auto-update can also mean a compromised piece of software could slip into your day-to-day without notice.

That’s why it’s key to ask not just “is it secure?” but also “what version is the app on, and what permissions is it allowed to have?” And to answer those questions with data instead of blind trust, you can rely on tools like this application risk assessment. It’s a great way to check the version you’re running and whether it behaves like it should.

Permissions and Trust Issues

For any application to function correctly, it must be able to perform specific actions on your behalf within your environment and on your devices.

These permissions are not limited to filling out forms on your browser; 1Password requires access to your clipboard, browser sessions, and browser storage. For Edge, it needs access to particularly high-risk areas, including the alarms and privacy APIs, as well as your tabs and downloads.

I didn’t memorize all of those across different platforms and extensions, of course. I ran a quick browser extension risk assessment:

Being able to view 1Password across all platforms and versions makes it easy to identify where the risk lies.

I was interested in how 1Password performs on Edge, and my trust issues kicked in. It really makes you wonder, “Who approved this?”

Like I said above, even great software from security experts can go from a fortress to swiss cheese, and it can happen right in front of your eyes. You might be wondering: “Where does 1Password stand on that scale?”

To date, 1Password has never had a vault-level breach. That’s a one-up above other solutions that have been compromised at deeper levels. But “no breach” doesn’t translate to “risk-free” directly. Researchers were able to uncover a clickjacking flaw (August 2025) in 1Password’s browser extension. However, it was quickly addressed.

Sometimes the vulnerabilities don’t have to be in the encryption or security model of the application, but rather in the apps and extensions that surround it. The vault-level data is solid, but malicious actors can target the distribution to end-users.

Real Talk

Is 1Password safe? Yes, at the vault level.

However, the vulnerabilities for any app lie in the versions, extensions, updates, and end-device clients wrapped around them. Clickjacking flaws, overreached permissions, or extension hijacking can introduce risks without requiring an attack at the vault-level.

Ultimately, the real question isn’t “Is 1Password safe?” It’s “Is your version of 1Password safe?”

For Individual Users

If you’re an individual, the smart move is to check what’s actually running on your digital ecosystem with tools like this application risk assessment.

For Organizations

If you’re responsible for your organization’s security, the stakes are high. Even seemingly small gaps—like overlooked browser extensions or misconfigured SaaS settings—can introduce meaningful risk. Conducting a structured assessment helps bring those issues to light so you can address them before they’re exploited.

Depending on your environment, this might mean using built-in tools in platforms like Google Workspace, leaning on third-party assessments for extensions and SaaS apps, or setting up compliance dashboards for continuous monitoring. The goal is the same: gaining visibility into where vulnerabilities exist, then building the processes and defenses to keep them under control.

If you’re interested in knowing where your SaaS environment stands, a demo of Spin.AI’s platform lets you see how to surface risks and enhance your defenses through compliance dashboards, continuous monitoring, and real-time tracking.

Is the ChatGPT Extension Safe? Assessing the Risks in 2025

Eric Boersma — Wed, 24 Sep 2025 15:54:34 +0000

At the time of writing, ChatGPT is the sixth most popular website in the world. Billions of people every month visit ChatGPT for any number of reasons. Many use it to improve their work, some use it as a conversational companion, and others still have it help to complete school assignments. It should come as no surprise that extension developers have rushed to fill the market with browser extensions that integrate with the popular LLM.

But whether you’re an enterprise user or an individual, adding a ChatGPT browser extension (aka plugin) raises an important question: Is this safe? Savvy internet users know that popular new computer capabilities also attract malicious developers who are more than happy to offer you a deal: install their extension, and they’ll get access to what they seek. This can include everything from corporate SaaS credentials to full control of your computer.

With that in mind, let’s take a dive into the deep end of ChatGPT extensions. We’ll evaluate the landscape, give you the tools you need to inspect any ChatGPT extension that your team might want to use, and help you make a decision about whether or not that extension is safe.

Which ChatGPT Extension?

If you’re trying to figure out whether “the” ChatGPT extension is safe, you first need to answer: Which ChatGPT extension? Here’s the thing: Anyone can put an extension on the browser app stores. That’s even more true with a tool like ChatGPT, where the true functionality lives on the remote website, meaning that any extension you might download is likely to be a wrapper around a basic API, and may even have man-in-the-middle architecture.

The reality of ChatGPT extensions right now is that they’re kind of like the Wild West. If you load up the Chrome Extension Store and search for ChatGPT, the responses are effectively endless. What this means is that if you have someone asking if they can use a ChatGPT extension, you first need to determine just what extension they’re looking to use. Chances are, if you’re managing an enterprise team, you probably have requests to use a dozen ChatGPT extensions or more.

Making things even more complicated, attackers can compromise a developer’s account and ship compromised versions, even when previous versions were safe.

Before you can answer whether or not it’s safe to install an extension, you need to nail down the details. Once you’ve done that, you can move on to the next step of the process: evaluating the extension(s) to determine how safe they are and review all potential risks.

How Should I Evaluate an Extension?

If you want to take a shortcut, this Free App & Extension Risk Assessment will give you the rundown on hundreds of thousands of extensions available on browser app stores. But let’s take a look at the key attributes you should consider when evaluating any kind of browser extension.

Permissions

The first question that you should answer with any browser extension is the most obvious one: What can the extension do? When a developer registers an extension on a browser store, they need to request permissions for what the app can do and what sites it can operate on. Understanding both of those parameters goes a long way toward understanding how risky an extension is. In cases where an extension is malicious, it may take actions without consent. Meaning, you can read the stated permissions an extension is requesting, but know that you still have to be able to trust the developer who created it. That will require a little sleuthing, but it’s a common deception and worth doing to protect your corporate environment.

External Communications

Step two in understanding the risk an extension poses is understanding what external sites an extension can talk to. If you’re using this application risk assessment, you can see a rundown of which websites an extension talks to in the course of operations.

Obviously, with any ChatGPT extension, it’ll need to make calls to some external websites. After all, ChatGPT isn’t hosted on the user’s local computer. Any other website connections should be evaluated carefully. This may include remote C2 servers capable of command-and-control actions that can be changed at will by whomever controls those servers. As with the previous tip, it’s good to keep in mind that you may or may not see this spelled out in the extension’s description. So, make sure you trust the developer.

Developer Reputation

While a developer’s reputation is no guarantee of the quality of an extension, it’s a good proxy. An extension from Google itself is much more likely to be reputable than one from an individual developer. An extension that is backed by a reputable company is more likely to respond to any security vulnerabilities than one helmed by a small team.

Again, none of this is a guarantee. You shouldn’t simply assume that just because an extension comes from a reputable developer, it’ll be safe. But it’s a good first step.

Developer Jurisdiction

Aside from understanding the background of the developer, it’s also important to understand where that developer is headquartered. If you live in the same country, it’s much easier to seek legal redress if a developer ships an extension that causes your company harm. If you’re in the United States, and the developer is somewhere like Russia, it’s unlikely that you’d ever have a chance to meaningfully redress any damages, whether their behavior was intentional or not.

If they are using a free email domain and provide any information that is inaccurate, you may have a hard time nailing down where they are physically located.

Non-Traditional Risks Related to LLM Extensions

When we’re talking about ChatGPT, extension risks expand beyond the traditional footprint. This is because, by definition, any LLM extension is going to execute untrusted code by the nature of its function. This might seem unintuitive, but take a moment to think about it.

The nature of LLMs is that they take natural text and process that, returning some output. When you consider that behavior, the LLM serves as an interpreter, and that natural language is now a computer program. Meaning, the input has been processed somewhere and may even have been added to its semantic core.

That kind of capability is extremely powerful. But it also exposes the user to an extremely broad range of threats, because any text that you feed into the LLM can instruct the LLM to take actions. If the user isn’t carefully examining every instruction, that might lead to the LLM taking actions that the user doesn’t intend.

In fact, security researchers are already identifying scenarios where simply asking an LLM to “summarize” a webpage can lead to an LLM taking malicious action based on nothing more than some hidden text on the page itself. Connecting an LLM to your browser, which you use to access your most sensitive data, presents substantial risks that are inherent to the technology.

The Bottom Line: Is the ChatGPT Extension Safe?

So, let’s break it down to brass tacks. Is the ChatGPT extension safe? It’s hard to say, in the absence of more information. There are dozens of ChatGPT extensions, and it’s impossible to provide a rundown of all of them in this space. Even if we tried, it’s likely that by the time you reached the end of the list, you’d find that there were new extensions to evaluate.

So, for a specific extension, the best bet is to find it on Spin.AI’s application risk assessment and look through a detailed breakdown to determine whether the extension meets your standards.

But at a broader level, the answer to the bigger security question is that the extension you’re looking at probably shouldn’t be trusted. That’s simply a reality of LLM security at the moment. These are powerful tools that unlock myriad new interaction patterns with powerful computers. But those new interaction patterns demolish existing security paradigms, and malicious users are more than happy to take advantage of these new holes.

The reality is that the landscape around these tools is shifting all the time. An extension that’s a bad idea today might be perfectly fine after a few tweaks in a couple of months. It’s important to stay on top of these things.

Is Grammarly Safe? A Complete Explanation of Risks

Bravin Wasike — Fri, 19 Sep 2025 15:24:31 +0000

Grammarly is one of the most popular writing assistants on the market today. Millions of users rely on it to check grammar, spelling, and tone across their communications. But a question often arises: Is Grammarly safe?

This isn’t just an idle curiosity. Users like IT admins, compliance teams, and privacy-conscious professionals want to know whether Grammarly poses risks to their sensitive data. They also have concerns about organizational compliance and overall cybersecurity.

The short answer is that Grammarly is generally safe, but there are nuances. Like any cloud-based SaaS application or browser extension, its safety depends on how it’s used, how versions are managed, and how risks are mitigated.

In this article, we’ll break down everything you need to know about Grammarly’s data collection, security measures, compliance risks, history of incidents, and how to protect yourself. We’ll also show you how to evaluate Grammarly, or any SaaS app or extension, objectively.

What Is Grammarly, and How Does It Work?

Grammarly is an AI-powered writing assistant delivered as a web editor, desktop apps (Windows/macOS), mobile keyboards (iOS/Android), and browser extensions (Chrome, Edge, Firefox, Safari).

Once installed, Grammarly can check everything you type across supported platforms, including

Emails in Gmail or Outlook.
Documents in Microsoft Word and Google Docs.
Social media posts and blogs.
Messaging applications.

When you type in a supported app, Grammarly analyzes the text to suggest grammar, spelling, clarity, tone, and rewrite improvements. Depending on your settings and plan, it can also provide plagiarism detection, brand tone, and team style guides.

How Grammarly Processes Text

Client-side capture: The extension or app identifies editable text fields in the page/app you’re using.
Secure transmission: Text snippets and context are transmitted to Grammarly’s cloud for analysis (scope depends on settings and exclusions).
Model inference: Grammarly’s NLP/LLM models analyze the text for grammar, clarity, tone, and other checks (e.g., plagiarism for subscribers).
Return suggestions: Suggestions appear inline; you accept or ignore them.
Telemetry & diagnostics: Usage/diagnostic metadata may be collected to improve performance and reliability.

This workflow inherently involves transmitting what you type to a third-party service. So you must decide which data is appropriate to route through Grammarly and which is not.

The Versioning Problem: Why Each Grammarly Version Needs a Separate Review

One of the biggest overlooked risks with SaaS apps and browser extensions like Grammarly is versioning.

Apps like Grammarly frequently update their software. While updates are meant to patch bugs or introduce features, they can also unintentionally or maliciously introduce risks. For example,

A compromised update could insert malicious code without the vendor’s immediate knowledge.
A third party could publish a fraudulent extension that looks identical to Grammarly but behaves differently.
Even legitimate updates may request broader permissions that create new risks.

This is not theoretical. In December 2024, Cyberhaven, a respected cybersecurity company, suffered a massive breach when attackers compromised their software update process. Customers who dutifully updated their tools were unknowingly opening a back door for attackers.

That’s why it’s critical to evaluate the specific version of Grammarly being deployed, not just “Grammarly” as a whole.

Action Plan

Inventory versions in your environment (per browser and OS).
Assess each version with Spin.AI’s application risk assessment.
Track change logs and permission diffs between versions.
Pin or stagger updates for high-risk groups. Pilot before organization-wide rollout.
Continuously monitor for reputation changes or new findings.

A Breakdown: What Data Does Grammarly Collect?

Grammarly’s published privacy policy documentation lists multiple categories of data the service collects and processes. Important categories include:

Text Data (content)

The words you type into the Grammarly editor or into text fields where Grammarly is active are processed to generate suggestions.
Grammarly says it avoids certain sensitive fields (e.g., password fields) but otherwise must analyze text to function.

Account & Profile Data

Name, email, organization domain, subscription tier, billing info (for paid plans)
Team/workspace configuration (enterprise)

Device, App, and Session Data

Browser/OS type and version, app version, device identifiers, and IP ranges
Crash logs, performance metrics, and feature usage

Telemetry/Metadata

Error categories, suggestion acceptance rates, and frequency of use
Potentially inferred patterns (e.g., usage hours, document length ranges)
Telemetry, used for debugging and product improvement

Behavioral Data

In some configurations, activity and usage patterns are used to optimize suggestions or features.

Because content is processed in Grammarly’s cloud, anything typed into an inspected field may be transmitted. So even if the company does not intend to store sensitive content long-term, temporary processing and associated metadata are part of the attack surface.

Compliance Risks With Grammarly

For organizations in regulated industries (healthcare, finance, legal, etc.), compliance is often a bigger concern than functionality. Grammarly users may inadvertently create risks under frameworks such as:

1. HIPAA (Health Insurance Portability and Accountability Act)

The Health Insurance Portability and Accountability Act of 1996 establishes a set of standards to protect sensitive health information. Grammarly is compliant with HIPAA security, privacy, and breach notification rules.

Grammarly’s public materials indicate it supports certain enterprise controls and can enter into business associate agreements (BAAs) under some conditions, but these are not unconditional. Organizations handling PHI should confirm a signed BAA and specific controls.

2. GDPR (General Data Protection Regulation) / CCPA (California Consumer Privacy Act)

Grammarly publishes GDPR and other privacy compliance statements and provides subject-rights options, but data residency, transfer, and subprocessors still matter for compliance teams.

3. Contractual or IP Risk

Sending drafts of proprietary code, confidential contracts, or trade secrets through an external NLP service can violate internal policies or third-party NDAs. Legal teams should evaluate use cases.

For regulated or highly confidential workflows, treat Grammarly as “conditionally allowed” and require explicit exceptions, contracts, or isolation.

4. SOC 2

Grammarly has completed SOC 2 (Type 1) and SOC 2 (Type 2) examinations and received corresponding reports. These examinations validate that Grammarly meets the strict SOC 2 standards for security, availability, confidentiality, and privacy of our customers’ data.

5. SOC 3

Grammarly’s SOC 3 report is a publicly available version of the SOC 2 (Type 2) report. To learn more, view the System and Organization Controls (SOC 3) Report.

Grammarly’s Requested App Permissions (By Platform)

Like most apps, Grammarly needs certain permissions to function across different platforms. These permissions control what the app can access on your device, such as the text you type, the websites you visit, or specific system features. They are directly tied to how Grammarly provides suggestions. Understanding them makes it clearer what data Grammarly can interact with and where potential risks may arise.

Browser Extensions

Read/modify content in web pages you visit (to analyze text and render suggestions).
Communicate with Grammarly’s servers.
Optional clipboard or download access where features require it.
Site access scopes (all sites vs. specific sites; on click vs. automatically).

Desktop apps (Windows/macOS)

Accessibility/typing overlay permissions to read text in applications.
Network access to connect to Grammarly’s service.
Auto-update permissions (version control risk consideration).

Mobile Keyboards (iOS/Android)

Full-access keyboards may transmit typed input for suggestion generation.
Network access for cloud suggestions may be limited in local-only modes.

These permissions are necessary for Grammarly to provide real-time writing feedback across platforms. However, they also mirror the same permissions that malicious browser extensions exploit. Attackers often disguise malware as legitimate tools by asking for broad permissions. This is why version-level risk assessment is crucial.

Security Measures Grammarly Uses

Grammarly implements several security controls:

Encryption: TLS encryption for data in transit and AES-256 for data at rest.
Bug bounty program: Partnerships with security researchers to identify vulnerabilities.
Zero-access design: Sensitive authentication details (like payment information) are tokenized and not accessible to Grammarly employees.
SOC 2 (Type II) certification: Ensures compliance with recognized security frameworks.

These measures show that Grammarly takes security seriously, but as with any SaaS tool, vulnerabilities can still emerge, especially through updates.

Risks of Using Grammarly

Even with strong security measures, Grammarly carries risks:

Data exposure: Sensitive information could be processed in Grammarly’s cloud.
Compliance violations: Use in regulated industries may breach HIPAA, GDPR, or internal confidentiality rules.
Malicious extensions: Fraudulent or compromised versions could bypass Grammarly’s safeguards.
Insider threat: If Grammarly accounts are compromised, attackers may gain access to stored documents or settings.
Third-party access: Service providers working with Grammarly increase the potential attack surface.
Over-broad permissions: “Read and change data on all websites” is risky by default.
Supply-chain/version risk: A single compromised update can flip risk overnight.
Shadow IT & sprawl: Unmanaged installs across browsers/devices bypass central controls.
Lookalike/malware risk: Fake Grammarly apps/extensions can harvest credentials and data.

Is Grammarly a Keylogger or a Security Threat?

One common concern is whether Grammarly functions as a keylogger. By definition, a keylogger records everything a user types, often for malicious purposes. Grammarly does not operate as a traditional keylogger, but the concern arises because it captures typed input to provide suggestions:

Keyloggers are malicious programs that secretly record every keystroke.
Grammarly only processes text in active writing fields to provide feedback.

Grammarly states it does not monitor password fields or sensitive system entries. Still, from a technical perspective, Grammarly does behave in ways that resemble keylogging. It monitors text input and transmits it to external servers.

The distinction lies in intent and transparency. Grammarly is a productivity tool, not malware. But organizations should still treat it with the same caution as any app that processes typed content.

Has Grammarly Ever Been Hacked? Security History and Risks

To date, Grammarly has not reported a major breach involving widespread compromise of user data. However, in 2018, a security researcher discovered a vulnerability in Grammarly’s Chrome extension that exposed authentication tokens.

This flaw could have allowed attackers to hijack accounts. Grammarly patched the issue quickly, but the incident highlighted the risks of browser extensions.

More recently, in 2023, Salt Security uncovered a broader OAuth implementation flaw affecting thousands of websites, including Grammarly. This vulnerability could have enabled credential leakage or account takeover under certain conditions, though Grammarly promptly addressed the issue after disclosure.

Researchers have shown in their work on malicious browser extensions, even legitimate apps can become compromised if attackers inject code or exploit version updates.

What Users Can Do to Protect Themselves

If you decide to use Grammarly, here are the steps to reduce risks:

Classify Data

Decide which data types may be processed by Grammarly.

Scope Deployment

Use managed browser policies, domain allowlists/denylists, and separate profiles.

Assess Versions Before Rollout

Go to Spin.AI’s free application risk assessment.
Search for Grammarly and review the risk details for the specific version you plan to deploy.
Compare versions across browsers/OS. Take note of permissions and behavioral changes.

Pilot, Then Expand

Test with a small group, monitor logs, and capture feedback.

Limit Extension Scope in Chrome

Restrict site access to necessary domains rather than “all sites.”

Educate Users

Explain when/where Grammarly is allowed and how to disable it on sensitive sites.

Watch the Ecosystem

Track campaigns and ecosystem threats with this 2025 malicious browser extension tracker and related research on malicious browser extensions.

Contractual Protections

If you must process regulated data, ensure a BAA or equivalent is in place and confirm where data is stored and how it is deleted.

Does Grammarly Collect My Personal Information?

Yes, Grammarly collects personal information, though the extent varies depending on how you use the app. According to Grammarly’s privacy policy, they collect

Personal account details: Name, email address, and payment information for premium plans.
Usage data: Device type, browser type, IP address, operating system, and app version.
Text input data: The content you type, which Grammarly analyzes to provide suggestions.

Grammarly notes that it does not permanently store all text you type. Instead, it processes input in real-time and may temporarily cache snippets for analysis. However, metadata and diagnostic data are often retained for product improvement and troubleshooting.

Does Grammarly Share Your Sensitive Data With Third Parties?

Grammarly states that it does not sell your personal data. However, it does share certain data with trusted third parties for the following purposes:

Payment processing (e.g., Stripe, PayPal).
Cloud infrastructure services (e.g., Amazon Web Services).
Analytics and performance monitoring tools.

Although these are standard practices, third-party integrations increase the overall attack surface. If one vendor is compromised, your data may be indirectly exposed.

What Grammarly Does and Doesn’t Store

While specifics can change by feature and version, Grammarly’s data handling generally falls into two categories: information that is commonly stored or retained, and information that is processed temporarily and not stored long-term.

Commonly Stored or Retainable

Account/profile/subscription data.
Documents you explicitly save in Grammarly’s editor.
Settings, style guides, dictionaries, and team policies.
Diagnostic logs and usage analytics (metadata).

Commonly Not Stored Long-term

Ephemeral text processed solely to generate inline suggestions (unless a feature requires retention or you save content).

Does Grammarly Collect Metadata and Diagnostic Data?

Yes. Grammarly collects metadata, including document length, error frequency, feature usage, and diagnostic logs. While this may not include raw content, metadata can still reveal patterns about your writing behavior and professional activity.

For example, metadata could indicate how often a legal team drafts contracts or how frequently a student writes essays. This type of information may pose compliance risks if shared or accessed by unauthorized parties.

How to Keep Your Grammarly Account Secure

Users can take these steps to enhance Grammarly's security:

Enable two-factor authentication: Add an extra layer of protection against account takeover.
Limit use in sensitive contexts: Disable Grammarly on platforms where you handle PHI, financial data, or confidential corporate documents.
Review permissions: Check which browsers and devices Grammarly is installed on.
Monitor account activity: Review Grammarly account login history for unusual access.

How to Enhance Your Privacy When Using Grammarly

Privacy-conscious users can further reduce risks by:

Using Grammarly’s desktop app instead of the browser extension when possible (fewer third-party interactions).
Excluding sensitive sites from Grammarly’s monitoring.
Regularly clear cached data and revoke permissions.
Reviewing Grammarly’s privacy settings to minimize data sharing.

How to Delete Your Personal Data From Grammarly

If you want to remove your data, Grammarly allows users to:

Sign in to your Grammarly account.
Go to Account → Privacy or Account Settings.
Request data export (optional) and/or data deletion.
For enterprise users, please contact your administrator. Deletion may be governed by corporate retention policies.
Confirm completion and verify removal of the extension/app from devices if you’re offboarding.

This action complies with GDPR’s “right to be forgotten” but may limit future use of the tool.

Is Grammarly Safe to Use on Different Devices?

Grammarly is available across:

Browsers (Chrome, Edge, Safari, Firefox).
Desktop (Windows, macOS).
Mobile (iOS, Android).

Each platform has unique risks. For example, browser extensions face higher exposure to malicious updates, while mobile apps rely on permissions that may grant broader access to device data. IT admins should evaluate risks per platform and control deployments accordingly.

Can Grammarly Access Everything You Type?

Grammarly can access text fields in supported applications. However, it does not work in

Password fields.
Certain secure websites (e.g., banking logins).

Still, users should assume Grammarly has broad access when enabled, making it important to disable the app in contexts involving sensitive data.

Final Verdict: Is Grammarly Safe?

So, is Grammarly safe?

For most casual users, yes. It’s generally secure and trustworthy. Grammarly can be safe if you treat it like any other powerful data processor. Safety depends on what you send to it, how tightly you control permissions, and how rigorously you monitor version updates.

For consumers and many business use cases, sensible configuration and hygiene are sufficient. For regulated data, keep Grammarly out of those workflows unless you have an airtight policy coverage and vendor assurances.

The most reliable way to answer “Is Grammarly safe?” is to test and verify:

Run Spin’s assessment: Research Grammarly (by version) in the free application risk assessment.
Operationalize controls: Use SSO/MFA, extension policies, domain blocklists, data classification, and version pinning.
Stay informed: Track extension threats with the 2025 malicious browser extension tracker.

Build A Dual-Purpose App: Text-to-Image and Custom Chatbot Using Comet, GPT-3.5, DALL-E 2, and Streamlit

TheophilusOnyejiaku — Wed, 29 May 2024 12:05:46 +0000

Overview

In this guide, we will explore how to create a dual-purpose application: a chatbot powered by custom dataset and a text-to-image generator, using OpenAI’s GPT-3.5 turbo and DALL-E 2 models, along with Comet and Streamlit.

Now let’s take a brief look at the infrastructures we will be using.

Comet

Comet is a platform that offers real-time experiment tracking with additional collaboration features. With Comet you can log your object detection models (YOLO, Tensorflow), large language models, regression and classification models and the like, with their various parameters. It also gives you the capability to monitor the training and prompting of all of these models and provides you with the option to share your logged projects publicly or privately with your team.

One advantage Comet has over similar platforms is its ability to easily integrate with your existing infrastructure and tools so you can manage, visualize, and optimize models from training runs to production monitoring.

GPT-3.5 Turbo Model

According to OpenAI, the GPT-3.5 Turbo is a model that improves on GPT-3.5 and can understand as well as generate natural language or code. With the help of user feedback, OpenAI has improved the GPT-3.5 Turbo language model, making it more proficient at understanding and following instructions. Being a fine-tuned model by OpenAI, it has been given examples of inputs and expected outputs to train (fine-tune) it for a particular task. OpenAI created GPT-3.5 Turbo as an expansion of their well-liked GPT-3 model. The GPT-3.5-Turbo-Instruct is available in three model sizes: 1.3B, 6B, and 175B parameters.

DALL-E 2

DALL·E 2 is an AI system that can create realistic images and art from a description in natural language. Below is an image generated by this app by running a prompt “A cup pouring fire as a portal to another dimension.”

Streamlit

Streamlit is a platform that enables you to build web applications that can be hosted in the cloud in just minutes. It helps you build interactive dashboards, generate reports, or create chat applications. Once you’ve created an app, you can use the Community Cloud platform to deploy, manage, and share your application.

This application is an example of deploying with Streamlit.

Prerequisites

In this section, we will quickly take a look at some of the tools you will need to successfully follow along with these steps and ultimately build your own application.

Python: A high level programming language for many use cases. For this project, we will be using Python version 3.9. This project will still work with any older version of Python. Proceed here to download any version of Python from the list of operating systems available. Ensure to add Python to your PC environment variable by following this guide.
pip: A package installer used in python. It is very important to have pip running in your PC for you to be able to flow along with this project. See this guide on how to install pip and add it to your PC path.
Pycharm IDE: Pycharm is the integrated development environment we will be using to build the application. It is simply where we will be writing our code. It is easy to install and saves you a lot of coding time, by assisting with code completion, code navigation, code refactoring and debugging. The community edition of this software is free! Once you create and give a name to any new project, it provides you with a Python virtual environment (venv) that enables the installation of libraries specifically for that project as opposed to sharing them with all users of the computer.
Dataset: The dataset we will be using in this project for training the LLM can be found here. Taking a closer look at the dataset structure, as seen in the figure below for the first two movies from the dataset, we will need only the movie's "title", "year", "genre" and the "extract". This structure of the dataset is very important to take into consideration; when we get to the coding part of this project, we will look into that.

Now Let’s Get Started!

To achieve our objective, we will be following just 5 simple steps.

Step 1: Create a Comet account to log your LLM

Now, if you haven't already, go to Comet and create a new account. After successfully creating your account, head on to API key section to get a copy of your comet API key.

Here, you can generate an API key for all your projects. You will need the API key for this part of the project. Copy and save it somewhere.

Step 2: Create an OpenAI account to access OpenAI API

If you are new to OpenAI, create your OpenAI account here. Once you’ve successfully created an account, go on to API key section by using the same credentials you used when creating your account. On the left panel of the screen, click on “API Keys” and then proceed to click on “Create new secret key”. This is shown below:

Next, you get a pop-up, as shown below, asking you to give a name for your secret key. Proceed to give it any name and click the “Create secret key” option.

Once done, you get the response to save your key. Ensure to copy and save your API key somewhere as you might loose it if you do not copy it instantly.

Note: This API key is very important to save immediately. Once you close this pop up, you will not be able to get the key again and you will then need to create a new key from scratch. It is therefore necessary you copy it and save it somewhere on your PC. An MS word will do just fine.

Building the Application

Now its time to build the application. You can use any IDE of your choice (I used Pycharm). We will need the following libraries for the successful development of this application:

comet-llm: This is a tool that will be used to log and visualize our LLM prompts.
openai: This is the tool with which we will be using the GPT 3.5 turbo and DALL-E 2 API’s.
Streamlit: An open-source framework used for building data science and machine learning applications.
json: Python module for encoding and decoding JSON data.
urllib.request: Python module for making HTTP requests and working with URLs.

Step 3: Install all Dependencies

You first create a new project in your Pycharm IDE and give it any name. This way, you automatically have an environment to start coding with your Python interpreter and other packages.

Now, in your IDE terminal, run the following commands to install all the dependencies:

pip install openai streamlit comet_llm

Once done successfully, you will need to configure your API key from OpenAI.

Step 4: Configure your OpenAI API key

Inside your IDE directory, create a new folder called “.streamlit” and create a new file, “secrets.toml” file inside it. It will look like this snippet shown below:

Now open the “secrets..toml” file and add the following line of text:

MY_KEY = "Now copy your Openai API key you copied before now and paste it here to replace this."

Make sure to replace “Now copy your OpenAI API key you copied before and paste it here.” with your actual OpenAI API key. After adding this line, save the file.

Step 5: Write your Code

Now create a new python script and give it any name. For this, I named mine “dualapp”. Below is the code to build this dual-purpose app with inline explanation for each line of code.

import streamlit as st
import openai
from openai import OpenAI
import comet_llm
import json
from urllib.request import urlopen

# Initialize OpenAI client
client = OpenAI(api_key=st.secrets["MY_KEY"])


# Load the JSON content of movies from the provided URL
response = urlopen("https://raw.githubusercontent.com/prust/wikipedia-movie-data/master/movies-2020s.json")

# Limit to the first 100 items
train_data = json.loads(response.read())[:100]

# Extract relevant information for training
movie_info = """
Hi! I am a chatbot designed to assist you. 
Here are some movies you might find interesting:
"""

for entry in train_data:
    title = entry.get('title', '')
    year = entry.get('year', '')
    genres = ", ".join(entry.get('genres', []))
    extract = entry.get('extract', 'No extract available')
    movie_info += f"- {title} ({year}) - Genres: {genres}\n"
    movie_info += f"  Extract: {extract}\n"


# Instruction for the model
instruction = """
You are strictly going to answer questions based on the movies provided to you. Do not discuss any other information that
has nothing to do with the movies provided to you. 
I want you to take note of the year, title, genre, and extract of the movies and be able to answer questions on them.
"""

# Combine movie_info and instruction for the system message
system_message = instruction + "\n\n" + movie_info

selection = st.sidebar.selectbox("Chat Bot to Text to Image", ("Custom Chat Bot", "Text to Image"))

if selection == "Custom Chat Bot":
    # Initialize Streamlit UI
    st.title("This is a chatbot about Theo")

    # Initialize chat history
    if "messages" not in st.session_state:
        st.session_state.messages = []

    # Display chat history
    for message in st.session_state.messages:
        if message["role"] == "user":
            st.markdown(f"**You:** {message['content']}")
        elif message["role"] == "assistant":
            st.markdown(f"**💼:** {message['content']}")

    # User input for new chat
    prompt = st.text_input("📝", key="user_input_" + str(len(st.session_state.messages)))

    if prompt:
        st.session_state.messages.append({"role": "user", "content": prompt})

        # Formulate message for OpenAI API
        messages = [{"role": "system", "content": system_message}]
        for message in st.session_state.messages:
            messages.append({"role": message["role"], "content": message["content"]})

        full_response = ""
        for response in client.chat.completions.create(
                messages=messages,
                model="gpt-3.5-turbo",
                stream=True,
        ):
            full_response += (response.choices[0].delta.content or "")
        st.session_state.messages.append({"role": "assistant", "content": full_response})
        st.markdown(f"**💼:** {full_response}")

        # Display user input field for next chat
        st.text_input("📝", key="user_input_" + str(len(st.session_state.messages)))

        # log LLM prompt on comet
        comet_llm.log_prompt(
            api_key="9HibPMbc18shhthis_is_my_api_key",
            prompt=prompt,
            output=full_response,
            metadata={
                "model": "gpt-3.5-turbo"
            }
        )

else:
    # Initialize OpenAI client
    client = OpenAI(api_key=st.secrets["MY_KEY"])

    # Streamlit UI for Text to Image
    st.title("DALL-E-2 Text-to-Image Generation")

    # User input for text prompt
    text_prompt = st.text_input("Enter a text prompt")

    if text_prompt:
        # Use the OpenAI API to generate image from text prompt
        response = client.images.generate(
            model="dall-e-2",
            prompt=text_prompt,
            size="1024x1024",
            quality="standard",
            n=1,
        )

        # Get the generated image URL from the OpenAI response
        image_url = response.data[0].url

        # Display generated image
        st.image(image_url, caption="Generated Image", use_column_width=True)

Key take-aways from the code above:

Initialize OpenAI client using the API key you copied from your OpenAI account.
With the variable system_message we are able to teach or give instruction to our model about any information.
Initialize the chat history.
We display the chat history.
We also provide a new chat for user input right away.
We formulate the message for OpenAI, then iteratively generate completions from a chat client using a GPT-3.5 Turbo model based on the provided messages.
We log the LLM prompt on Comet using the API key from Comet.

Run your App!

Run the command below to run your app. The name I gave to this app is “dualapp” as mentioned before.

streamlit run dualapp.py

Bravo! You’ll get the response shown below:

Click on the link in the output message to view your app.

This is the home page of the app

Below is a Prompt using the chat bot

Below is the corresponding LLM log on comet. Visit here to view this page. Make sure to click on “Columns” in order to select the variables of the table you want to see as shown in the figure below:

Now lets explore the app:

[video width="1280" height="644" mp4="https://www.hitsubscribe.com/wp-content/uploads/2024/04/YouCut_20240409_113404658.mp4"][/video]

Summary

To successfully create this dual purpose app that integrates both text-to-image and custom chatbot, we followed the following steps:

Step 1: Create a Comet account to log your LLM.
Step 2: Create an OpenAI account to access your OpenAI API keys.
Step 3: Install all dependencies.
Step 4: Configure your OpenAI API key.
Step 5: Write your code.

Thank you for your time!

Credit: Dataset from Peter Rust

Developer Marketing: An Insider's Guide with Actionable Tips

Erik Dietrich — Mon, 28 Aug 2023 20:14:47 +0000

I spent about a decade in roles with various flavors of "software engineer" in the title. After that, I logged time as a dev manager, CIO, IT management consultant, and dev trainer/coach. I have occupied, supervised, or advised literally every role in the IT org chart.

So naturally, I founded a marketing company three years ago.

That weird career transition is a story for another day. You see, I'm engaging in the editorial sin of unsolicited autobiography with an actual purpose.

I want you to understand that this guide comes, yes, from an understanding of marketing. But, more importantly, it comes from a deep, deep understanding of the buyer landscape.

I'm going to walk you through the ins, outs, and subtleties of developer marketing. And I'm going to do it from the unique perspective of a long-time insider that understands marketing.

First of All, Stop Generalizing the "Developer" Persona

Let's start with an easy one. Easy to understand, at least. It might be harder to initially wrap your head around it, since I see an industry antipattern in developer marketing.

"Developers hate marketing and they're skeptical of it."
"You can find developers on Stack Overflow constantly because they're obsessed with DIY solutions to technical problems."
"Engineers won't buy anything without reading about it in depth and trying it extensively."
"You know how programmers are; they hate meetings and will do anything to avoid talking to people."

I read and hear these sorts of statements all the time...in the context of one marketer talking to another.

Here's a fun exercise. Zoom out a little and imagine you're reading a marine biologist talk about the lovable, but enigmatic octopus.

You won't be able to unsee this now. The way marketers tend to talk about developers ranges between anthropological and reminiscent of animal biology.

This tendency toward overgeneralization, however, is nonsense. And I'll drive that point home with two simple statistics:

Number of software developers in the world: 26.4 million.
Number of Australians in the world: 25.5 million.

From a quantitative perspective, these efforts to categorize software developers are like saying, "You know how marketing to Australians is—they all have pet kangaroos and carry around giant Crocodile Dundee knives!"

So stop generalizing software developers. They aren't octopuses that you're studying, and there are too many of them to generalize even if they were.

To Understand the Marketer-Developer Relations Baseline, Understand Recruiters

While overgeneralizing developers as a demographic isn't productive, there are certain aspects of the developer experience that you could generalize: CS degrees, bootcamps, tech interviews, etc. But the one that I want to productively generalize here is the developer experience with recruiters.

To put a little informal data behind it, I ran a poll of our authors (who are engineers). I asked this question, with yes or no poll options:

In the last month, has a recruiter reached out with a job that was ill-suited for your actual skills/experience?

100% of respondents said "yes."

Recruiters Become Insufferable for Engineers

To have software development experience or education is to become a juicy target for software recruiters. As both a former target of this relentless, transactional outreach and someone who has employed it on the hiring side, let me explain briefly how it works.

Recruiters and recruitment firms are heavily commissioned. And they earn their pay by charging the hiring authority a roughly 20% average of the hired candidate's first year of salary. If we call the average developer's salary $100K for easy math, that means they get $20K for each arranged marriage.

Understand, also, that software development has been an employees' market for years and years. This makes developers hard to find and hard to pry away from their current jobs. This, in turn, incents the recruiters to blast out insincere outreach, constantly, en masse, without the most basic research.

Hey dudebro! Our totally gnarly client is looking for a junior rockstar coding ninja that can pull request to the max! Preferred experience is 10 years in a technology that came out 3 years ago, and I'm sending this to you in spite of the fact that glancing at you on LinkedIn would have told me you have 15 more years of experience than are appropriate for this job. And they've got ping pong tables!!!! API me over that resume, and rock on!

And it only becomes more insincere (if less cartoonish) from there. Almost any developer will be able to share a war story about recruiters fibbing to both parties about the job to make a placement or about a recruiter giving them a high pressure sale on a job that was clearly not a fit.

Now imagine a steady flood of this in your personal inbox, on LinkedIn, and on your phone's voicemail for years.

That's how something that seems like it'd be great—people constantly offering you job opportunities—actually becomes incredibly tiresome.

Marketers Can Easily Walk and Quack Like Recruiters

As I mentioned earlier, it's impossible to generalize software engineers' collective understanding of different business roles. Some are well aware of the difference between marketing and sales, for instance. To others, marketing, sales, and recruiters are a faceless crowd of slick-talking parasites, trying to trick them while feeding off of the value their software creates.

It really does run the gamut.

But if you're not careful, you can smell like a recruiter to even the friendliest, "every role brings value" corner of the software developer demographic. And then, it's all over.

At best, they'll ignore you. At worst, they'll put your content on blast somewhere before you know what hit you. And it's because you've created one of the few things that can unite this disparate demographic: an opportunity for shared catharsis at a near-universal downside of their chosen career.

I'm mentioning all of this to help you understand the persona that sits on your content briefs. To really understand them.

Developers aren't "just left-brained" and they aren't born with some natural aversion to content marketing or marketers. They're just relentlessly assaulted by patronizing insincerity, and they're exhausted by it.

So when you, a non-developer, write a blog post called "10 Reasons Every Developer Should Be on Github," you're inadvertently re-creating for them the experience of inbox spam.

You need to avoid that. Consider insincerity, knowledge-faking, manufactured enthusiasm, and fluff to fall under a common, cardinal sin to avoid: reminding them of recruiters.

How to Segment the Developer Persona (and How Not To)

Having established deal-breaking pitfalls, let's dive into how you should approach things. Let's talk about segmenting the overly-broad developer persona.

A few options might come immediately to mind.

Segment by years of experience: "junior developer" and "senior developer."
Or, maybe segment by org chart roles: "developer" and "architect."
How about tech stack? Rails developers, enterprise Java developers, or web vs backend developers.

Making those distinctions is better, but it's not how I'd go about it if you really want to nail segmentation.

To really nail it, get on the calendar of one or two engineers in your organization. I say this because you've got some collaboration to do.

Work with Engineer Colleagues to Establish Personas

I don't mean to sound contrarian, but I promise that you don't understand your buyers' org charts as well as you think. I've been a CIO, and as an IT management consultant, I actually helped actual organizations construct actual IT org charts, and I still find the complexity and variance dizzying.

Are developers influencers or gatekeepers? Does an architect report to a dev manager or to someone else? Do directors make purchase decisions, or only the CTO?

The answer to all of these questions is "yes."

Helpful? Great, that's why you need help.

See if you can find engineers in your organization or in general that have resume experience at companies that look like your ideal clients. This immediately takes you from abstract speculation to concrete examples.

Interview those folks to get a sense of what those org charts looked like, who made decisions, who owned budget, etc. Create avatars of your buyers, influencers, gatekeepers and committees based on those interviews. That will help you understand buying dynamics so that you can work backward toward the reader persona of your content.

Then Work With The Engineers to Segment by Beliefs about Software Development

This is where you should segment further. But not by demographics—by psychographics. (Here's a quick primer, if that's a new term for you.)

You want to understand what your prospective users and buyers believe about software development.

For instance, consider these questions that expose fault lines in the software development world:

Agile: god-send, or corporate cringe?
Is a computer science degree important?
TDD: table stakes for professionalism or overrated?
Is Javascript the assembly language of the internet, or is it the sloppy language of wood glue and baling wire?

I cannot tell you how powerful it will be to find patterns in how your buyers and users feel about these issues. In many cases, you'll have an even split, but when you find the ones where one opinion correlates with enjoying your offering, you've just struck gold.

Consider, for instance, how the psychographic segmentation of "agile skeptic" can make your content creation picture crystal clear.

Chase virality on Hacker News and Reddit with contrarian "agile is dead" pieces and earn a deluge of new fans if one takes off.
Drive engagement on social media by asking people to vote on, say, whether things constitute "agile fails."
In organic search, look for questions/keywords associated with researching agile so that you get the first bite at the persuasion apple for tomorrow's buyers.

But to accomplish this, you need engineers' input. You need them to explain not just the org chart at companies like your ideal buyers, but to explain what engineers at companies like that tend to believe about software development.

Building a Content Plan

So paired with engineers to advise you, and segmentation in your pocket, how specifically do you create a content plan? Here are some specific suggestions.

1. Start With Organic Search: What Questions Do Members of Your Segment Ask?

We generally recommend organic search as the bedrock of any developer marketing content plan. It's the blue chip play in your content portfolio, and perfect for avoiding the so-called "flatline of nope."

To come up with a solid backlog of topics, figure out what questions your audience asks of the search engine. These should include both topics relevant to your product and also relevant to what your audience believes and is curious about in the developer world.

This becomes the top of your funnel and how you meet a good chunk of your audience: with content specifically designed to answer their questions, walk them through tutorials, and generally help them. With organic content, I strongly suggest outsourcing and guest blogging so that you can publish as quickly as possible. The best time to write an organic blog post was two years ago, and the second best time is today.

2. Lay Out Strong Opinions That Bind Your Audience to You

Working with engineers to help you, you've discovered what your audience believes—their psychographics. Working with key folks internally, use those to define some controversial opinions that will endear your audience to you.

With these opinions in place, define some (mildly) controversy-courting posts to write and share. For instance, if you sell a tool that enables remote or asynchronous code review, you might schedule a post along the lines of "It's Time to be Honest: Pair Programming is Overrated."

This style of post becomes another way to bring audiences in and bind them to you, but this time through social media share and syndication. Publish these on your blog, promote them, syndicate them to sites like DEV and DZone, and submit them to sites like Hacker News and Reddit.

With this style of post, you can outsource them to guest authors, but I'd suggest finding internal folks to do it, if possible. This might be dev rel folks working for you or internal engineers. This style of content is closer to your brand, and lets you position your people as columnists that can build a following. (Brands, rather than individuals, tend to attract followings in the dev world).

3. Define Pain-Dream-Fix for Your Offering

With two flavors of top of the funnel content in your back pocket, let's move to the middle of the funnel.

Again, working with the engineering folks you've partnered with, sit down and talk through pain-dream-fix. How does your product make the developers using it more awesome? What's in it for them?

Here where we're more in the territory of product marketing, you want to tell these stories. You can do this as case studies, but if at all possible, I'd suggest doing it with blog posts. With the aforementioned asynchronous code review tool, write a post that shows users how to navigate a code review workflow on Github that, oh, by the way, just happens to use your tool.

In an ideal world, you can draw readers directly to these posts with the right organic strategy. But a lot of you reading don't have the kind of product that neatly generates use cases that correspond to great keywords. So plan to get eyeballs on this content with backlinks from your organic posts and controversy-courting direct shares.

This is another kind of post that you can outsource, but are often better doing internally, if at all possible. It tends to have a non-trivial learning curve for the author, and with freelance software engineers, they're going to pass that cost right on to you.

4. Create Collateral to Help Your Champions Make the Sale

At some point, you've sold your audience. The engineers reading your content trust your brand, like your offering, and have perhaps even concluded a trial. That's incredibly important.

But it's also, in all likelihood, not the end of the story. Rather, it's just the start of your sales cycle, where some combination of your sales reps and the engineers have to sell their leadership on opening the purse strings.

Address this with content. Case studies are great, obviously. But you can also create blog posts, emails, webinars, and other pieces of collateral to help both the developers and your sales team convince the monetary buyer.

If the engineer is sold on your remote code review tool, she'll appreciate a blog post about how to manage up when it comes to such tools. I have firsthand experience with this, since I literally still earn royalties on a course I made six years ago, helping engineers sell tools and practices to their management.

Of course, you need collateral for your sales reps. But don't sleep on enlisting enthusiastic engineers to help you with the sales process.

5. Create a Developer-Savvy Promotion Plan

You've now got all of the content components in place. Organic posts on your blog will bring a steady supply of traffic, and your opinionated posts will bring in spikes of it, while endearing your audience to you. From there, you're building trust as developers interact more with you.

But you want to make sure that you're creating and distributing content efficiently. You want to work with the engineers helping you, again, to understand your audience's digital haunts. And you want to get content to those channels as regularly and easily as possible.

Here is a quick list of things to do to wring everything out of the content.

Identify syndication-driven and share-driven sites where your audience hangs out, and form a plan as to which content to promote there (definitely all of your shareable content, but be leery of syndicating organic content).
Comb your posts for good quotes that you can turn into graphical pull quotes. This helps SEO in organic posts and it also gives you material for social media.
With the posts that you write, brainstorm what sorts of questions they might answer on Q&A sites like StackOverflow and Quora. Especially with organic posts. If you can do it helpfully and as a good citizen, add links back to your posts as answers or comments.
If you have the bandwidth, have someone in your organization make videos, facing the camera, where they talk through the points covered in blog posts.

These are just a few of the things you can do, but it should get you started.

Developers Are the Key to Developer Marketing

If you've noticed a theme throughout this post, it's that I've advised having your software engineer collaborators sitting with you through all of this planning. That's no accident.

It's become common for developer tools companies to enlist engineers to write content. That's old hat. But having them participate in keyword research and content strategy is relatively uncommon.

I know that it's uncommon because it's what Hit Subscribe does for its clients, and it's proven to be a massive differentiator as we've grown over the last few years. At every stage of our process, we involve engineers —subject matter experts—because of their deep understanding of the nuances of reaching the audience from which they hail.

So as you create and then execute your plan, make sure you're involving engineers at every step.

Dev Bloggers/Technical Bloggers Wanted

Angela C — Mon, 22 Nov 2021 19:04:06 +0000

Hit Subscribe is a company that hires engineers to write content for technical blogs. So, what we're looking for is quite straightforward: engineers interested in a side hustle writing technical content for companies that sell to engineers. Or, put more simply, we want you to write content (mostly blog posts) about technical topics like DevOps, testing, machine learning, security, and more.
If you like writing blog posts (or think you might, and have been meaning to start your own technical blog) let's talk.
Apply here: https://www.hitsubscribe.com/apply-to-be-an-author/