SmartSense LIVE26 recap & takeaways

SmartSense LIVE26 took place October 7-9, 2026, at the Hyatt Regency Austin in Austin, Texas. The conference focused on food safety, compliance, and the role of connected technology in daily operations.

It was our first time attending LIVE, in the first year the conference opened to the wider industry. For us, it was also an opportunity to sponsor and support SmartSense, a company we’ve worked with since 2019.

Who SmartSense LIVE26 is for

SmartSense LIVE is designed for people responsible for safety, compliance, and operational performance. Its audience spans food service, healthcare, logistics, and other industries where monitoring physical conditions is part of everyday work.

That makes it relevant to operations and food safety leaders, as well as the technology teams supporting them. A monitoring system has to fit how people check conditions, respond to issues, and document what happened.

SmartSense LIVE26’s attendees spanned retail, healthcare, food service, and education, including Costco, CVS Health, and honeygrow. Speakers brought perspectives from operations, food safety, compliance, IT, and procurement.

What SmartSense LIVE26 was like

The main focus of the event were the SmartSense ONE presentation and the acquisition of Disruptive Technologies, which gave us a clearer picture of the company’s direction: connecting what happens in physical environments with the decisions and tasks that follow.

SmartSense ONE

SmartSense ONE brings SmartSense and Jolt capabilities into a modular platform with shared data and a common web and mobile experience, including offline support. Its seven modules cover monitoring, daily tasks, food safety, audits, maintenance, labeling, and staff scheduling. Customers can choose the capabilities they need and combine them as their requirements grow.

The focus extends from collecting data to acting on it

SmartSense describes its approach in three stages: Sense, Understand, and Act. Sensors capture conditions in the physical world, analytics and AI interpret the data, and digital workflows help teams respond.

The DT acquisition will strengthen sensing and expand SmartSense’s reach

On October 1, Digi announced an agreement to acquire Disruptive Technologies for $130 million. DT brings proprietary sensor technology, more than 250,000 deployed sensors, and devices designed to operate for up to 15 years. The acquisition would bring that technology into SmartSense, establish a stronger commercial presence in Europe, and expand opportunities in building automation and space occupancy.

Seven years of working with SmartSense

Our relationship with SmartSense began in 2019. Since then, we’ve worked together on product development and modernization as the company has grown and brought acquired products into its ecosystem.

One part of that work involved modernizing a remote monitoring app while incorporating features from other legacy products. The decisions went beyond rebuilding screens: we had to understand which workflows to keep, improve, combine, or retire. The resulting application serves more than 10,000 supply chain teams.

We’ve also worked on the process behind sensor deployments. A mobile installation app brought scanning, assignment, validation, and data synchronization into a guided workflow, helping technicians complete more deployments without adding headcount.

That work gave us a specific reason to be at LIVE: to hear from the people whose routines these systems support, and understand where software could make their work easier.

At our booth, we shared a demo showing how connected systems can work together in practice, along with our AI Adoption Handbook and some swag.

After Austin

Thank you to the SmartSense team for having us as sponsors and for the work we’ve shared across products and teams since 2019. Being part of LIVE added a new setting to that relationship: spending time with the people and organizations those products support.

And thank you to everyone who stopped by our booth, tried the demo, or took the time to tell us about their work.

If there’s a workflow you’d like to explore further, get in touch with us. We can help you clarify the problem and decide what would be useful to test first.

‍

AI makes it easier for more people across a company to create a first visual version without relying on Design for every step.

Marketing can generate campaign assets. Product managers can turn ideas into prototypes. Teams can make an idea visible earlier in the process.

That creates a new design problem.

If more people can create, how do you make sure the output still reflects the decisions Design has already made about hierarchy, typography, spacing, composition, and brand?

A design system can help.

When its rules, components, templates, and examples are available to AI tools, other teams can create within boundaries Design has already defined.

Design does not have to build every first version. It can focus on reviewing important decisions and improving the system when recurring problems appear.

A design system can carry judgment beyond the Design team

A design system gives teams shared rules for creating consistent work.

It can define:

• Color, typography, spacing, and composition.
• Components and how they behave.
• Templates for recurring layouts.
• Examples that show how those decisions work together.

That context is useful for AI too.

Without it, someone creating a page, presentation, or social post has to explain what “on brand” or “well designed” means in a prompt.

With a design system, many of those decisions are already documented. AI has a reference for how content should be structured, which components belong together, and what kinds of compositions fit the brand.

Teams get a starting point that is closer to the company’s existing visual language without having to describe it from scratch.

What this can look like across teams

Marketing can create recurring assets with less production dependency

Marketing often works with recurring formats such as social posts, campaign pages, and event assets.

Templates can give the team enough structure to create a usable first version independently. A social template, for example, can define typography, spacing, image treatment, and composition while leaving room for the content to change.

Design can then focus its review on the decisions that need attention.

Product teams can make ideas visible earlier

Product managers often need something visual before they need production-ready design.

If an AI tool has access to the same components and rules the product already uses, a PM can create a rough prototype that is closer to the real product than a generic wireframe.

The prototype is not a design direction by itself. It gives Product and Design something concrete to discuss.

Instead of spending time explaining what an idea might look like, they can focus on whether the flow makes sense, what needs to change, and where deeper design work is needed.

Generated work can show where the system is weak

AI does not only use the design system. Its output can also reveal where the system needs more guidance.

