A firm foundation for engineering intelligence

We usually talk about engineering leaders, their pain points, and how Flux helps them and their teams. Here, I want to talk about something different: our product philosophy and how we approach building our solution.

For us, this product philosophy serves as a framework, a set of guardrails for building Flux. We're a startup in close communication with our customers, so we can move fast. As we do, we need to check in against our foundations.

We're sharing this so engineering leaders like you know why we're building the features we do. Any time you choose a platform, you should make sure the team behind it understands you and your challenges. You should see that they're being thoughtful about the problem space, not just cranking out features (which is a lot easier these days thanks to agents!) 

We're building Flux for you, so let's dig into how and why.

Iterate quickly, with customers

Internally, we have a set of guiding principles we call the "Flux Operating System", or fluxOS. One of the most important is "treat customers like guests in our house." For product development, this means we welcome customers in and listen. We aren't afraid to experiment and learn—we quickly build prototype features to explore solutions to our customers' real problems. We ship code early and often.

We also dogfood Flux—I use it daily, and we look at it as a team every two weeks in our engineering meeting. We identify improvements this way, but we primarily depend on the feedback from design partners and customers.

Code-first engineering intelligence

Flux is a code-first engineering intelligence platform. We believe that the code tells the best story of what your team (people and agents) are doing. It's where we can identify real risks and opportunities. 

Other platforms and legacy tools start by connecting to your project management systems. We don't ignore these systems, but we treat them as secondary to the code.

This approach is critical in the age of AI and agentic development, because ticketing systems are falling behind as we all write more code more quickly. Even with new developments like Rovo trying to bridge the gap between project management and code, tickets will always be a proxy for the actual code changes. Derivatives can be useful, but they're lossy. They shouldn't be your primary source of engineering intelligence.

Platforms that focus on DX (developer experience) often start with surveys. These are important tools to understand your team, but there are many options for surveying your team, from lightweight (Google Forms) to robust and company-wide (15five).

These are incomplete because they're missing the critical (and harder to glean) signals from code changes. We plan to integrate with survey systems to supplement our findings. But again, we start with the code as the ground truth.

Provide value with minimal setup, zero ticket tuning

"It took us months to get the system set up and tune Jira."

We've heard this so many times. When you're relying on insights from a project management system, you have a lot of dependencies: configuration, labeling, user consistency. Everyone does things differently. It's a time- and labor-intensive process to set up, and it's fragile.

With Flux, our goal is to minimize operational and administrative overhead. You connect your repositories, and Flux quickly begins analyzing your code and change patterns so you can start seeing useful insights with minimal setup. From there, if you want to adjust and tune, great. But we want you to get value out of Flux as quickly as possible.

Show our work, not just a score

Like you, we're engineers. We don't like to be handed an inscrutable answer or AI insight without rationale. We don't want to have to look into the details every time, but we want to know that we can if something looks off.

We always strive to show our work. We don't just give you data or a finding; we show how we got there in the code and the signals we analyze, so you can see why Flux is surfacing a particular metric or risk.

Build for engineering leaders

The seemingly endless stream of AI and agentic tools are overwhelmingly targeted at individual contributors (the developers on your team). There are many, more every week, and your team is likely using several as you move toward agentic development.

But engineering leaders like you still have responsibilities, and there aren't many platforms built just for you. That's why you keep using Excel and DIY solutions to crunch the numbers. We're building Flux for leaders like you. Flux is built explicitly to help you set strategy, manage risk, support teams, and explain tradeoffs to executives, using ground‑truth signals from the codebase.

Support teams, don’t spy on developers

Too many engineering intelligence platforms are used to spy or beat up on developers. The most famous example, of course, is building a "lines of code" leaderboard. We all know this is too simplistic, encourages unnecessary complexity, and is easily gamed. 

We believe in the power of engineers working together in teams. We know that you want to support your team, coach them, and help them be at their best. 

We aim to be as transparent as possible, showing data in a clear manner to support change management, not micromanagement. We use standard team metrics like DORA and SPACE. We show data at a team level to foster collaboration and help you uncover opportunities for increased efficiency and output. We strive to provide a nuanced view of individual devs in a team context, and with full transparency so individuals and managers are working from the same data. 

A firm foundation

If you're an engineering leader navigating AI-accelerated development and any of this resonates with you, please get in touch. We love talking with folks like you about your challenges around visibility, velocity, and risk in the codebase. Reach out to discuss how Flux can help.