Why distribution and attention are the real bottleneck in B2B SaaS | Pete Hunt @Dagster

In this episode of saas.unbound, Anna Nadeina talks with Pete Hunt, CEO of Dagster Labs, about what AI is actually changing inside software companies—and what it is not.

Pete has worked across engineering, open source, product, and company building. He started his career at Facebook before its IPO, helped build Instagram’s first web app, became an early core contributor to React, founded and sold a company to Twitter, and now leads Dagster Labs.

The conversation moves beyond broad claims about AI productivity. It covers the engineers who thrive in the AI era, the work that still needs careful human ownership, why Dagster has not reduced hiring, how an open-source company funds its product, and why distribution has become a more meaningful constraint than building software.

From engineer to CEO: Journey people and destination people

Pete did not become a CEO because he wanted to escape engineering. At Dagster Labs, he originally joined as Head of Engineering while founder Nick Schrock served as CEO. Over time, the two recognized that their interests were better matched to different roles: Nick wanted to focus more on customers and creative technical work, while Pete was willing to take on the operational responsibilities of running the company.

That shift led to a useful way of thinking about why some technical founders embrace the CEO role while others resist it.

Engineers often fall somewhere between two broad orientations:

• Journey-oriented engineers get energy from solving difficult technical problems, working deeply in a craft, and enjoying the process of building.
• Destination-oriented engineers care most about the outcome: shipping something useful, reaching users, growing adoption, or building a successful company.

The CEO role tends to suit people who are more motivated by the destination. The destination may still be the same—creating a valuable product and a durable business—but the work is entirely different. It includes hiring, compensation, planning, finances, insurance, customer relationships, and many other responsibilities that are far removed from writing code.

This distinction is becoming even more visible with AI. Some engineers see AI as a powerful route to an outcome: a faster way to build, test ideas, and solve customer problems. Others experience it as a loss of the creative work they enjoyed. If the joy came from the journey of writing and refining code, then supervising generated output can feel less satisfying than building directly.

AI is changing developer experience, but adoption should not be forced

AI-assisted development creates a new tension for engineering teams. Instead of progressing through small, manageable implementation steps, developers can now receive large volumes of generated code at once. The work can shift from building to reviewing, which brings its own cognitive load.

At Dagster Labs, the approach has been to give people room to use tools in the ways that work for them. Teams still need enough standardization to collaborate effectively, but there is little value in being overly prescriptive about individual workflows. Just as teams may not need to dictate every developer’s IDE, they do not need to dictate every detail of how people use AI.

What matters is helping teams share the practices that work. Some groups will adopt AI tools quickly and move at a faster pace. Others will move more gradually. The management challenge is not forcing uniformity; it is enabling more teams to benefit from the effective practices that emerge.

This includes:

• Making AI tools and use cases visible across the organization.
• Sharing practical workflows and lessons learned between teams.
• Identifying where faster teams are gaining leverage.
• Helping other teams adopt those practices when they fit their work.

The bigger shift may still be ahead. Today, AI produces increasing amounts of code that humans must inspect carefully. Eventually, that manual review model may no longer scale. There may simply be too much generated code for traditional review to remain the final control mechanism.

When “slop lands in master,” alignment becomes the real engineering work

The important question is not whether every line of AI-generated code will always be individually reviewed. It is how companies create systems that prevent poor-quality output from causing harm.

That means improving the feedback loops around software development. AI systems need to test their own work, follow clear specifications, and meet quality requirements before changes are accepted. Humans will increasingly be responsible for defining the constraints and validating the outcomes rather than manually authoring every implementation detail.

Pete describes this as a practical form of AI alignment. Rather than focusing on science-fiction scenarios, the central question is much more immediate: how can an AI system be aligned with the requirements of a particular job?

For a software team, that means asking whether the system:

• Builds the intended feature.
• Follows the relevant specifications.
• Passes the required quality checks.
• Completes work within acceptable cost and time limits.
• Respects security, data, and operational constraints.

This kind of work will be exciting for some engineers and frustrating for others. But it is likely to become an increasingly important part of technical work as generated software becomes more common.

Pete’s own career offers a useful reminder that not every valuable technical task begins as enjoyable work. He studied distributed systems and joined Facebook expecting to work on large-scale backend infrastructure. Instead, he found himself working on frontend product development and early React. Initially, it was not the work he expected or preferred. Over time, however, he learned to enjoy it.

The lesson is not that everyone must love every change in the industry. It is that people can often develop an interest in unfamiliar work when they understand its value and give themselves time to become capable at it.

Data privacy still requires clear policies