We saw this while using our own design system with AI at Kaizen.

Our Design team created the system while redesigning the Kaizen website. It documented the site’s colors, typography, composition rules, components, and templates. Marketing later began using that same system with AI to create website prototypes and social content.

One pattern kept appearing.

The AI put almost everything inside boxes.

Text, images, and entire sections appeared inside containers, even when a more open composition would have worked better.

Design reviewed the source material and found that many of the examples and rules leaned toward contained compositions. The AI was reproducing the patterns it had been given.

The team added guidance and examples for other layout approaches. The generated work became more varied and used more open compositions.

Instead of correcting the same problem in each new asset, the team improved the guidance that influenced future outputs.

That is one of the useful side effects of this process: recurring corrections can point to gaps in the system itself.

Autonomy still needs boundaries

Giving more people the ability to create does not mean every deliverable should follow the same workflow.

A recurring social post built from an established template may only need a quick review. A new product workflow may need much more involvement from Product and Design before anyone treats the prototype as a direction.

Teams can start by agreeing on three things:

What can teams create independently?

Identify recurring formats where the main design decisions are already understood.

What needs Design review?

Decide which outputs need a light check and which need deeper involvement.

What should go back into the system?

When the same correction happens repeatedly, update the shared rule, component, template, or example.

These boundaries make it clear where teams can move independently and where Design’s judgment is still needed.

What this changed for us at Kaizen

Before introducing this process, a LinkedIn visual could take more than two weeks from request to delivery once other priorities, coordination, review, and revisions were included.

We now estimate that a similar piece can move from copy to something ready to publish in about one afternoon.

For website work, a process that previously took around two weeks can now start with a Marketing-generated prototype in about two days, followed by roughly two days of Design refinement and production.

These are elapsed turnaround estimates, not active design hours. Reusable templates, the design system, clearer responsibilities, and the review process all contribute to the difference.

The biggest change is where the work starts.

Marketing can reach a concrete first version sooner. Design can spend more time refining important decisions and improving the system that will influence the next piece too.

For teams exploring this approach, start with one repeatable format.

Define the rules, examples, and templates needed to create a reasonable first version. Agree on where Design should enter the process. Then pay attention to recurring corrections.

If the same typography, layout, or composition problem keeps appearing, improve the shared guidance instead of fixing the same issue every time.

The goal is to make Design’s decisions reusable while keeping Design involved where its judgment matters most.

If you are working through the same questions, we can help you turn your existing design decisions into practical rules, templates, and review workflows your teams can use with AI.

‍

Legacy software does not become a problem just because it is old.

It becomes a problem when it starts limiting the business.

In one of our modernization projects, a legacy application was still central to the client's product. Customers used it every day to search and book flights, hotels, transportation, and other travel services.

But maintaining it had become expensive. Routine changes took too long, the technology was no longer supported, and the application struggled to meet current accessibility, usability, and security requirements.

The company needed to replace it without interrupting the customers who depended on it.

There is no single right way to modernize legacy software. The right approach depends on how the system works, how users depend on it, and what it will cost to run the old and new systems during the transition.

TLDR

• Modernize when the existing system is creating business problems, not simply because the technology is old.
• Compare incremental migration with building the replacement separately.
• Treat legacy code as a reference, not the specification.
• Define scope, expected behavior, and acceptance criteria clearly.
• Validate the replacement with real users before broad migration.
• Treat launching the new system and retiring the old one as separate milestones.
• AI can speed up implementation, but it cannot resolve unclear requirements.

Start with the business problem

An old system may still serve the business well.

Modernization becomes more urgent when maintaining it starts getting in the way of what the company needs to do.

Common signs include:

• Routine changes taking too much engineering time.
• Security or compliance requirements becoming harder to meet.
• Integrations becoming difficult to maintain.
• Customer requests becoming expensive to deliver.
• Teams avoiding necessary changes because they fear breaking the system.

These problems give the modernization a purpose.

Instead of asking, “How do we rebuild this application in newer technology?”, ask:

What constraints does the replacement need to remove?

That question helps keep the project focused on business needs rather than technology for its own sake.

Decide how the old and new systems will coexist

One of the first decisions is whether to migrate gradually or build the replacement separately.

An incremental migration can work well when parts of the system can move independently. But it also means the old and new applications may need to work together for months.

That temporary architecture has a cost.

In this project, the team initially considered releasing parts of the replacement while the rest of the product remained in the legacy application. They even started working that way.

But the approach introduced additional complexity. Each new feature needed to work alongside the legacy system, requiring compatibility, security, and interoperability work that would eventually have to be removed. With tight deadlines, the extra development effort and future maintenance costs made this approach impractical.

The team decided to build the replacement separately while keeping the legacy application in production. Once the new application was ready, selected customers began using it and reporting issues or missing functionality before the broader migration.

In other projects, moving functionality gradually has made more sense because workflows could be separated cleanly.

The useful question is:

What temporary work does each migration strategy create?

If gradual migration requires months of disposable compatibility work, a separate replacement may be easier to control. If capabilities can move independently, incremental migration may reduce risk.

Make that trade-off explicit before development starts.

Treat legacy code as evidence, not the specification

One of the hardest questions in a modernization is simple:

What should the new system actually do?

“Make it work like the old system” is not enough.

