
In the world of software development, the ultimate testament to a platform's capability is often whether its own creators rely on it for their most critical tasks. For GitLab, the comprehensive DevSecOps platform, this isn't just a talking point—it's a fundamental operational reality. GitLab runs its entire company, develops its vast software, manages its complex infrastructure (including GitLab.com), and fosters its all-remote culture using its own single application. This profound commitment to "eating your own dogfood," or as they often put it, "GitLab on GitLab," is not just a practice; it's a core tenet that shapes the product, drives innovation, and ensures a deep empathy with its global user base.

### The Entire Company Runs on GitLab: A Single Source of Truth

GitLab's vision, as often articulated by CEO Sid Sijbrandij and reflected in their extensive [public handbook](https://handbook.gitlab.com/handbook/), is to provide a single application for the entire software development lifecycle. This vision is most powerfully validated by their own internal adoption. From idea to production, GitLab uses GitLab for:

* **Source Code Management:** The millions of lines of code that constitute GitLab itself are managed in GitLab repositories. Every merge request, every code review, and every version iteration happens within their own platform.
* **Continuous Integration/Continuous Deployment (CI/CD):** GitLab's robust CI/CD capabilities are the engine behind their own development velocity. They use GitLab CI/CD to automatically build, test, package, and deploy GitLab.com and its various components multiple times a day. The [GitLab Handbook page on "Dogfooding CI/CD"](https://handbook.gitlab.com/handbook/engineering/infrastructure/library/ci-cd/) provides a glimpse into how seriously they take this internal proving ground.
* **Plan and Project Management:** All work, from strategic initiatives and new feature development (organized via Epics, Issues, and Iterations) to marketing campaigns and HR projects, is planned, tracked, and managed using GitLab's own planning tools. This ensures that these features are robust and genuinely useful for diverse team workflows.
* **Security (DevSecOps):** GitLab champions a "Shift Left" security approach, and they apply this to their own development by integrating their suite of security scanning tools (SAST, DAST, Dependency Scanning, Secret Detection, etc.) directly into their CI/CD pipelines. This internal use is critical for refining these DevSecOps capabilities.
* **Collaboration and Communication:** As a pioneering all-remote company with team members in over 65 countries, asynchronous communication and transparent collaboration are vital. GitLab (the product) serves as the central hub. Merge requests are key collaboration points, issues track discussions, and the entire company handbook—a sprawling, living document of over 2,000 pages detailing how they operate—is a GitLab project, open to contributions and iterations from all team members. This transparency, a core GitLab value, is enabled by their own platform.
* **Operating GitLab.com:** The SRE (Site Reliability Engineering) and infrastructure teams responsible for the massive GitLab.com SaaS offering use GitLab's monitoring, deployment, and incident management capabilities to keep the service running. This is arguably the most demanding "dogfooding" environment, pushing the platform to its limits in terms of scale and reliability.

### How "GitLab on GitLab" Drives Product Evolution

This deep immersion in their own platform provides a continuous, high-fidelity feedback loop that directly shapes the product:

