Skip to main content

Dogfooding: Encouraging Everyone to Be a Tester

BLIP Bettingcomp PSSB

In the fast-paced world of software development, it’s tempting to push features out the door and rely solely on QA teams or early adopters to find the cracks. But we, at Blip, swear by a different approach: dogfooding. Eating our own dog food means using and testing products and services internally before releasing them into the world. It’s not just a quirky techy saying, it’s a cultural commitment to quality, knowledge and involvement. 

When our engineers, architects, designers, product managers and even executives rely on the same tools they’re building, bugs get spotted earlier, user experiences improve, and our teams gain a deeper understanding of our clients’ needs. But involving everyone in testing isn’t just about catching errors, it’s about fostering a shared sense of ownership and driving innovation. When we’re all engaged with what we’re developing, we gain a clearer understanding of how to improve, evolve, and create truly game-changing products.

 

Bridging the Gap Between Development and Delivery 

Delivering software is hard. Delivering software that every team trusts and deeply understands is even harder. That’s where dogfooding comes in. By running our own builds in-house and putting them in front of everyone, we create a feedback loop that automated tests can’t match. 

In growing companies like ours, it’s important that every team understands what they’re working toward. When we’re focused on day-to-day tasks, it’s easy to lose sight of the bigger picture, the impact of each line of code and how it shapes the final product. By constantly using our own platforms and experimenting with ideas still in development, we bridge the gap between the development and delivery stages. This approach gives Blippers the chance to directly influence the end product, enhance user experience, and ensure no bug goes undetected. It also deepens everyone’s understanding of our business and strategic goals, involving the entire team in the full product lifecycle - from concept to delivery.

PJS

 

How We Dogfood: Internal Competitions 

So how do we actually get a taste of our own food? How do we get everyone involved in enabling new products, giving people a deep, hands-on understanding of new developments and how they impact our apps? We run internal competitions to rigorously test our platforms across all brands, covering both cross-brand products and brand-specific developments. This approach turns every participant into an active contributor to the enablement and success of new product launches. 

Our VPN-protected staging environments replicate production at scale, using similar deployment processes and infrastructures as well as production-like test accounts for realistic, privacy-safe testing. Dedicated slack channels, onboarding tasks for new challenges, and daily leaderboards make the entire process engaging and transparent at every stage of the competition, transforming our internal teams into a high-value QA force. 

These internal competitions act as a strategic way to bring every Blipper closer to our products and see them from the client's perspective. In turn, this helps us catch errors early, shorten deployment cycles, and build products our teams are genuinely proud of. 

And perhaps just as importantly, the competitive format encourages collaboration. Team members form new groups, exchange ideas and work with colleagues they might not normally interact with, strengthening our company culture. At the end of the competition there are also, of course, prizes for the winners, which is always a plus.

 

Why Dogfooding Matters: A Wrap Up 

By now, we’ve seen that dogfooding isn’t just a testing method, it’s a mindset for us. Here are the key principles that make it work and why we keep adopting it: 

  • Everyone’s a tester: From developers to executives, everyone contributes with valuable feedback that improves product features and quality. 
  • Real-world conditions: Internal environments mirror production as closely as possible, ensuring Blippers’ user experience is the same as our clients will find in our platforms. 
  • Knowledge and understanding: By using the tools we build every day, our teams gain a deeper knowledge of how each feature works, how it affects users and how their individual contributions shape the overall product. This firsthand experience builds stronger technical insight and empathy for the clients. 
  • Early detection, faster fixes: Continuous internal use allows teams to identify issues long before clients do. 
  • Culture of ownership: When everyone uses the product, there’s a shared sense of responsibility for its success. 
  • Cross-team collaboration: Dogfooding encourages communication between departments that don’t often intersect, creating stronger, more connected teams. 
  • Data-driven improvement: Internal testing provides real usage data that informs smarter design and development decisions. 
  • Innovation through experience: Testing our products leads to fresh ideas for improvement that only come from hands-on familiarity.

 

The Technical Side of Dogfooding  

Behind the cultural shift lies a robust technical infrastructure that makes company-wide testing possible and secure.

1. Environments 

Depending on what we’re testing, we might spin up a protected staging environment or dive straight into production servers. The goal is always the same: to mirror what our clients see and feel. 

For experiments where more control or security is required, we use staging environments that run on machines only accessible internally via VPN. They run the production code with data identical to what’s used in production, but interactions with real client-facing services are kept to a minimum. 

For very specific situations, we can use the production applications to run competitions or other testing events. These events rely on controlled test accounts and close monitoring. 

2. Security and Access Control 

Whenever we touch production systems, security takes center stage. Our clients’ trust depends on it. Every initiative is carefully coordinated so that Blippers can explore and test our products, without putting anything at risk. 

Thus, when promoting these internal competitions, we need to make sure the Security and Internal Fraud teams are aware and alert for any suspicious activity. 