Legacy code can show developers how something was implemented. It cannot always explain which behaviors still matter, why exceptions exist, or what users depend on today.

For each piece of work, define:

• The scope.
• The expected behavior.
• Acceptance criteria.
• Representative use cases or test cases.

Instead of writing:

“Recreate the functionality from the legacy application.”

Start by defining what the user needs to accomplish. Then describe the steps they take, what information they need to see, how the application should respond, and how the team will verify that the feature works as expected.

Modernization projects will uncover missing details. When they do, make the new work visible instead of quietly expanding the task already in progress.

Protect the team's capacity

Keeping the legacy system running while building its replacement creates two workloads.

Production support can quickly compete with modernization work, especially when the same engineers understand both systems.

Before committing to a schedule, decide:

• Who supports the legacy application?
• Which legacy improvements still need to happen?
• Which requests can wait?
• How much modernization capacity is protected?
• What happens when a production issue interrupts the plan?

A deadline is more useful when the capacity behind it is clear.

Validate the replacement with real users

Development being complete does not mean the migration is complete.

Before moving everyone, selected customers on this project used the replacement in their real workflows.

They found bugs, missing information, and behaviors the development team had not anticipated.

Technical completeness does not guarantee that users can complete their work.

Before broad rollout, test realistic tasks with real users. Find out where information is missing, which workflows break down, and where people still need the old system.

Separate launch from legacy shutdown

A migration rarely happens in one event.

The replacement may already be serving customers while the team continues fixing gaps and moving the remaining users.

Treat these as separate milestones:

1. The replacement is ready for testing.
2. The replacement is ready for production users.
3. Customers no longer depend on the legacy system.

Before retiring the old application, confirm that users can complete their important workflows, support teams can resolve problems in the new system, and customers no longer need to return to the legacy application.

If users keep going back, find out why.

The replacement may be missing functionality, require more training, or make an existing task harder.

Migration success is not simply having the new application in production.

It is reaching the point where people can stop depending on the old one.

AI makes clear requirements more important

AI was introduced partway through this modernization project and helped the team implement work faster.

It worked best when the task was already clear.

With defined scope, acceptance criteria, and test cases, developers could use AI to produce more of the implementation and spend more time reviewing the code and checking the expected behavior.

Ambiguous requirements stayed ambiguous.

AI can reduce the effort required to produce code. It cannot decide which legacy behavior matters or what the replacement should do.

As implementation gets faster, understanding the system and defining the work become even more important.

Plan the migration, not just the deadline

A delivery date is not a migration plan.

Teams also need to understand:

• Which pieces of work depend on each other.
• What can happen in parallel.
• Where the biggest unknowns are.
• How much capacity is available.
• What must happen before users can migrate.

The plan will change as the team learns more about the legacy system. Having one still gives the team a way to understand whether the deadline remains realistic.

What should be clear before modernization starts?

Before committing to a migration plan, answer four questions:

Why are we modernizing?

Identify the business constraints created by the existing system.

How will the old and new systems coexist?

Compare the temporary cost and risk of each migration approach.

How will expected behavior be defined and validated?

Document acceptance criteria and representative use cases, then test them with real users.

What needs to be true before the old system can be retired?

Define this separately from the launch of the replacement.

Any question the team cannot answer identifies work that should happen before rollout.

Modernization should remove constraints, not reproduce them

A legacy application is an important source of information, but it should not dictate every decision about its replacement.

Understand which business rules still matter. Make expected behavior explicit. Choose a migration strategy based on the real dependencies between the old and new systems. Then validate the replacement with the people who will depend on it.

The goal is not simply to replace old technology.

It is to leave the business with software that is easier to change, support, and rely on.

If you're planning a legacy modernization and need help understanding the existing system, comparing migration strategies, or defining a path to the replacement, let’s start a conversation.

‍

Kaizen Softworks is Certified in the Claude Partner Network.

This milestone recognizes the Claude training and certifications completed by members of our team. It also reflects work we've been doing across Kaizen: testing how AI can improve software development and exploring new ways to build AI into products.

For your team, that could mean testing a product idea earlier, finding information across internal systems, or reducing manual work in an existing process.

We've been exploring these opportunities through internal experiments and client projects. Now we're bringing that experience into services designed to help you identify where AI makes sense and turn promising ideas into working software.

What being Certified means

The Claude Partner Network is how Anthropic works with firms that help customers bring Claude into production. Its Services Track recognizes progress in developing certified teams, delivering Claude use cases, and demonstrating customer work.

Certified is the first partner tier. It recognizes firms whose team members have completed Claude training and earned Claude certifications.

For Kaizen, this is another step in building our team's AI capabilities. The certifications add structured learning to the practical work we've been doing through our Innovation Hub.

How AI is changing the way we build software

AI is changing how we work across the software development cycle, from exploring ideas and designing experiences to writing code, testing, and releasing improvements.

AI-assisted workflows can help teams build up to 6× faster at a fraction of the cost. The actual gains depend on the project, the tools involved, and how the work is organized.

Our experience has shown us that speed alone isn't enough. AI-generated work still needs clear requirements, technical judgment, and careful review to ensure the software is reliable and maintainable.

For clients, this creates opportunities to explore ideas, validate decisions, and ship improvements faster, with less development effort and lower costs.

How AI changes what your product can do

Using AI to build software is different from adding AI capabilities to a product.

When AI becomes part of your product, the starting point is what users need to accomplish.

