Let’s be honest — developers are a tough crowd, especially when they’re using their own tools. If something’s clunky, confusing, or even two clicks too far, someone’s already grumbling in Teams or filing a ticket titled “why is this like this.” And that’s exactly why having developers use their own tools works so well. By running our day-to-day operations through the very software we build, we catch rough edges early — not through support tickets, but through developer eye-rolls. It’s not just quality assurance; it’s quality discomfort — and it drives us to polish faster, simplify more, and build something we’re actually happy to use.
This becomes even more powerful in the context of routine, unglamorous tasks — the kind every developer dreads but can’t avoid. Beyond developing customer-facing use cases and validating them through proper business testing, we also deal with config checks, content updates, and deployment rituals. And because we use the exact same tools and interfaces as our customers, those inefficiencies and UX quirks don’t hide for long. When something’s tedious, brittle, or unintuitive, we feel it immediately — and fix it before it becomes anyone else’s problem.
While our product development is driven by customer needs — with a clear focus on delivering meaningful value and a great user experience — some useful refinements also come from our own internal workflows. By using the same tools as our customers, we occasionally uncover issues or areas for improvement that might otherwise go unnoticed. These often take the form of enhancements and technical tweaks that help make the product more consistent, efficient, and pleasant to use. Here are just a few examples from that deeply technical, developer-shaped layer of our product work:
Service Integration Testing
We run regular integration tests for our services using Workflows in the Automation App and Flows in the Flow App. These tests help ensure that critical systems are online and communicating — but more importantly, the process of building them often exposes issues that wouldn’t surface through automated tests alone. One early example involved timer activities and the background jobs behind them, which helped shape our current approach to recurring, time-sensitive workflows.
As we continued building and scaling these flows — often involving dozens of steps, conditions, and service interactions — we began encountering another category of challenges: friction in the UI and overall user experience. These are the kinds of issues that only become apparent when you’re deep in real usage. During one of these builds, a developer noticed that a field could really benefit from a format hint, quickly added it, and later received appreciative feedback from others who no longer had to guess the expected input. It was a small tweak, born out of hands-on use, that quietly improved the experience for everyone.
Deployment Helpers
Deployments are smoother thanks to internal tools we built using Automation. These workflows scan application changes in our repositories and ensure they move correctly through staging and production. While setting this up, we realized our Automation App needed to support a broader range of activities — particularly around interacting with the Flow App’s API. So we extended its capabilities.
This improvement didn’t just help us streamline our deployment processes — it made the Automation App more versatile for everyone. Customers gained access to new, more powerful building blocks for their own flows, and interestingly, even our own developers began using certain linked features more actively. Once those activities became easier to integrate, adoption naturally followed. What started as an internal need ended up unlocking better workflows across the board.
Weekly Reports & Development Diaries
We also use Flows for team reflections and weekly reports — a simple but valuable ritual. Filling these out regularly give us firsthand experience with the UI and revealed usability issues in the Flow App that wouldn’t show up in automated tests. In one instance, a developer stumbled upon a layout issue that only appeared with a specific type of real-world content — something our test cases hadn’t included. It turned out to be a fairly impactful UX flaw, and thanks to that internal discovery, we were able to fix it before it ever reached customers. These small improvements, driven by actual use, make the product feel noticeably smoother and more reliable for everyone.
These are just a few examples from the tip of the iceberg — many other cases are either too boring or a bit too revealing for a blog post 😉. But the principle stands. Using what we build isn’t just a habit — it’s part of our product DNA. It keeps us honest, sharp, and empathetic. Because if we don’t feel good using it ourselves, we can’t expect others to either.