* **Real-World Problem Solving:** When GitLab's own engineers encounter a bottleneck in their CI/CD pipelines, a missing feature in issue tracking, or a cumbersome aspect of code review, they are experiencing the same pain points their users might. This creates a powerful internal impetus to build solutions that address these real-world needs.
* **User-Centric Design for Developers:** Because GitLab's primary internal users are developers, DevOps engineers, and product managers, the platform naturally evolves to meet the sophisticated demands of technical users who value efficiency, automation, and a comprehensive toolset.
* **Rapid Iteration:** With a monthly release cycle ("every month on the 22nd," as highlighted by [Sid Sijbrandij in an InfoQ interview](https://www.infoq.com/articles/gitlab-sid-interview-sw-development/)), the ability to quickly test and validate new features internally is crucial. "GitLab on GitLab" allows for rapid iteration based on immediate internal feedback.
* **Feature Prioritization:** The features that solve the most significant internal pain points or unlock substantial productivity gains for GitLab's own teams are often strong candidates for broader development and release.
* **AI Integration (GitLab Duo):** As GitLab integrates AI capabilities across the DevSecOps lifecycle with GitLab Duo (e.g., AI-assisted code suggestions, vulnerability explanations, value stream forecasts), its own teams are among the first to utilize and refine these tools in their daily workflows, shaping the future of AI-powered software development from within.

### The All-Remote Context: Shaping a Platform for Distributed Teams

GitLab's all-remote culture is not just a work style; it's a product shaper. Because the entire company collaborates and builds software without a central physical office, the GitLab platform has been inherently designed and optimized for asynchronous workflows, clear communication trails (via issues and merge requests), and transparency. This makes it an exceptionally strong platform for other distributed teams and organizations embracing remote or hybrid work models. Their [All-Remote guide](https://about.gitlab.com/company/all-remote/) is a testament to their expertise, and the platform reflects these ingrained practices.

### Benefits of a Transparent, Dogfooding Culture

The "GitLab on GitLab" approach, coupled with their commitment to transparency (much of their handbook and roadmap are public), yields significant benefits:

* **Authenticity and Trust:** Users and customers can see that GitLab believes in its own product enough to run its entire business on it.
* **High-Quality, Battle-Tested Features:** Features are rigorously tested in a demanding, real-world environment before reaching the wider community.
* **Deep Understanding of User Needs:** GitLab developers have an intrinsic understanding of the challenges and desires of other software development teams.
* **Strong Community Alignment:** By being open about their processes and using their own product, they foster a strong connection with their open-source community.

While the primary users within GitLab are highly technical, the company also focuses on making the platform accessible. However, the depth and breadth of features, as noted in some external analyses like a [SentinelOne article on GitLab CI/CD Security](https://www.sentinelone.com/cybersecurity-101/cloud-security/gitlab-ci-cd-security/), can sometimes present a learning curve for new users—a common challenge for comprehensive platforms that GitLab likely continuously addresses through documentation and UI refinements based on broad feedback.

### Conclusion: The Ultimate DevOps Proving Ground

GitLab's commitment to using its own platform for every facet of its operations is a powerful demonstration of confidence and a critical driver of its innovation. By making its own teams the first and most demanding users, GitLab ensures that its DevSecOps platform is not just a collection of features but a deeply integrated, battle-tested solution designed to meet the real-world challenges of modern software development. The "GitLab on GitLab" philosophy means that when users choose GitLab, they're adopting a platform that is continuously shaped and validated by a global team of experts who don't just build the future of DevOps—they live it every day.

GitLab on GitLab: How the DevOps Platform Builds Itself and a Culture of Iteration


In the software world, the practice of "eating your own dogfood"—using your own products to run your business—is often touted as a path to quality and customer empathy. For Basecamp, the company (also known as 37signals), this isn't just a checkbox item; it's the foundational principle upon which their entire operation and product philosophy are built. Basecamp, the renowned project management and team communication software, is the central nervous system for the company that creates it. Every task, every discussion, every project, and every internal announcement happens within Basecamp itself. This deep, unwavering commitment to being their own most critical and comprehensive user is what shapes the product's distinct, opinionated, and enduring appeal.

### Born from Necessity: Solving Their Own Problems First

The origin story of Basecamp is a classic tale of "scratching your own itch." As a web design consultancy in the early 2000s, 37signals needed a better way to manage client projects and communication without vital information getting lost in emails and disparate systems. As detailed in their book **"Getting Real"** and reiterated in many talks and posts, they built Basecamp to solve their own collaboration and project oversight challenges.

This philosophy of building software for themselves first has remained a core tenet. Jason Fried and David Heinemeier Hansson, co-founders of 37signals, are vocal proponents of this approach. In a [REWORK podcast episode aptly titled "Eat your own dog food,"](https://podcasts.apple.com/us/podcast/eat-your-own-dog-food/id1264193508?i=1000704572975) they discuss why every 37signals product is used internally before it ships. This practice, they argue, keeps them incredibly close to the real problems users face and serves as a crucial filter—sometimes even killing off ideas that don't prove genuinely useful in their own day-to-day work.

### Running the Entire Company on Basecamp

At Basecamp (the company), Basecamp (the product) isn't just *a* tool; it's *the* tool. This comprehensive internal usage spans every facet of their operation:

* **Product Development:** From initial idea shaping (using their **"Shape Up"** methodology, which itself is managed within Basecamp projects) to to-do lists for specific features, code discussions, bug tracking, and coordinating launches, every step of the product development lifecycle happens inside Basecamp. The [Basecamp Handbook section on "How We Work"](https://basecamp.com/handbook/how-we-work) outlines their 6-week work cycles and 2-week cooldown periods, all orchestrated within the platform.
* **Internal Communication:** As a pioneering remote-first company (a philosophy extensively detailed in their book **"Remote: Office Not Required"**), clear, organized communication is paramount. Basecamp's Message Boards, Campfires (group chat), Pings (direct messages), and Automatic Check-ins are the primary channels for all internal discourse, reducing reliance on scattered emails or ephemeral real-time-only chats. This directly tests and refines these core communication features.
* **Project Management for All Teams:** It's not just product teams. Marketing, customer support, operations, and even administrative tasks are managed within Basecamp projects. As described on their [website](https://basecamp.com/), they run dozens of projects at once— "one for a web site redesign, one for planning an upcoming offsite, one for working with our accountants, and one just for the executive team to plan strategy, etc."
* **Collaboration with External Partners:** Basecamp is also used to collaborate with external clients and contractors, meaning the "client access" features are also rigorously tested from both perspectives.

### How Internal Use Directly Shapes Basecamp's Features and Simplicity

The opinionated nature of Basecamp—its focus on simplicity and its "less is more" approach to features—is a direct result of its creators building the tool they themselves want to use every day.

* **Feature Genesis from Internal Needs:** Many Basecamp features and improvements are born from the team's own evolving workflows. For example, recent enhancements like [Direct Replies and Boosts in Campfires and Pings](https://updates.37signals.com/post/new-in-basecamp-direct-replies-boosts-on-campfires-and-pings) were added because the team found them useful for their own communication. The ability to have [multiple instances of tools like Message Boards or Campfires within a single project](https://updates.37signals.com/post/design-refresh-multiple-tools-and-plenty-more) arose from their own need for better organization, such as separating internal team chat from automated bot messages or client-facing discussions.
* **Refining Core Tools:** Constant daily use of To-Dos, Message Boards, Docs & Files, and Schedules by the entire team ensures these core tools are practical, straightforward, and effective for getting work done. If a workflow within Basecamp is cumbersome for them, it's a signal that it needs rethinking.
* **The "No" to Feature Bloat:** Because they are building Basecamp for themselves, they are highly resistant to adding features that don't solve a real, recurring problem they experience. This protects the product from the feature bloat that plagues many software tools and keeps it aligned with their philosophy of simplicity, a point often made in their book **"Rework."**

### The Benefits and the "Opinionated Software" Outcome

This unwavering commitment to dogfooding has several profound benefits for Basecamp and its users:

* **Deep Product Understanding:** The team possesses an unparalleled understanding of their product's strengths and weaknesses because they live in it.
* **Inherent Quality Control:** Bugs and usability issues are often discovered and fixed rapidly because they directly impact the team's own productivity.
* **Authenticity:** They can speak about their product with genuine authority and passion because it's a tool they truly rely on and believe in.
* **Focus:** It keeps the product focused on solving core problems related to project management and team communication in a clear, organized way.

However, this intensely internal focus also leads to what they call "opinionated software." Basecamp is designed around how 37signals works best, and this specific approach might not be a perfect fit for every organization. Some users coming from more traditional or complex project management tools might find Basecamp lacking in certain advanced features like granular reporting, complex Gantt charts, or extensive customization options, as noted in some [external reviews](https://www.proofhub.com/articles/basecamp-vs-jira) or [PM Software analyses](https://www.softwareforpm.com/review/basecamp). This isn't necessarily a flaw in Basecamp's eyes; it's a deliberate design choice born from their philosophy of prioritizing simplicity and effectiveness for their way of working.

### Conclusion: The Basecamp Way is Built on Basecamp

Basecamp's story is perhaps one of the purest examples of a company thriving by "eating its own dogfood." Their project management and team communication software is not just a product they sell; it's the operational bedrock of their remote-first company, the canvas for their product development, and the medium for all their internal collaboration. This intimate, daily reliance ensures that Basecamp evolves in a way that is practical, user-centric (with themselves as the primary user advocates), and deeply aligned with their long-held principles of simplicity, clarity, and "calm work." For teams looking for a proven, opinionated way to manage projects and communicate, Basecamp offers a solution that is, quite literally, built on its own success.

Basecamp Builds for Basecamp: The Ultimate Dogfooding Story


WordPress powers a vast portion of the web, from personal blogs to large-scale enterprise sites. Automattic, the company founded by WordPress co-founder Matt Mullenweg, is a central force in this ecosystem, stewarding WordPress.com, developing key plugins like Jetpack and Akismet, and leading the charge with WooCommerce for e-commerce. But Automattic's relationship with WordPress goes deeper than just product offerings; the platform is the very backbone of its own global, distributed operations, profoundly influencing its culture, products, and contributions to the wider WordPress community.

### WordPress.org vs. WordPress.com: An Important Distinction

To understand Automattic's internal use, it's crucial to distinguish:

* **WordPress.org:** The open-source WordPress software that anyone can download, modify, and use to build a self-hosted website. This is a community-driven project.
* **WordPress.com:** A for-profit, hosted website and blogging platform run by Automattic. It uses the WordPress.org software as its core but adds its own layers of features, services, and infrastructure.

Automattic is a significant contributor to the WordPress.org open-source project and, naturally, the developer of the WordPress.com service. This dual role means their internal use and understanding of WordPress technology is exceptionally deep.

### Living on P2: WordPress as an Internal Collaboration Engine

Perhaps the most striking example of Automattic "eating its own dog food" is its extensive, company-wide use of **P2**. P2 is essentially a WordPress theme and workflow optimized for internal team communication, project management, and asynchronous collaboration. For a company like Automattic, which has been remote-first and globally distributed for its entire existence, P2 is not just a tool—it's the lifeblood of its operations.

As stated by Automatticians (Source: Automattic's "How We Work" page, Hacker News discussions):

* **Primary Communication Hub:** Automattic tracks the vast majority of its projects (around 70%) on P2-themed WordPress.com blogs. Email is reportedly not used for internal communication.
* **Asynchronous by Design:** With employees spread across nearly every time zone, P2 enables thoughtful, threaded discussions where decisions are documented, and everyone can contribute regardless of their working hours. The motto "P2 or it didn't happen" underscores its role as the source of truth for important conversations and decisions.
* **Transparency and Searchability:** P2 posts are typically visible across the company, allowing for cross-team awareness and knowledge sharing. Anyone can search for past discussions, technical analyses, or project updates.
* **Fostering Thoughtful Interaction:** Unlike the rapid-fire nature of synchronous chat, P2 encourages more considered, long-form posts and discussions, which is vital for complex problem-solving and strategic planning.

The very design and evolution of P2 have been directly shaped by Automattic's own needs as a large, distributed workforce striving for effective collaboration without relying on traditional office environments or excessive meetings.

### WordPress.com: A Living Laboratory at Scale

WordPress.com, being one of the largest WordPress installations globally, inherently serves as a massive, real-world testing ground for the WordPress software and Automattic's infrastructure. Every update to WordPress core, every new feature deployed on WordPress.com, is effectively being used and monitored by the company that runs the service. This provides invaluable data on performance, scalability, and reliability at an unparalleled scale.

Furthermore, Automattic's own company blogs, internal announcement sites, and, as mentioned, project P2s are all hosted on WordPress.com, meaning their own day-to-day publishing and information sharing rely on the platform they provide to millions.

### Developing and Refining Products Through Internal Use

Automattic's suite of products, including Jetpack (security, performance, site management), Akismet (spam filtering), and WooCommerce (e-commerce), also benefits from internal application and insight:

* **Jetpack & Akismet:** It's highly probable that these tools are deployed across Automattic's own network of WordPress.com sites and internal P2s. This allows them to test new security features, performance enhancements, and spam-fighting algorithms in a diverse and demanding environment before they reach the broader user base.
* **WooCommerce:** While direct internal e-commerce use cases for Automattic itself might be less about selling typical products, their deep involvement in developing the leading e-commerce platform for WordPress means their teams are constantly building, testing, and refining WooCommerce features.
* **Contributing to WordPress Core:** Historically, Automattic has been a very significant contributor of code and personnel to the open-source WordPress.org project. Their developers, working directly on the core software, are inherently using and testing WordPress at its most fundamental level. This deep engagement allows them to identify areas for improvement, propose new features (many of which are outlined on the Make WordPress Core blog), and ensure the platform evolves. *It's important to note that in early 2025, Automattic announced a significant recalibration of its sponsored contribution hours to WordPress.org, a development that has sparked much discussion within the community about the future balance of contributions.*

### The Automattic Culture: Shaped by Its Tools

Automattic's unique, distributed culture and its reliance on WordPress-based tools are deeply intertwined:

* **Empowering Autonomy:** Tools like P2 support a culture where employees are trusted to work autonomously and communicate effectively across distances.
* **Onboarding through Immersion:** A unique aspect of Automattic's onboarding is that all new hires, regardless of their role, spend their first few weeks in customer support for WordPress.com. This practice ensures every Automattician gains a direct understanding of user needs, challenges, and joys, fostering empathy and providing a direct feedback channel from the front lines to product teams.
* **Open Source Ethos:** Even with internal tools, the spirit of open communication and contribution, core to the WordPress project, often permeates how Automattic operates.

### Challenges in a WordPress-Powered World

While the benefits are numerous, this deep reliance also presents considerations:

* **Maintaining P2 Effectiveness:** As the company grows, ensuring P2 remains an efficient tool for information discovery and doesn't lead to overload requires ongoing effort and platform refinement.
* **Balancing Internal Needs with a Diverse User Base:** Tools and workflows optimized for Automattic's highly technical and distributed workforce might not always perfectly align with the needs of a small business owner or a casual blogger using WordPress. The customer support rotation and broader community engagement are vital for maintaining this balance.
* **Navigating the Open Source Ecosystem:** As a major commercial entity deeply involved with a massive open-source project, Automattic continually navigates the complex dynamics between its business interests and the health and governance of the broader WordPress community.

### Conclusion: Making the Web Better, From the Inside Out

Automattic's use of WordPress is a profound example of a company truly living its product. By building its internal communication systems, project management, and even aspects of its company culture on the WordPress platform (especially via P2s), Automattic not only refines its own offerings but also contributes valuable, real-world insights back into the WordPress ecosystem. This internal proving ground, coupled with a deep commitment to the open web, allows Automattic to continue its mission to "democratize publishing," starting from within its own global team.

Articles tagged with "Remote Work"

GitLab on GitLab: How the DevOps Platform Builds Itself and a Culture of Iteration

Basecamp Builds for Basecamp: The Ultimate Dogfooding Story

WordPress at Work: How Automattic Builds a Global Platform by Living on Its Own Creations