Contributors have always been a vital component to The New Stack. Since the site’s inception in 2014, we have had an open door policy for those who wanted to share their own views in a contributed post. Whether you’re representing a major corporation or coding solo on weekends, we welcome your insights and experiences through contributed posts.

Interested in contributing? You can reach out to us directly. We typically review submissions within a week. However, to maximize your chances of publication and readership, consider the following guidelines.

Our readers value The New Stack for its clear, positive analysis of technology that cuts through jargon and complexity. We respect our audience – CTOs, developers, project managers, and IT professionals – and speak to them as the knowledgeable professionals they are.

We publish content that provides practical solutions to real-world technical challenges. The most impactful contributions combine technical expertise with personal experience. Share your journey – how did you discover this solution? What challenges did you face? These details provide valuable context for your insights.

Get personal with your article and tell readers how you discovered the advice. Personal anecdotes and real-life examples provided important context around your solution.

Don’t send us marketing-driven “neutral” thought leadership pieces. We want articles with excitement and passion – just ensure your claims are accurate and supported by evidence.

Story Ideas

We get it. Sometimes it’s hard to come up with story ideas beyond product announcements and promotions.

But IT people tend not to read these articles – they want insights from other technologists. This is first and foremost our goal at The New Stack: to help readers do their jobs and make smart decisions. Finding where that aligns with your expertise will help position you to readers as a trusted resource.

These articles might help you write articles that appeal to The New Stack’s audience:

Writing for Software Engineers: Read Me First
Writing for Software Engineers: Beyond the Basics

Looking to develop content that resonates with The New Stack’s audience? Here’s your strategic guide for uncovering valuable insights and expertise:

• Talk with your developer relationship advocates and IT project leaders – Your developer advocates and IT project managers are invaluable resources for content ideas. They regularly interact with users, understanding their challenges and needs firsthand. Even when topics don’t directly relate to your products, sharing these insights positions your organization as a trusted knowledge source in the broader tech community.
• Leverage your TNS sponsorship effectively – For sponsors, include your developer advocates in meetings with The New Stack team. Their presence enriches the discussion and helps generate relevant topic ideas through collaborative brainstorming.
• Ask your social media feed – Beyond product promotion, your social channels can reveal compelling content opportunities. User discussions about technical challenges, unexpected use cases, or problem-solving experiences can transform into engaging articles. When you help solve a unique user problem, consider sharing that journey to benefit others facing similar situations.
• Check with the Help Desk – Your help desk team often spots recurring patterns in user challenges. These patterns can inspire articles that address common pain points and provide solutions at scale.
• Showcase your team’s side projects – Many developers pursue personal projects or contribute to open source initiatives. While these might not directly connect to your product line, sharing these experiences demonstrates your team’s technical depth and active participation in the broader technology community.
• Share technical deep-dives – When discussing your tools, present them through an engineer’s perspective, offering detailed technical insights rather than marketing overviews.

Here are some more examples of great content that worked:

Your take on a story in the news, especially with an engineering or startup angle:
What We Can Learn from Twitter’s Outages
How Tech Leaders Are Managing Anxieties after SVB Failure

How you deal with a problem within your own company:
How We Manage Incident Response at Honeycomb
GitLab Data Loss Incident Prompts a Review of its Restore Processes

Why did you take this approach, and not that one, to deal with a technical problem:
Why We’re Sticking with Ruby on Rails at GitLab 

Comparing technologies:
Redis Pub/Sub vs. Apache Kafka 
Terraform vs. CloudFormation: Which Is Better for You?

Explain something:
How to Use Terraform’s for_each, with Examples
K8s Resource Management: An Autoscaling Cheat Sheet 

Your take on a trend:
A New Architecture for APIs 
Coding Sucks Anyway — Matt Welsh on the End of Programming

Why you chose a certain programming language:
Why Is Python so Popular? GitHub Knows What’s up
Rust vs. Go: Why They’re Better Together

Other Things to Keep in Mind

Please note that all contributed content we run must be original. We exclusively publish work that hasn’t appeared elsewhere online, and we require writers agree to a two-week exclusivity period. This approach ensures maximum visibility for your content, both with our readers and search engines. After this period, you’re welcome to republish the material on other platforms, including your own website or Medium.

Don’t feel pressured to write lengthy technical treatises. We value concise, insightful pieces – a 800-word article describing a technical discovery, useful technique, or valuable lesson can be just as impactful. We welcome code snippets, visual elements, and quantitative data to support your narrative.

Please note: ALL post images/illustrations/charts should be 1,800 pixels wide (the size of the page) or 350 pixels tall. This includes feature images.

For technical tutorials with code samples, please note our WordPress platform’s specific requirements:

• Plain text formatting only – no syntax coloring or special formatting
• ASCII characters exclusively – avoid smart quotes
• No HTML or bracket-containing code
• Space and tab formatting is handled on a best-effort basis, with no guarantees of preserving original structure (particularly relevant for Python code)
• Markdown is not supported
• We encourage the use of dynamic elements through third-party tools like Asciinema or dynamic GIFs

To maintain content diversity, we limit contributions from each company or individual to once every three months. If you’re interested in more frequent publications, please contact our sales team about sponsorship opportunities.