Maybe they need to find information across several systems. Maybe your team spends too much time gathering context before making a decision. Or perhaps there's a repetitive task that could be completed with less manual effort.

AI can help with these needs, but making it useful takes more than connecting to a model.

We help define what information AI can access, which actions it can take, when people need to be involved, and how the product should handle incomplete or incorrect answers.

What this means for our clients

Whether you're building a new product, improving an existing platform, or modernizing software, AI creates opportunities worth exploring. Your product doesn't need an AI feature for your team to benefit from AI-assisted development.

Here's how we can help.

Test ideas earlier. AI-assisted prototyping and design exploration can help your team review ideas sooner. You can identify usability issues, gather feedback, and decide what's worth building before committing to a full implementation.

Find where AI fits your project. Not every workflow needs AI, and results depend on your systems, requirements, and team. We help you identify specific opportunities, test them, and decide whether the improvement justifies further investment.

Turn promising ideas into working software. A successful experiment is a starting point. We support the design, integration, testing, and engineering work needed to make software reliable, secure, and maintainable.

Our certification marks progress in developing the skills behind this work. What matters for clients is how we put those skills to use.

Services built around those needs

Your team may have useful information spread across applications, databases, and internal systems. Finding an answer often means searching through several tools. Our Custom MCP Connector service helps connect those systems to AI tools such as Claude, so users can find approved information without navigating every system separately.

Some processes involve the same steps every time: reading a request, gathering information, and deciding what happens next. Our AI Agents service helps identify which parts of those processes AI can handle. We define the task's boundaries with your team, including which tools the agent can use and which decisions require human approval.

A prototype can show that an idea works. Making it reliable enough for everyday use requires more work. Our Prototype to Production service helps your team take an existing prototype further, addressing how it connects with your systems and what it needs to run reliably. That includes defining expected behavior, improving code quality, addressing security, preparing deployment, and planning maintenance.

Where to start

Start with a change worth making.

Choose one workflow or product need. Identify what takes time, where information is difficult to access, or what prevents users from completing a task.

Then define what an improvement should accomplish.

That might mean less time searching for information, fewer manual handoffs, or a task users can complete with less assistance.

Start small, evaluate the whole workflow, and use the results to decide what comes next.

If you have a process you'd like to improve or a prototype you're ready to take further, get in touch. We can help you identify the next step and what it needs to prove.

An AI coding agent works with the context your team gives it: existing code, documented decisions, instructions, and reference examples. If that context contains inconsistent patterns, the agent can repeat them.

Before implementation starts, engineering leaders need to define how agents should work and how the team will check their output. Choosing a coding assistant does not make those decisions for you.

For greenfield projects, where the team is building a new codebase, our approach starts with Sprint 0. This is when the team sets the architecture, coding conventions, agent guidance, and verification process.

The setup has two parts: guidance that shapes the agent's work before it starts, and checks that catch problems afterward. With both in place, agents can take on more implementation while engineers stay responsible for how the software is built.

Give agents clear guidance before they build

The codebase is part of an agent's instructions. Its structure and existing implementations show the agent which patterns to follow.

A well-structured starting point gives the agent better direction than an empty repository or inconsistent boilerplate. That makes the team's early decisions important because those decisions become context for future work.

Sprint 0 makes that direction explicit through four elements:

• Architecture decisions. Record key decisions in lightweight architecture decision records, or ADRs, so agents and developers can refer back to them.
• Repository instructions. Use a file such as AGENTS.md to define the rules an agent should follow in the repository.
• Skills and prompt templates. Prepare reusable guidance for recurring workflows.
• Reference implementations. Keep examples that show the patterns and quality the team expects.

The team also needs to decide what agents can access and do. That includes which files and systems they can see, which tools they can use, what they can change, and which reviews they must pass.

Without enough context, agents have to infer what the team wants. Weak constraints can lead to inconsistent implementations.

Setting those boundaries is part of the engineering work that should happen before agents start building.

Set up verification before relying on agent output

Guidance shapes the work, but the team still needs to check what the agent produces.

That process can include:

• Review rules for architecture, security, and token usage.
• Automated tests and linting that check code against defined rules.
• A sign-off process before changes reach production.

Engineering leaders need to define and maintain these checks. Stronger verification gives the team more confidence to delegate implementation work because problems are easier to detect before they reach production.

As agents take on more implementation, engineers can spend more time on architecture, review, and improving the guidance the agents work from.

Start construction with a clear specification

Implementation needs the same clarity: a description of what the team is building.

In this model, Product explores an idea in a separate environment and validates it with customers. Once the idea is ready for construction, Engineering receives:

• A behavioral specification.
• A test plan with acceptance criteria.
• A link to the prototype for reference.

The experimental code stays in the exploration environment.

We cover that handoff in When PMs can ship code, what changes for Engineering?, including what Product should provide after testing an idea.

During construction, the specification defines the behavior the implementation needs to meet, including edge cases and failure modes. Engineering decides how to implement that behavior within the agreed architecture.

This gives the agent a defined target and gives the developer a clear basis for reviewing the implementation.

Keep engineering judgment in the construction cycle

Sprint 0 prepares the environment, but engineers continue making decisions throughout implementation.

The developer chooses the architecture and reviews the agent's execution plan, including which files it will change and which risks it has identified.