AI tools have made it easier for people to paste information into new systems without thinking through where that information travels. That risk is especially important for companies handling customer data, sensitive business information, or regulated workloads.

Dagster’s architecture limits some of this exposure. The company primarily handles metadata, such as table names and update times, rather than the underlying contents of customer tables. That creates a different risk profile than businesses working directly with highly sensitive user information.

Still, the basic discipline remains the same. Customer data should not be sent into a new AI product—or any external system—without understanding how it will be stored, processed, and protected.

Practical safeguards include using clear internal policies, relying on approved vendors, and monitoring the growing ecosystem of AI and agent security tools. The technology may be new, but the underlying responsibility is familiar: organizations need to know where customer data flows.

Local models may also become an important option for businesses that want more control over sensitive information. Models such as Gemma, Qwen, and DeepSeek can run locally and may offer a more suitable path for certain use cases where data privacy is a primary concern.

Where AI creates real product-development compression

AI is changing product development at Dagster Labs, but the impact is uneven. Customer buying cycles remain largely familiar. Enterprise customers still evaluate products through processes that resemble those of recent years.

What has changed is the volume of opportunities and the speed at which teams can pursue them. More data-intensive applications are being built, creating more potential buying cycles. Internally, smaller teams can now take on product areas that would have been too ambitious before AI-assisted development.

A team of three people can sometimes accomplish work that may previously have required a team of around 10. But that leverage depends heavily on the stakes of the work.

For lower-risk areas, AI can create substantial compression. A project that once took a week may now take a day. In these cases, the effective speedup may be in the range of three-to-one or five-to-one.

For higher-risk work, the gains are far smaller. Database migrations, core infrastructure, and anything that writes to a source-of-truth system still require caution. AI may help generate code, but the review, verification, and operational responsibility remain substantial.

The result is not a single productivity number. It is a more nuanced picture:

• Lower-stakes work: large portions can be automated, enabling very small teams to move quickly.
• High-stakes work: AI can assist, but careful human review limits the degree of compression.
• New product capabilities: AI makes some previously impractical features much easier to build.

For example, recommendation-style experiences can be incorporated into products more easily with modern language models. A product can help users discover relevant information or suggest useful next steps without requiring the same level of custom system-building that such functionality previously demanded.

Why developer productivity is difficult to measure

AI productivity claims often sound more precise than they really are. Self-reported gains may not match the number of features shipped, the quality of the software, or the long-term cost of maintaining it.

Dagster does not use simplistic metrics such as lines of code for performance reviews or compensation. Commit velocity has increased, and a complete absence of commits may sometimes indicate a problem depending on someone’s work, but commit counts alone are not a meaningful measure of engineering value.

The stronger signal is ambition. Teams can now take on projects that were previously too expensive, too slow, or too risky to pursue. Expectations around delivery have shifted, particularly for lower-stakes features and experiments.

That is a more useful framing than trying to assign every developer a precise AI productivity percentage. The real question is whether the organization can responsibly attempt and complete more valuable work than before.

Higher productivity does not automatically mean hiring less

One common assumption is that AI should lead every company to hire fewer people. Pete’s perspective is that this depends on the company’s business model, market opportunity, and goals.

Dagster Labs has not changed its hiring plans because of AI. For venture-backed companies pursuing large markets, the constraint is often not a lack of efficiency alone. It is the need to deploy capital quickly enough to capture a meaningful opportunity.

When productivity increases, a high-growth company can use that leverage to become more ambitious rather than simply reducing headcount. More capable teams can pursue more customer segments, build more product areas, run more experiments, and expand their market reach.

That does not mean AI-related layoffs do not exist. Different companies face different economic constraints. A business focused primarily on profitability may make different decisions than a company trying to grow rapidly in a large market.

But for organizations with a clear opportunity and strong demand for talent, AI may act less like a replacement for hiring and more like an amplifier of what the company can pursue.

Distribution and attention are now the bigger bottlenecks

As software becomes easier and faster to build, product development is no longer the only—or even the main—constraint for many businesses.

Product-market fit, attention, distribution, sales, and marketing remain difficult. Even the largest AI companies have launched products that failed to gain meaningful adoption. Building something is not the same as earning a place in a customer’s workflow.

For many B2B SaaS companies, the constraint is no longer simply having enough product bandwidth to build. It is having enough distribution strength to run the right experiments, reach the right audience, establish trust, and convert interest into customers.

In this sense, AI is transforming go-to-market work at least as much as it is transforming engineering. Top-of-funnel activity, marketing operations, research, outreach preparation, and content creation can all become faster and more scalable.

However, enterprise selling remains deeply human. The larger the contract, the more important relationships become. Buyers spending significant sums often want to speak with a real person, ask detailed questions, and develop confidence in the company behind the product.