Test accounts used in production applications need to be properly flagged as such, approved and monitored by the Internal Fraud team to prevent any armful or bad behaviours. When dealing with real currency, there is also the need to disable all deposit and withdraw features, especially when using production environments.  

Finally, we make sure that these accounts are short lived and they are deleted as soon as they outlive the scope for which they were created.

3. Monitoring and Analytics 

As all modern application systems, we have a wide range of monitoring tools. Most of the outcomes and conclusions of our tests and experiments rely on dashboards and reports already created by our data analytics teams for the real-world clients. 

Because we’re working with the same data infrastructure during these internal events, we get to see exactly how our systems behave, where friction hides, and how people really move through the product.  

We pair those metrics with the human side of feedback. What did Blippers struggle with? What surprised them? What made them smile? These stories, combined with data, paint the full picture. 

Every dogfooding event becomes a feedback loop, a mix of metrics and lived experience that guides our next improvements. It’s a reminder that analytics isn’t just about numbers, it’s about listening to the story they’re telling, and acting on it before our clients ever need to. 

4. Feedback and Suggestions 

The best way to collect feedback is to make it easy for everyone to provide it. 

As a company best-practice, most or our products and initiatives have open Slack channels, where anyone can join and share suggestions on improvements or report issues with those products. These channels act as a catch-all and are long lived and separate from specific events. They are monitored and regularly advertised internally. 

When running a competition, we tend to take advantage of the closeness to the participants and the underlying context to explicitly collect feedback through forms and other call-to-action. This helps us focus the feedback into a more fine-grained detail. 

5. Running a Competition 

Motivation to win is a big driving factor in all initiatives and dogfooding is no exception. Having the mechanisms to allow Blippers to use our products internally isn’t the same as actual engagement, especially if we take into consideration that no direct value can be extracted from normal usage. 

To captivate engagement, we run internal competitions with a dedicated prize pool, custom leaderboards, and fun tasks to focus attention on specific features where feedback is more important. 

The tools used for these initiatives are parallel to the regular production environment, so they are custom made. 

The leaderboard typically serves as the main focal point of the competition. We share this information through a simple web application hosted on an internal URL. To ensure data security, given that the application requires access to account balance data, it is only accessible through the corporate VPN.  

Some special considerations need to be taken into account: for daily updates, we can subscribe to filtered internal reports from tools such as Google Analytics or Looker and automatically feed that data into the web application. If real-time data is required, we can use an authentication token to access the wallet service and retrieve the balance data. This token is monitored and will often be limited in access to make sure no real client data is accessed by accident. 

When it comes to enabling testing involving a large number of people, most of the effort to enable dogfooding is organizational, since the goal is to use the products as they are presented to the clients, almost as a black box usage. Most technical hurdles are related with security, access control and monitoring. Different challenges arise when running competitions, since there is a need to foster and keep user engagement by running parallel applications like the leaderboards.  

 

Learning Through Dogfooding and Improving the Competitions  

Dogfooding isn’t just a method, it’s part of our DNA at Blip. Since the very beginning, we have been organizing internal competitions to get everyone on board with ongoing developments and ideas for future ones. It keeps us curious and deeply connected to the products and services we deliver. When we encourage everyone to be a tester, we don’t just find bugs, we find opportunities. Opportunities to simplify, to enhance and to engage our clients with experiences that feel seamless because we’ve already walked in their shoes.  

Over time, we’ve refined these competitions to make them more dynamic and meaningful. By turning internal testing into a company-wide practice, we transform every release from a simple handoff to a shared achievement. Each iteration becomes a reflection of collective effort, pushing each product further. 

Ultimately, dogfooding reminds us why we build in the first place. It’s about a constant drive to improve and evolve. When everyone is part of the journey - from idea to implementation - innovation stops being a goal and becomes a natural outcome. 

And, of course, dogfooding isn’t the only way we test products, drive innovation and promote collaboration - so stay tuned for the next one! 

 Quote_PS

Related Articles

Blog Post Deni Junior 5

Protecting Your Frontend from Impossible Scenarios

This article is not about error screens or user experience. It is about how development-level decisions can protect our customers from impossible scenarios and give the developer more confidence while writing code.

View More
BLOG POST 16MAR 2 (2)

Learning at Scale for Engineering at Scale

For software development teams, the moment we stop learning is the moment our technical stack starts becoming obsolete. It’s not about how many languages or tools we know. It’s about how quickly we adapt when they evolve, get replaced, or transform…

View More
BLOG 19FEB 4 (1)

What “Done” Really Means

"Done": A Dangerous Word? In Software Engineering, the word “done” might seem simple, almost obvious. In reality, it can be deceptively slippery. What’s “done” for a developer implementing a feature may not be the same as what’s “done” for QA,…

View More