During implementation, the developer supervises the work. Before sign-off, the changes go through manual review, automated checks, and security review.

If the work stops matching the specification or architecture, the developer should stop and reset the cycle.

The guidance from Sprint 0 also needs to evolve. As the team builds, engineers can add new rules and examples, update existing ones, and remove documentation that no longer reflects the codebase.

Maintaining the context agents use becomes part of the development process.

Account for the codebase you already have

This approach is easiest to establish on a greenfield project because the team can set the architecture, conventions, and verification process from the start.

Existing codebases are different. Their previous decisions and inconsistencies are already part of the context an agent sees.

Teams can still introduce the same kinds of guidance and checks. Reaching consistent agent output can therefore take more work.

For a new project, Sprint 0 gives the team a chance to make those choices before implementation begins. Define the architecture, give agents clear guidance, put verification in place, and keep engineers responsible for architectural decisions and release approval.

Then keep that foundation current as the codebase grows.

If your team is starting a new project with AI coding agents, we can help you define the architecture, repository guidance, and verification process before implementation starts.

‍

You've said it in a meeting recently. "With AI, could we just build this ourselves?" It's a fair question. And for the first time in a long time, the answer might be yes, but not for the reasons most people think.

AI has changed the cost equation in two ways: custom software is faster and cheaper to build, and teams can test an idea earlier before committing to a full production build. Together, those shifts make building worth reconsidering in situations where it would have been dismissed a few years ago.

TL;DR

AI made custom software faster and cheaper to build. Projects that used to take six months can now take weeks, at half the cost. 

It also made it much cheaper to test an idea, get feedback, and refine what you need before committing to a production system.

Together, those changes open the build vs. buy decision to more companies. The most common mistake is still the same: committing too early, in either direction, before you've tested the problem and the path you're considering.

The old paradigm

For most of the 2000s and 2010s, the standard advice was simple: when in doubt, buy.

Building custom software meant a technical team, months of development, and an upfront investment, typically $100,000 or more, without knowing whether the result would solve the problem. SaaS subscriptions were cheaper, faster, and someone else's problem to maintain. For commodity workflows like payroll, email, accounting, and basic CRM, the math almost never favored building.

This logic was sound. And it still is, for those categories. Mature SaaS tools in commodity categories come with ecosystem value: documentation, integrations, training resources, community support. Building your own payroll system doesn't create competitive advantage. It creates infrastructure you have to maintain.

The problem is that companies applied this rule too broadly, including to the workflows that determine how they compete. The cost of building made that feel reasonable. It wasn't worth it.

For many mid-sized companies, that left an uncomfortable gap: generic tools were no longer enough for the way they operated, but custom software still looked like an enterprise-level investment.

That assumption deserves a second look.

AI changed both sides of the equation

Most of the conversation around AI and software has focused on one thing: building got faster and cheaper. That's true, but incomplete.

The cost of building dropped. A development project that took six to twelve months can now be completed in six to ten weeks. Costs that ran $100,000 or more have come down to $30,000-50,000 for comparable scope, and in some cases less. At Kaizen, our development teams work two to four times faster than before AI-assisted development became part of our process. The cost of the AI is marginal when teams work with clear requirements and structured context. When they iterate without direction, costs add up, but that's a process problem, not a technology one.

The cost of buying is going up. This part gets less attention, but it matters just as much. SaaS companies are embedding AI capabilities into their products and charging for them, separately. A platform that cost $12,000 per year is now $30,000-40,000 once you add the AI tier, the analytics add-on, and the integrations your operations need. For niche tools serving specialized industries, the pricing was already high and the functionality already limited. Add AI tiers on top and the three-year cost comparison starts to look different than it did when you last ran the numbers.

The result is that the two lines are crossing. Custom software is getting cheaper. SaaS, especially for complex or industry-specific use cases, is getting more expensive.

Most companies are still making this decision based on what building cost three years ago.

There's one more thing AI changed that doesn't get enough credit. It lowered the cost of being wrong early. A functional prototype that used to take weeks of development time can now be assembled in days.

That gives teams something concrete to react to, learn from, and change before deciding whether a full build makes sense.

When building makes sense now

The conditions for building have shifted, but the logic hasn't changed entirely. Building still makes most sense when two things are true:

1. The workflow is part of how you differentiate.
2. You understand it well enough to start defining what you need.

That second condition doesn't mean having every requirement figured out upfront. It means knowing the business and the process well enough to test assumptions, get feedback, and make increasingly specific decisions.

Companies that start building without that understanding can build the wrong thing faster. The speed advantage AI creates doesn't help if it's pointed in the wrong direction.

Some indicators that a workflow is worth owning:

You're working around your SaaS tools. Spreadsheets patching gaps in a platform. Manual re-entry because two systems don't talk. A Zapier automation that everyone is afraid to touch. These are signals that the tool is containing your problem, not solving it. You're paying the SaaS subscription and building a workaround on top of it. At that point, you're paying twice.

The workflow is where your competitive advantage lives. A logistics company with a particular, high-complexity routing and load assignment process is in a different situation than one that needs basic route planning. The first company's process is their edge, and owning that software means no vendor can change the pricing, pivot the product, or get acquired and leave them exposed. A standard CRM, by contrast, is rarely where a sales organization wins. Salesforce's roadmap reflects the priorities of thousands of customers. If your competitive advantage depends on a process that no SaaS vendor will prioritize, you can't buy your way there.