Building trust through real human connection

For bootstrapped founders, large-scale sponsorships and expensive trade-show booths may not be realistic. But in-person events can still be valuable without a five- or six-figure budget.

Instead of sponsoring a major booth, founders can buy a ticket, attend in a company shirt, meet customers and contacts face-to-face, and spend time building relationships. The important part is not treating every interaction as a transaction.

Rather than focusing only on an immediate upsell or sales target, create a positive experience around the relationship. Plan something enjoyable in the host city, bring customers and contacts together, and make room for genuine conversation.

The goal is to build an environment where good things are more likely to happen. A customer may not make a purchasing decision that night, but the stronger relationship can matter during a renewal discussion, a future expansion, or a moment when the customer is deciding whether to take a chance on a newer vendor.

People want to enjoy their work relationships—even relationships with vendors. Being a decent human and creating positive shared experiences is not a soft alternative to go-to-market strategy. It is often part of what makes the strategy work.

How open source supports Dagster’s commercial business

Dagster Labs builds Dagster, an open-source framework for building and operating data pipelines. Its commercial offering, Dagster Plus, provides the additional capabilities companies need to run Dagster in the cloud or within their own environment.

Open source is central to the company’s strategy. In a category where Dagster was not the first product to market, the open-source offering needs to be genuinely strong. It raises awareness, creates trust with technical users, and gives teams a real product they can adopt and evaluate.

But open source is not free to maintain. Someone still needs to build the software, pay for infrastructure and tools, respond to security issues, verify changes, and support the project over time.

There are several possible ways to sustain an open-source project:

• Large corporations can fund contributions to important projects.
• Individual maintainers can carry the work themselves, often at the risk of burnout.
• A company can establish a commercial model that funds ongoing development.

Dagster Plus represents the third approach. The open-source core remains available under the Apache 2 license, while larger organizations can pay for adjacent capabilities that become more valuable as teams and operational complexity grow.

Those paid capabilities include hosting, enterprise security, collaboration, and team-oriented features. A company with a small data team may not need extensive collaboration controls. A company with hundreds or thousands of employees is far more likely to benefit from them.

The principle is straightforward: if a large organization derives substantial business value from open-source software, it is reasonable for that organization to pay for the commercial capabilities that help it operate the software at scale.

A four-week build cycle followed by a two-week cool-down

Dagster’s development process includes a four-week development cycle followed by a two-week cool-down period.

During the four-week cycle, teams work toward a defined set of goals in a structure similar to a traditional sprint. They build, ship, land changes, and cut a release.

The cool-down is not simply a pause. It creates room for two different types of work:

• Product leaders, technical leads, and managers reflect on what was shipped, conduct research, and plan the next cycle.
• Engineers address quality work, cleanup tasks, technical debt, and other important improvements that are often invisible to top-down planning.

This structure recognizes that engineers often know about necessary maintenance work that does not naturally appear in feature roadmaps. Without dedicated space for it, these tasks can be repeatedly postponed in favor of urgent business priorities.

The system has been in place for roughly six months, and it has helped support product quality while giving teams room to plan and improve the foundation beneath future work.

Software teams are becoming groups of makers

AI is blurring traditional role boundaries. Designers can write more code. Engineers can contribute more directly to design. Data analysts can build interfaces around the information they need to explore.

Rather than neatly separated functions, more people are becoming broadly capable makers who can work across adjacent disciplines.

This is also shaping what customers expect from software. Flexible, composable products increasingly appeal to teams that want to connect and rearrange capabilities in ways the vendor did not necessarily anticipate. The preferred experience can resemble a Lego set: modular pieces that can be combined to solve a particular problem.

More monolithic, all-in-one solutions may feel less attractive to these early adopters because they limit how much users can adapt the product to their own needs. Whether this becomes a permanent market shift remains to be seen, but it is a meaningful trend in how technical teams are thinking today.

Staying grounded in a fast-moving industry

There is no shortage of tools to explore, models to test, or headlines to follow. Pete has found value in tools such as Codex, ElevenLabs, and local models, while also recognizing the temptation to treat every new capability like a slot machine: an endless stream of small experiments that may not move important work forward.

The counterweight is focus. Teams and leaders need enough discipline to distinguish between a useful tool and an interesting distraction.

More importantly, founders and operators need something outside of work that matters deeply to them. For Pete, that is family. For others, it may be a hobby, community, health, or time outdoors.

AI and SaaS are moving quickly, and no one has complete certainty about where the market is heading. Maintaining a meaningful life outside of work is not a sign of reduced ambition. It is what makes sustained ambition possible.