You shouldn't be adapting your processes to fit a tool. The tool should fit your processes. This is a signal for building: when a company has spent years reshaping how it operates around what a SaaS product can and can't do. That's the opposite of what software is supposed to accomplish. Custom software eliminates that inversion. It's built on domain expertise: knowledge of how your business operates. The software adapts to you.

Vendor dependency is a strategic risk. If a price increase, product pivot, or acquisition could disrupt your operations, you're already exposed. Ownership changes that exposure. It also changes your negotiating position if you stay with a vendor: companies that can credibly leave get better terms.

When buying still makes sense

None of this makes custom software the default answer.

For commodity workflows, buying is still faster and lower-risk. Payroll, basic CRM, email, project management, accounting: these categories have mature tools with strong ecosystems. Build a custom solution here and you've committed to recreating the documentation, integrations, training, and community support that already exist in the products you'd replace. That's rarely worth it.

When your process is still maturing, buying can teach you. A company implementing HubSpot is also adopting a structured methodology for sales, one they can refine as they learn. If you don't know what your ideal process looks like yet, building locks you into one version of it before you've earned the right opinions. Sometimes the right move is to buy, learn, and build later with better information.

When you can't realistically own what you'd build, buying is still the right answer. Custom software is an asset with ongoing maintenance requirements: security patches, library updates, performance monitoring, and someone accountable when things break. If your organization doesn't have that capacity internally, or doesn't have a committed external partner, a build will depreciate without upkeep. Be honest about this before you start.

What AI doesn't change

Two things remain constant, and underestimating either one is expensive.

A prototype is not a production system. AI makes it possible to build a working one in days, but its value is simpler than most people assume: it gives your team something concrete to react to, and those reactions reveal what you need.

One of the most expensive problems in software projects is teams discovering, weeks or months in, that they never agreed on what they were building. Everyone had a mental model. Nobody had tested whether those models matched each other. Show someone a working screen and they'll tell you five things they didn't know they thought until they saw it. That conversation, the one that surfaces the implicit assumptions, the disagreements, the things everyone knew but nobody said, is what the prototype is for.

Building from the requirements that come out of those conversations is a different project than building from initial assumptions. The prototype's purpose is to get you to better requirements faster. Production is a separate project, built from what you learned.

What AI doesn't do is replace the expertise required to architect a system that's secure, scalable, and maintainable over time. Security, data structure, integration design, and long-term ownership decisions don't go away because a prototype came together quickly. A fast prototype that moves to production without rethinking those decisions can accumulate technical debt that costs more than the original development savings. Moving fast into the wrong architecture isn't a win.

AI still needs context. Most teams carry knowledge that's never been written down: how things work, why a decision was made three years ago, what the exception to the rule is. AI doesn't pick that up. Neither does a development partner who starts building without asking the right questions. Explicit requirements matter more now, not less, because the tools that execute on those requirements are faster.

How to decide

Before committing to either direction, three questions are worth working through.

1. Is this process differentiating, and do you know it well enough to define it?

If your answer to the first part is yes, make sure your answer to the second part is honest. 

You don't need every requirement upfront. But you do need enough domain knowledge to describe the process, identify what makes it different, and use prototypes or other forms of validation to refine what the system needs to do.

If the answer is "we know how it works but we've never written it down," that work comes first, regardless of whether you build or buy.

2. What does the cost comparison look like over three years?

Include SaaS licensing at realistic price growth (most contracts escalate), implementation, training, integrations, and the cost of the workarounds your team already maintains. Then include the cost to build, plus what realistic ongoing maintenance looks like. The gap is usually narrower than the initial subscription price implies. If you've never run this comparison for your situation, you're deciding without the information you need.

3. Do you have the capacity to own what you'd build?

This means a specific person or team is accountable for what happens after launch, not "we'll figure it out" or "the vendor will handle it." If that accountability isn't concrete and named, the risk profile of building shifts, and buying may still be the right answer even if the cost comparison favors building.

Before you build or buy, validate the path

You don’t need to start building to find out whether building is the right path.

An AI Validation Sprint helps you evaluate the problem, the workflow, and the options before committing significant time or budget. Depending on what you already have, that might include reviewing your current process, comparing existing products, testing key assumptions, or building a lightweight prototype where seeing the workflow in action would help answer an open question.

The goal is to answer questions like:

• Is the problem clear enough to solve?
• Could an existing product meet the need without forcing major compromises?
• What would custom software need to do differently?
• Which assumptions should we test before making a larger investment?
• What are the main technical and operational risks?
• Does the evidence point toward building, buying, or doing more validation first?

Sometimes the answer is to build. Sometimes it’s to buy. We’ve recommended products like Shopify when an existing platform was the better fit, even when custom development was an option.

And if you already have an AI-built prototype, the same process can assess what’s solid, what only works under demo conditions, and what would need to change before it could become a production system.

The goal is not to justify a build. It’s to give you enough evidence to choose the path that makes sense for your business.

Ready to evaluate your options? Start with an AI Validation Sprint.

‍

When an engineer leaves a software team, the visible cost is a vacancy. The expensive cost is invisible: the context that leaves with them, and the months the rest of the team spends rebuilding it.

We've seen this play out across client projects for years. This post covers what walks out the door when someone leaves, how to think about the real cost, and a simple framework for making better decisions when it happens, whether you work with us or not.

The short version

• Turnover costs capacity for weeks. It costs context for months.
• Context is specific and nameable: decision history, business constraints, platform knowledge, and working agreements.
• The reflex to replace the exact profile that left is often the most expensive option. Sometimes the answer is already on your team.
• You can evaluate any software partner on continuity with four questions. We include our own answers below.

What does a software team lose when someone leaves?

A software team loses two things when someone leaves: capacity and context. Capacity is visible and replaceable. Context is neither.

Context sounds abstract, so let's make it concrete. It comes in four forms:

A new hire can match the departed engineer's skills on day one. The four things above take months to rebuild, and while they're being rebuilt, the whole team pays: meetings run longer, settled decisions get relitigated, and senior people spend their time explaining instead of building.

What is the cost of developer turnover?

The cost of developer turnover is the ramp-up period multiplied across the team, not the recruiting fee. The math works like this:

The replacement operates below full productivity for months while they absorb the four types of context above. During that same period, the existing team diverts hours to onboarding, re-explaining, and reviewing more carefully than usual. So the cost is one person's ramp-up plus a productivity tax on everyone around them, at exactly the moment the project needed continuity.

This is why turnover gets underestimated. On the day someone resigns, it looks like an operational issue: fill the seat, keep moving. The bill arrives over the following two quarters, itemized as slower delivery, longer meetings, and decisions that used to be obvious.

Why replacing the exact profile is often the wrong reflex

The first thought is to backfill with an identical hire. Sometimes that's right. But the skill that is left with that person may be easier to replace than the context they gained: the client relationship, the platform history, and the judgment behind past decisions.

Someone already on the team may be able to learn a specific skill faster than a new specialist can learn the client, the platform, and the history behind the work. For a real example and four questions to ask before starting a search, see “Why adding people doesn't always fix a struggling team.”

How to evaluate a software partner on continuity

If you work with an external team, their turnover becomes your turnover. Four questions tell you most of what you need to know, and any serious partner should answer them with numbers:

What's your team retention rate? Ours has averaged 96% in recent years. Whatever the number, ask how it's measured and over what period.

How do you know people want to stay? Retention tells you what happened. An engagement measure tells you what's coming. Our eNPS (employee Net Promoter Score) is +83.

How do you spread context across the team? One person holding all the context is a risk with a name: bus factor. Ask how knowledge gets documented and shared, so continuity doesn't depend on any single individual.

Do you prepare capacity before it's needed? On some projects, we bring people up to speed on the business and the platform before there's an immediate need. When the project needs more capacity, nobody starts from zero.

These questions work on any vendor, including us. That's the point.

AI has changed what Product Managers can do.

A PM can now go from an idea to working software in hours. They can build a flow, put it in front of a customer, learn from it, change it, and test again without waiting for every iteration to go through Engineering.

That creates an opportunity for product teams. It also creates a new challenge.

Just because a PM can build something doesn’t mean that thing is ready to become production software.

If we don’t rethink how Product and Engineering work together, faster prototyping can become more code for Engineering to untangle, more unclear ownership, and more pressure to turn experiments into production features.

The answer is to separate exploration from construction.

PMs and engineers are solving different problems

During product discovery, the PM is trying to answer: Should we build this?

That means testing assumptions, changing direction quickly, throwing things away, and getting something real enough in front of a customer to learn from it.

Engineering is solving a different problem: How do we build this correctly?

That means thinking about architecture, security, maintainability, performance, edge cases, and everything else required for software that has to live in production.

Both need AI. But they don’t need the same working conditions.

Exploration benefits from speed, autonomy, and low friction. Construction needs stronger guarantees and guardrails. Trying to optimize the same environment for both creates tension.

So instead of asking how PMs can safely contribute code to the production codebase, there’s a more useful question: What if PMs had their own space to build and validate ideas?

Give PMs a safe place to explore

A PM working with an AI coding agent can build functional versions of new ideas. Not a Figma screen. Not a ticket describing what something might do.

Working software that can be used to test the product experience. The important part is that this environment is separate from production.

That boundary gives the PM freedom to experiment without requiring the same controls we’d expect from production software. The environment can be designed so experiments can’t affect the live product or access things they shouldn’t.

Now the PM’s workflow can look more like:

Idea → build → test with users → learn → iterate

Engineering doesn’t need to be pulled into every cycle.  Engineering still matters. It  gets brought in once Product has stronger evidence about what’s worth building.

The prototype shouldn’t be the handoff

This is where things can go wrong.

If a PM spends two days building something with AI and then gives the repository to Engineering saying, “It mostly works, can you finish it?”, we haven’t improved the product development process. We may have just moved the mess downstream.

The prototype should help answer product questions. It shouldn’t make technical decisions on Engineering’s behalf.

What Engineering needs from exploration is intent.

• What does the feature need to do?
• How should it behave?
• What did we learn from customers?
• What happens in the important edge cases?
• How will we know when the production version works as intended?

That becomes the handoff.

At Kaizen, we’ve been exploring a model where the bridge between the two cycles is a behavioral specification and a test plan, supported by the working prototype as a reference. The implementation itself stays behind.

What crosses into construction is the spec: a behavioral description, a test plan, and a link to the prototype as reference. The prototype itself stays where it was built.

In simple terms:

Product owns the what. Engineering owns the how.

That distinction matters even more now that AI makes it so easy for both sides to generate code.

What the workflow could look like

A PM starts with a product hypothesis. Instead of immediately turning it into a backlog item, they use AI to build enough of the experience to test it. They put it in front of users. They discover that part of the original idea was wrong. So they change it. They test again.

Once the problem and desired behavior are clear enough, the PM closes the exploration cycle with a clear specification and acceptance criteria.

Engineering then starts from that understanding, not from the PM’s experimental code only. They decide how the feature fits into the architecture, how it should be implemented, what needs to be verified, and how it reaches production.

The result is two parallel forms of autonomy:

• PMs don’t need Engineering for every experiment.
• Engineers don’t inherit implementation decisions from every experiment.

More autonomy doesn’t have to mean less ownership.

AI can make discovery faster

A lot of the conversation around AI in software teams is still about developer productivity. How much faster can we write code? How much implementation can an agent take on?

Those questions matter. But for Product, there may be an even bigger opportunity upstream. AI can shorten the distance between having an idea and learning whether that idea is any good.

That changes what PMs can bring to an engineering team. Instead of: “We think customers want this.” They can increasingly say: “We tested this behavior with customers. Here’s what worked, what didn’t, and exactly what we now need the product to do.”

That’s a much better starting point for building production software.

If you have a prototype and want to take the idea into production, we can help you determine what needs to happen next.

Catalyst 26 was Partnership Leaders' fifth annual conference for partnership, ecosystem, and go-to-market professionals. It took place August 25 and 26, 2026, at the Marriott Hotel at the Brooklyn Bridge in New York, with more than 1,000 attendees and 70-plus speakers from companies including Anthropic, OpenAI, Google, Microsoft, IBM, BCG, and Siemens.

Who Catalyst events are for

Catalyst brought together people building and running partner programs across SaaS, AI, consulting, systems integration, agencies, and major cloud platforms.

Attendees included executives leading partnership organizations, and people working directly in alliances, partner sales, marketing, operations, strategy, and enablement.

What Catalyst 26 is like

You can look at the agenda before a conference and have a pretty good idea of what you'll find. Being there is different.

This year's theme was "Navigating Frontier Ecosystems". Anthropic's Head of Partnerships and one of OpenAI's partner program leads appeared on the same agenda as people from Oracle, Siemens, IBM, and BCG, companies that have run formal partner programs for two decades.

That mix was one of the most interesting parts of the conference. Newer AI companies were discussing partner tiers, co-selling, and joint delivery alongside companies where those models have been part of their business for years.

What Catalyst 26 covered

Catalyst 26 split its sessions into eight pillars:

• Advancing Organizational Maturity: turning partnerships into something measured and repeatable instead of one founder doing favors for another.
• Become a Strategic Partner: getting partnerships involved when product and business decisions are made, not told about them afterward.
• Frontier Partner Experience: adapting partner programs as AI changes how companies build and integrate products.
• Path to CPO: career sessions for people aiming to lead partnerships at the executive level.
• Co-Build: two companies building something together.
• Co-Market: two companies running a campaign together.
• Co-Sell: two sales teams working the same deal.
• Co-Serve: two companies delivering the same engagement to a client.

Catalyst 26 sessions

Day 1 Keynote

The Day 1 keynote brought together Partnership Leaders’ CEO Asher Mathew, Tribe AI’s Co-founder & CEO Jaclyn Rice Nelson, Anthropic’s Head of Partnerships Phil Samenuk, and Boomi’s Chairman & CEO Steve Lucas.

Their discussion focused on how companies are relying on partners to build, sell, and deliver products across AI, cloud, and enterprise software. A few points stood out:

• More companies have dedicated partner teams now, which means a generic, one-size-fits-all partner program doesn't cut it anymore. Partners show up when the program fits how they work.
• New AI products and cloud services are shipping so fast that a partner program can't just get set once and left alone. Incentives, support, and how you work together need regular updates.
• Partnerships also came up as a way to access data a company couldn’t reach on its own, whether that meant getting access to it, combining it, or putting it to use.
• AI doesn't change the basics of a good partnership. Account planning, clear ownership, and relationships built over time still matter most.

Day 2 Keynote

The Day 2 keynote featured Ramp’s Lead Economist Ara Kharazian, Eliza’s Founder Brian Benedict, Siemens’ EVP Global Partner Ecosystem Dion Smith, and Oracle’s SVP, Partner Sales & Operations Strategy Leah Yomtovian.

A few points stood out:

• The spending data told a slower story than expected: AI adoption is mostly going toward productivity gains and task automation, not some overnight shift.
• Siemens is in the middle of folding more than 68,000 partners and roughly 200 separate programs into a single global one, mainly to make it easier to coordinate across IT and operational technology.
• Oracle's approach is a running "listening tour": every partner gets the same baseline benefits, then incentives and credits get layered based on the type of partner and how they work with Oracle.
• There was also talk of a newer kind of service team: bring in engineers, turn AI requirements into working products, and reuse delivery methods that already work instead of starting from scratch each time.

Next Catalyst events

The date and location of Catalyst 27 hasn’t been announced yet. In the meantime, you can check out the half-day Catalyst Summits in different cities:

• October 20, 2026 - Seattle
• October 27, 2026 - Chicago
• October 2026 - Los Angeles
• December 2026 - Singapore

Check Partnership Leaders’ events page for updates.